[RelEng] Derive Maven deployment type from sourceRepository

This allows to remove the explicit 'snapshotOrRelease' parameter and
simplifies invoking the job.
The deployment type is derived from the sourceRepository URL.
But as a safeguard the user is instead asked for confirmation if a
'release' deployment is detected.

Author: HannesWell

JenkinsJobs/Builds/build.jenkinsfile

@@ -317,7 +317,6 @@ spec:
 			}
 			steps {
 				build job: 'Releng/PublishToMaven', wait: false, parameters: [
-					string(name: 'snapshotOrRelease', value: 'snapshot'),
 					string(name: 'sourceRepository', value: "https://download.eclipse.org/eclipse/updates/${RELEASE_VER}-${BUILD_TYPE}-builds/${BUILD_IID}")
 				]
 			}

JenkinsJobs/Releng/FOLDER.groovy

@@ -21,8 +21,11 @@ Releases are published to <a href="https://repo1.maven.org/maven2/org/eclipse/">
 <p>
 ''')
 	parameters { // Define parameters in job configuration to make them available even for the very first build after this job was (re)created.
-		choiceParam('snapshotOrRelease', ['snapshot' /*default*/, 'release'], '''\
-If this is the publication of a snapshot or a release build. 
+		stringParam('sourceRepository', null, '''\
+The URL of the source P2 repository to be published.<br>
+For a snapshot publication, the 4.x-I-Builds child repository of the specific build should be specified, e.g. 'https://download.eclipse.org/eclipse/updates/4.37-I-builds/I20250710-1800/'<br>
+<b>To deploy a <em>Release</em>, the corresponding release repository should be specified</b>, e.g. 'https://download.eclipse.org/eclipse/updates/4.36/R-4.36-202505281830/'<br>
+If left blank (not recommended), the latest I-build is published.
 <ul>
 <li>
 Snapshots are published to <a href="https://repo.eclipse.org/content/repositories/eclipse-snapshots/">https://repo.eclipse.org/content/repositories/eclipse-snapshots/</a>.
@@ -31,12 +34,6 @@ Snapshots are published to <a href="https://repo.eclipse.org/content/repositorie
 Releases are published to <a href="https://repo1.maven.org/maven2/org/eclipse/">Maven central</a> by publishing to a <a href="https://oss.sonatype.org/#stagingRepositories">staging repository</a>.
 </li>
 </ul>
-''')
-		stringParam('sourceRepository', null, '''\
-The URL of the source P2 repository to be published.<br>
-<b>If this is a <em>release</em> publication, the corresponding release repository should be specified</b>, e.g. 'https://download.eclipse.org/eclipse/updates/4.36/R-4.36-202505281830/'<br>
-For a snapshot publication, the 4.x-I-Builds child repository of the specific build should be specified, e.g. 'https://download.eclipse.org/eclipse/updates/4.37-I-builds/I20250710-1800/'<br>
-If left blank (not recommended), the latest I-build is published.
 ''')
 	}
 	definition {

JenkinsJobs/Releng/publishToMaven.jenkinsfile

@@ -14,6 +14,7 @@ pipeline {
 		maven 'maven-daemon'
 	}
 	environment {
+		DEPLOYMENT_TYPE = determineDeploymentType()
 		REPO = "${WORKSPACE}/repo"
 		CBI_AGGR = "${installLatestCbiAggr()}"
 		// Folder ~/.m2 is not writable for builds, ensure mvnd metadata are written within the workspace.
@@ -24,15 +25,15 @@ pipeline {
 	stages {
 		stage('Aggregate Maven repository') {
 			steps {
-				sh '''#!/bin/bash -e
+				sh '''#!/bin/bash -xe
 					FILE_SDK_AGGR="${WORKSPACE}/git-repo/eclipse.platform.releng/publish-to-maven-central/SDK4Mvn.aggr"
 
 					# Set the specified source repository
 					if [ -n "${sourceRepository}" ]; then
 						sed -e "s|<repositories location=\\".*\\">|<repositories location=\\"${sourceRepository}\\">|" -i ${FILE_SDK_AGGR}
 					fi
 					# Set whether this is a snapshot build or not
-					if [ "${snapshotOrRelease}" != 'release' ]; then
+					if [ "${DEPLOYMENT_TYPE}" != 'release' ]; then
 						sed -e 's/snapshot=".*"/snapshot="true"/g' -i ${FILE_SDK_AGGR}
 					fi
 
@@ -49,6 +50,7 @@ pipeline {
 
 					pushd ${REPO}
 
+					set +x
 					echo "========== Repo aggregation completed ========="
 
 					# Find all the artifact folders for all projects
@@ -179,6 +181,15 @@ pipeline {
 	}
 }
 
+def determineDeploymentType() {
+	if ("${sourceRepository}".trim() =~ /\/(?<version>\d+\.\d+)\/R-\k<version>(\.\d+)?-\d{12}(\/)?$/) {
+		input message: 'The specified P2 repository is a release and will be deployed to Maven-Central.', ok : 'Proceed deploying to Maven-Central'
+		return 'release'
+	} else {
+		return 'snapshot'
+	}
+}
+
 def installLatestCbiAggr(){
 	return install('cbiAggr', "https://download.eclipse.org/cbi/updates/p2-aggregator/products/nightly/latest/org.eclipse.cbi.p2repo.cli.product-linux.gtk.x86_64.tar.gz") + '/cbiAggr'
 }

RELEASE.md

@@ -110,7 +110,8 @@ The actual steps to release
     - You can subscribe to [cross-project-issues](https://accounts.eclipse.org/mailing-list/cross-project-issues-dev) to get the notifications on Simrel releases.
   * #### **Publish to Maven central**
     - Publishing to maven should happen by at least Tuesday before the release since there is up to a 24 hour delay for the maven mirrors.
-    - Run the [Publish to Maven](https://ci.eclipse.org/releng/job/Releng/job/PublishToMaven/) job in jenkins with the `release` parameter and the release build as `sourceRepository`.
+    - Run the [Publish to Maven](https://ci.eclipse.org/releng/job/Releng/job/PublishToMaven/) job in Jenkins with the release build as `sourceRepository`.
+      - About a minute after triggering the job, Jenkins will ask for confirmation on the console, if the specified build should really be deployed to Maven-Central staging.
     - Once that publish job has completed successfully, log into https://oss.sonatype.org/#stagingRepositories and close the Platform, JDT and PDE repositories.
       - If you do not have an account on oss.sonatype.org for performing the rest of the release request one by creating an issue like https://issues.sonatype.org/browse/OSSRH-43870 to get permissions for platform, JDT and PDE projects and tag an existing release engineer to give approval.
   * **Contribute to SimRel**
@@ -134,8 +135,6 @@ The release is scheduled for 10AM EST. Typically the jobs are scheduled beforeha
     - For the Y and P build parameters it's important to know whether or not Y and P builds were run during the release. Since they correspond to java releases on a 6 month cycle, typically they are built in odd-numbered releases.  
     The existing builds are kept for one release, then cleaned up before the next stream that will have Y and P builds. it's convoluted and I dont want to type it out. Remove Y builds on even releases. 
     - If something doesn't get cleaned up properly you can use  Use the [list artifacts](https://ci.eclipse.org/releng/view/Cleanup/job/list_artifacts_from_download_server/) job to generate ta list of what's on the download server and either create a new job to clean it up or update and rerun the cleanup job as appropriate.
-  * **Set Maven to Publish to I-builds**
-    - Update [SDK4Mvn.aggr](https://github.com/eclipse-platform/eclipse.platform.releng/blob/master/publish-to-maven-central/SDK4Mvn.aggr) and point it to the new streams I-builds.
   * **Set Previous Release to GA** 
     - Everything that was updated to RC2 (see below) should now use the released build.