[RelEng] Update build configuration in release preparation pipeline

[HannesWell]

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.

This also simplifies the cron-triggers by just using the complement for the RC schedule (at least for I-builds) and by continuing the RC schedule for the sign-off Thursday. Nowadays we don't have to worry too much about extra triggers as an I/Y build is skipped when nothing has changed:

• [Build] Skip scheduled I/Y-build if nothing has changed since last build #2706,

From a RelEng POV this has the advantage that the RC schedule doesn't have to be activated by an extra config/code-change but is just specified as necessary from the beginning.

FYI @akurtakov, @MohananRahul
and @jarthana, @mpalat, @stephan-herrmann as this also affects JDT's Y-build.
Are you all fine with this?

This is currently a draft as the update of the Y-build is currently missing and I have to check if the new I/Y-build jobs can be created in disabled state (and be activated once everything is ready).

[mpalat]

FYI @akurtakov, @MohananRahul and @jarthana, @mpalat, @stephan-herrmann as this also affects JDT's Y-build. Are you all fine with this?

Thanks @HannesWell. Looks fine to me. Rechecking on one point on Y-Build: While I Build is always on master, Y Build as you know will be on the BETA_JAVAXX branch which would be BETA_JAVA26 for Java 26. After BETA_JAVA25 merge to master, Y Build should not automatically triggered on BETA_JAVA25 even if there's an update on BETA_JAVA25 (by mistake, let's say). Is there any guard for this scenario?

[stephan-herrmann]

If I am to answer if the impact on Y-builds is OK, I would need a little help, what actually is the effect on Y-builds? Do we have a special schedule for RC phase? Do we have a precise definition of that RC phase to begin with? Other effects?

Then for a moment I was thinking if #2706 is actually good for Y-builds (which have lower frequency of actual changes). In the light of intermittent test failures I actually appreciate when more builds are running on the same input to give an idea if the failure indicates a systematic bug.

OTOH, I don't want to be a resource hog, so should the above scenario be resolved by touching some forceQualifierUpdate.txt file or similar?

[HannesWell]

FYI @akurtakov, @MohananRahul and @jarthana, @mpalat, @stephan-herrmann as this also affects JDT's Y-build. Are you all fine with this?

Thanks @HannesWell. Looks fine to me. Rechecking on one point on Y-Build: While I Build is always on master, Y Build as you know will be on the BETA_JAVAXX branch which would be BETA_JAVA26 for Java 26. After BETA_JAVA25 merge to master, Y Build should not automatically triggered on BETA_JAVA25 even if there's an update on BETA_JAVA25 (by mistake, let's say). Is there any guard for this scenario?

In fact this needs an even more detailed look: Even for Y-builds the eclipse.platform.releng.aggregator repo as well as most submodules are still checked out from the master branch. Therefore the pipelines also get their definition from the master branch. Only the JDT repos are checked-out at the corresponding BETA_JAVAXX branch, as it's defined (for Java-25) in:
https://github.com/eclipse-platform/eclipse.platform.releng.aggregator/blob/abd5d8563d0caa7e84d5ebd5b63f95e6e0d1c0f5/cje-production/streams/repositories_java25.txt
Furthermore the Y-builds are 'published' to the Y-builds repo with a name based on the current Eclipse release and the name doesn't contain the java-version, as defined in

eclipse.platform.releng.aggregator/cje-production/mbscripts/mb620_promoteUpdateSite.sh

Line 26 in abd5d85

dropsPath=${epUpdateDir}/${STREAMMajor}.${STREAMMinor}-${BUILD_TYPE}-builds

To make a long story short and to answer your question: As soon as the repositories_javaXX.txt is changed to the next version the Y-build (even with the same Eclipse version) will build the new BETA_JAVAXX branch. That file is basically the switch.
If there is some time between the last Y-build e.g. for BETA_JAVA25 and the point where BETA_JAVA26 is set up, I suggest to simply disable the corresponding Y-build job in the Jenkins UI.

Or does this gap not really exist and you create the BETA_JAVA26 branch on the same day when BETA_JAVA25 is merged into master?

If I am to answer if the impact on Y-builds is OK, I would need a little help, what actually is the effect on Y-builds? Do we have a special schedule for RC phase? Do we have a precise definition of that RC phase to begin with? Other effects?

That's a good question I was also wondering. For the Eclipse-TLPs respectively the RC-phase/schedule starts on Monday before RC1 and lasts until Wednesday before RC2. The build from Wednesday night is by default the last build of a release cycle and is to be signed off on Thursday and promoted on Friday. If problems are noticed early, another build can be started manually on Thursday or Friday (before the promotion). Or there is a RC2a/b/c... if problems are noticed later.
But that's just the RC schedule for I-builds.

The effect on Y-builds is indeed a good question. Correct me if I'm wrong, but for the beta branch eventually only the P-build repo is published in that sense that the P-build repo is referenced from the Marketplace entry for ECJ's support of a new java version, which is created on release day (and based on selected bundles from the Y-build)?
With that in mind I would say that the Eclipse release schedule is actually irrelevant for Y-builds and they should just continue on the regular schedule in that time.
The RC phase for Y-builds respectively the support of a new Java version in ECJ is actually the week before the release of that java version.
So my proposal is to leave the Y-build at it's regular schedule during the Eclipse RC. And if you want it, add a 'Java-RC' about a week before a Java-release where the Y-build runs every day instead of every two days?

[HannesWell]

Then for a moment I was thinking if #2706 is actually good for Y-builds (which have lower frequency of actual changes). In the light of intermittent test failures I actually appreciate when more builds are running on the same input to give an idea if the failure indicates a systematic bug.

That feature was introduced mainly for RC-schedule times where we have more frequent I-builds but at the same time have a great chance of no changes (if no bug is found...). or times around new-year where only little change happens.

As Y-builds by defaults runs less often, it would probably not be unreasonable to turn that off for Y-builds. OTOH, the last time a Y-build was skipped due to no changes was in March (probably short before the Java-24 release?):
https://www.eclipse.org/lists/jdt-dev/2025/Mar/index.html
At the same time this can be an argument pro disabling build-skipping for Y-builds.
However, let's discuss that separately.

OTOH, I don't want to be a resource hog, so should the above scenario be resolved by touching some forceQualifierUpdate.txt file or similar?

Does enforcing a new qualifier really helps with test-failures? I assumed they only helped with comparator errors.

[akurtakov]

For the record - 4.37 RC1 I-builds happened only once per day and 2 I-builds per day for RC2 . As RC2 is too late in the cycle for significant work having 2 builds doesn't make sense and no one complaint about the single build per day for RC1 - I propose to remove this complication and have single I-build per day at all time even in RC phase.

[HannesWell]

I propose to remove this complication and have single I-build per day at all time even in RC phase.

That sounds good to me. I plan to complete this with that proposal. The only 'complication' I would add is to that the cron-trigger patterns should be limited to stop (the regular) schedule after RC2-2 (as it's intended now).
Then we don't have to disable the I-build after RC2 is build to prevent disturbing I-builds during the preparation of the subsequent release. But that should be much simpler (in the end we'll have to lines instead of one).

So my proposal is to leave the Y-build at it's regular schedule during the Eclipse RC. And if you want it, add a 'Java-RC' about a week before a Java-release where the Y-build runs every day instead of every two days?

@mpalat and @stephan-herrmann, I plan to continue with that for now and discuss with you a potential JDT/Y-build rc schedule in a separate PR. Unless you state that you don't want that at all?

[HannesWell]

This PR has been updated with the suggestion from my previous message.
All my testing so far was successful.

This is a pure RelEng change that's intended to be used for the upcoming release preparation. Therefore I'm submitting this now despite we are currently in a freeze-period. And as the verification build doesn't test this, I'm submitting this immediately.

[stephan-herrmann]

We have a build failure in https://ci.eclipse.org/jdt/job/eclipse.jdt.core-run.javac-25/26/console which tells me that that composite repo https://download.eclipse.org/eclipse/updates/Y-builds already points to 4.38-Y-builds, which IMHO doesn't make sense before Java 25 GA / final freeze of BETA_JAVA25.

Is there any connection to this PR?

Will Y-builds start to upload to 4.38-Y-builds already?

As per eclipse-jdt/eclipse.jdt.core#4366 I'm preparing to tie the branch build to the more specific 4.37-build repo, which assumes that this will still be populated by current Y-builds. Is this assumption correct?

[stephan-herrmann]

Will Y-builds start to upload to 4.38-Y-builds already?

no, today's Y-build still uploaded to 4.37-Y-builds.

[stephan-herrmann]

We have a build failure in https://ci.eclipse.org/jdt/job/eclipse.jdt.core-run.javac-25/26/console which tells me that that composite repo https://download.eclipse.org/eclipse/updates/Y-builds already points to 4.38-Y-builds, which IMHO doesn't make sense before Java 25 GA / final freeze of BETA_JAVA25.

Is there any connection to this PR?

Will Y-builds start to upload to 4.38-Y-builds already?

As per eclipse-jdt/eclipse.jdt.core#4366 I'm preparing to tie the branch build to the more specific 4.37-build repo, which assumes that this will still be populated by current Y-builds. Is this assumption correct?

There's more to it, over to #3273

[HannesWell]

We have a build failure in https://ci.eclipse.org/jdt/job/eclipse.jdt.core-run.javac-25/26/console which tells me that that composite repo https://download.eclipse.org/eclipse/updates/Y-builds already points to 4.38-Y-builds, which IMHO doesn't make sense before Java 25 GA / final freeze of BETA_JAVA25.

Is there any connection to this PR?

Yes that was changed intentionally, but after your remarks, I think that this point in time might be too early.

There's more to it, over to #3273

Thanks, I'll continue there.