Y-build repo link has changed - are we still able to run Y-builds?

[stephan-herrmann]

I was alerted by this build failure: https://ci.eclipse.org/jdt/job/eclipse.jdt.core-run.javac-24/28/

It is a special periodical build for branch BETA_JAVA24 which pulls dependencies from https://download.eclipse.org/eclipse/updates/Y-builds/

However, since 2025-03-12 09:07 that repo points to https://download.eclipse.org/eclipse/updates/4.36-Y-builds

I'm not worried about this particular special build, but I wonder if https://ci.eclipse.org/releng/job/YPBuilds/job/Y-build-4.35 is still able to succeed, as it has never run after 2025-03-08 (for lack of changes in source git).

We will need that job to run reliable this coming Tuesday, which is Java 24 GA.

So may I suggest to ensure that Y-build-4.35 is again run even if no changes are found?

Otherwise things might get very hectic again on Tuesday!

Also PR-builds of jdt.core, jdt.ui, jdt.debug should better be functional on that day, otherwise final changes would have to be merged without testing.

[stephan-herrmann]

Copying some people as I don't know who receives regular notifications: @MohananRahul @HannesWell @merks @mpalat @jarthana

[stephan-herrmann]

jdt.core PR builds fails with the same

14:40:11  [ERROR] Cannot resolve dependencies of project org.eclipse.jdt:org.eclipse.jdt.core:eclipse-plugin:3.41.50-SNAPSHOT
14:40:11  [ERROR]  with context {osgi.os=linux, osgi.ws=gtk, org.eclipse.update.install.features=true, org.eclipse.jdt.buildtime=true, osgi.arch=x86_64, org.eclipse.update.install.sources=true}
14:40:11  [ERROR]   Software being installed: org.eclipse.jdt.core 3.41.50.qualifier
14:40:11  [ERROR]   Missing requirement: org.eclipse.jdt.core 3.41.50.qualifier requires 'osgi.bundle; org.eclipse.core.runtime [3.29.0,4.0.0)' but it could not be found: See log for details

See https://ci.eclipse.org/jdt/job/eclipse.jdt.core-Github/job/PR-3808/1/console

[stephan-herrmann]

Correction: the repo hasn't gone, it's only the link in https://download.eclipse.org/eclipse/updates/Y-builds/ that has been prematurely updated from the active 4.35-Y-builds to the future 4.36-Y-builds

[stephan-herrmann]

OK, it seems we can work around the issues in jdt in the style of eclipse-jdt/eclipse.jdt.core#3809

Only the following combination of current strategies seems to be broken:

• Usage of generic Y-builds address in builds
• Updating of build configurations immediately before Java GA (and hence our final Y and P release builds)
• Skipping Y-builds during quiet week towards final Y and P release builds

This begs the question if we should change strategy in all three regards, or if changing only one or two items is a viable choice.

[stephan-herrmann]

Indications that Y-builds are still functional:

• https://ci.eclipse.org/releng/job/YPBuilds/job/Y-build-4.35/116
• https://ci.eclipse.org/releng/job/YPBuilds/job/ep435Y-unit-linux-x86_64-java24/72

At this point only all of JDT's PR builds are broken. Repair attempts are in

• Pin the address of the Y-build repo to 4.35-Y-builds eclipse-jdt/eclipse.jdt.core#3809
• Pin the address of the Y-build repo to 4.35-Y-builds eclipse-jdt/eclipse.jdt.ui#2089
• Pin the address of the Y-build repo to 4.35-Y-builds eclipse-jdt/eclipse.jdt.debug#641

Those attempts contain several version bumps as requested by tycho. I don't have an explanation why those bumps could possibly be needed, and whether or not they are relevant (needed?, wrong?) for Y-builds.

And of course the original failure of https://ci.eclipse.org/jdt/job/eclipse.jdt.core-run.javac-24/28/ still holds, but if that's the only one, then I'm willing to ignore it for now.

[mpalat]

Only the following combination of current strategies seems to be broken:

• Usage of generic Y-builds address in builds
• Updating of build configurations immediately before Java GA (and hence our final Y and P release builds)
• Skipping Y-builds during quiet week towards final Y and P release builds

This begs the question if we should change strategy in all three regards, or if changing only one or two items is a viable choice.

@stephan-herrmann @MohananRahul Updating configuration for every release may be error-prone, I guess especially since we will have to change the configuration again to reflect the next BETA_JAVAxx version. Would a pair of transient build jobs - a Y-dash and a P-dash configurations - make sense - to cover the period between the Eclipse RC2 and the Java version release time-frame? [Or do people feel that its adding noise to the list of build jobs?]

[mpalat]

For the record, adding that did a successful basic sanity testing with the existing P build - https://download.eclipse.org/jdt/updates/4.35-P-builds/P20250317-0634/ .

[stephan-herrmann]

@stephan-herrmann @MohananRahul Updating configuration for every release may be error-prone, I guess especially since we will have to change the configuration again to reflect the next BETA_JAVAxx version. Would a pair of transient build jobs - a Y-dash and a P-dash configurations - make sense - to cover the period between the Eclipse RC2 and the Java version release time-frame? [Or do people feel that its adding noise to the list of build jobs?]

I don't see which problem that would solve.

Let's check where these repo URLs are used:

1. currently jenkinsfile of each JDT git refers to the generic Y-builds p2 repo
2. do we expect users to keep a reference to Y-builds (or P-builds) across Java versions?
3. any other references?

Note that (1) exists only within a specific branch BETA_JAVAX. The next branch will be created afresh from master, no? So there is no way of keeping that reference unchanged.

I don't see much value in (2), because around the release of Java X the generic URL already points to Y-builds for X+1, which however, at that point have now valuable content. It will take a while until those X+1 builds produce useful content.

OTOH note, that each P-build references a specific Y-build anyway. No confusion here.

Ergo: I don't see much use in the generic Y-build repo.

From a JDT p.o.v. the generic Y-build repo would only make sense, if the redirect to X+1 would happen later: definitely only after Java X GA, more likely right during the process of creating new beta branches.

If releng wants to keep stream changes in a single check list to be done right after Eclipse code freeze, then we need to ensure that this in no way affects Y-builds of the current (old) stream, which rules out usage of a generic address that changes under foot at the unhappy point in time.