[RelEng] Update build configuration in release preparation pipeline

and simplify the definition and activation of the RC schedule:
Update the cron-trigger to it's final value immediately. The extra
builds are then triggered when the RC period arrives without activating
that schedule manually.

Author: HannesWell

JenkinsJobs/Builds/FOLDER.groovy

@@ -14,18 +14,11 @@ for (STREAM in config.Streams){
 				triggers {
 					cron {
 						spec('''TZ=America/Toronto
-# format: Minute Hour Day Month Day of the week (0-7)
-
+# Format: Minute Hour Day Month Day-of-week (1-7)
 # - - - Integration Eclipse SDK builds - - - 
-# 2025-09 Release Schedule
-# Normal : 6 PM every day (11/6 - 27/8)
-# 0 18 * * *
-
-
-# RC Schedule 
-# Post M3, no nightlies, I-builds only. (Be sure to "turn off" for tests and sign off days)
-# 0 6 15-27 8 5-7,1-3
-# 0 18 15-27 8 5-7,1-3
+# Schedule: 6 PM every day until end of RC2
+0 18 * 5-7 *
+0 18 1-27 8 *
 ''')
 					}
 				}

JenkinsJobs/Releng/prepareNextDevCycle.jenkinsfile

@@ -47,9 +47,10 @@ pipeline {
 					// E.g. next to: https://github.com/eclipse-simrel/.github/blob/main/wiki/SimRel/2025-09.md
 					def m1Date = parseDate(readParameter('M1_DATE'))
 					def m2Date = parseDate(readParameter('M2_DATE'))
+					//TODO: do we still need this?
 					def m3Date = parseDate(readParameter('M3_DATE'))
 					def rc1Date = parseDate(readParameter('RC1_DATE'))
-					def rc2Date = parseDate(readParameter('RC2_DATE'))
+					rc2Date = parseDate(readParameter('RC2_DATE'))
 					def gaDate = parseDate(readParameter('GA_DATE'))
 					if (!(m1Date < m2Date && m2Date < m3Date && m3Date < rc1Date && rc1Date < rc2Date && rc2Date < gaDate)) {
 						error "Dates are not in strictly ascending order: ${M1_DATE}, ${M2_DATE}, ${M3_DATE}, ${RC1_DATE}, ${RC2_DATE}, ${GA_DATE}"
@@ -136,6 +137,30 @@ pipeline {
 				replaceInFile('production/testScripts/configuration/streamSpecific.properties', [
 					"for ${PREVIOUS_RELEASE_VERSION}.0 builds" : "for ${NEXT_RELEASE_VERSION}.0 builds",
 				])
+				replaceInFile('JenkinsJobs/JobDSL.json', [
+					/"${PREVIOUS_RELEASE_VERSION}"/ : /"${NEXT_RELEASE_VERSION}"/,
+				])
+				script {
+					def now = java.time.LocalDate.now()
+					def rcEnd = rc2Date.minusDays(2) // Wednesday before RC2 is the last planned I-build
+					// if (rcEnd < now || now.until(rcEnd).toTotalMonths() > 10) {
+					// 	// This enire logic is based on the assumption that the rc-end is (clearly) less then a year ahead (and not in the past).
+					// 	// Fail to make callers aware that this part has to be reworked, in case the release schedule changes that much.
+					// 	error "RC end is in the past or almost a year (or more) ahead."
+					// }
+					def completeMonthsStart = now.monthValue
+					def completeMonthsEnd = rcEnd.monthValue - 1
+					// Consider end-of-year overflows
+					def completeMonths = (completeMonthsStart < completeMonthsEnd) ? "${completeMonthsStart}-${completeMonthsEnd}" : "${completeMonthsStart}-12,1-${completeMonthsEnd}"
+					def rcSchedule = """\
+						0 18 * ${completeMonths} *
+						0 18 1-${rcEnd.dayOfMonth} ${rcEnd.monthValue} *
+					""".stripIndent().trim()
+					echo "RC schedule:\n${rcSchedule}"
+					replaceAllInFile('JenkinsJobs/Builds/FOLDER.groovy', [
+						"(?<prefix># Schedule:.*\\R)(?s).*(?<suffix>\\R'''\\))" : '${prefix}'+rcSchedule+'${suffix}',
+					])
+				}
 
 				commitAllChangesExcludingSubmodules("Update versions to ${NEXT_RELEASE_VERSION} in build scripts")
 			}
@@ -408,6 +433,8 @@ pipeline {
 
 @groovy.transform.Field
 def githubAPI = null
+@groovy.transform.Field
+def rc2Date = null
 
 // --- utility methods
 

JenkinsJobs/YBuilds/FOLDER.groovy

@@ -15,15 +15,10 @@ for (STREAM in config.Streams){
 				triggers {
 					cron {
 						spec('''TZ=America/Toronto
-# format: Minute Hour Day Month Day of the week (0-7)
-
-#Daily Y-build
-0 10 * * *
-#milestone week
-#0 6 * * 2
-#0 6 * * 4
-#
-#0 2 21 7 4
+# Format: Minute Hour Day Month Day-of-week (1-7)
+# - - - Beta Java Eclipse SDK builds - - - 
+# Schedule: 10 AM every second day
+0 10 * * 2,4,6
 ''')
 					}
 				}

RELEASE.md

@@ -5,7 +5,6 @@
 ## Milestone and RC Releases
 
 ### Friday before release week:
- * Update [I-builds job definition](JenkinsJobs/Builds/FOLDER.groovy) to build on the milestone schedule (Twice daily at 06:00 EST and 18:00 EST except Thursday).
  * Create or update prerequisite issues for tracking ECF, EMF and Orbit
  * Send reminder email for upcoming RC week to [email protected], [email protected], [email protected] and [email protected]
    * [Example from 4.30 RC1](https://www.eclipse.org/lists/platform-dev/msg03924.html) but the usual schedule:
@@ -49,9 +48,7 @@
            4. Update the Location property to the "Specific repository for building against" in the mailtemplate.txt from promotion.
            5. Commit Simrel updates to Gerrit
               - Message should use year-month format, i.e "Simrel updates for Eclipse and Equinox for 2022-06 M1"
-       * For **Milestone builds** return the I-builds to the normal schedule.
      * **After RC1**
-       * Leave the I-builds running on the milestone schedule for RC2. 
        * Comment on EMF, ECF and Orbit issues to ask for final release builds.
      * **After RC2**
        * (optional) Disable the automatic [nightly cleanup](https://ci.eclipse.org/releng/job/Cleanup/job/dailyCleanOldBuilds/) of I-builds
@@ -165,12 +162,12 @@ The release is scheduled for 10AM EST. Typically the jobs are scheduled beforeha
   - Issue for the 2023 releases is [https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/2336](https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/2336)
 
 #### **Update Jenkins for the next Release:**
-  - Edit the [JobDSL.json](JenkinsJobs/JobDSL.json)
-      * Add the next release version to the `Streams` key item.
-      * In the `branches` item update the current release to map to the maintenance branch and add a new key:value pair mapping the next release to master.
   - Run the [Create Jobs](https://ci.eclipse.org/releng/job/Create%20Jobs/) job in Jenkins.  
-    This should move the current I-builds to run on the maintenance branch and create new I-builds for the next release.
-    Performance and Unit tests should also be generated for the new release automatically.
+    But until the preparation work has completed, the new I-builds should not be triggered in order to avoid undesired interference. To ensure this, either
+    - Run the `Create Jobs` job only after all preparation work is reviewed and submitted and the first I-build can run.
+    - Disable the new `I-build` job until it's ready to run it the first time.
+      In order to investigate the state of the I-build it's probably also good to disable the job again after the first I-build has completed, until the master is open for regular development.
+  - Move the previous (still existing) I-Build job to run on the maintenance branch (and remove it's cron trigger). That job can be deleted (together with its test jobs), when we are sure RC respins won't happen anymore.
 
 #### **Create Git Milestones for the next Release:**