Storage Restore issue - Next Steps

[mpalat]

Dear JDT Committers (not just JDT.Core),
Hope you have seen the message : https://www.eclipse.org/lists/eclipse.org-committers/msg01496.html. Quoting from the message verbatim :
"
To avoid prolonging the outage any further, we have two options:

1. We can provision a Jenkins instance with the last known version of the Jenkins data. This data is the last snapshot prior to migration to the storage cluster, and, depending on when your instance was migrated, may be weeks, or up to several months old.
2. We can provision a new, bare Jenkins instance for your project. If your build is defined in pipelines alongside your code, recovery may be more straightforward.
3. You can also choose to wait for the storage cluster to recover, so that we can either continue its usage, or extract data from it to provision a new instance. We do not, however, have an ETA for this recovery, nor do we know with any level of certainty that it actually will recover.
   "
   I am more inclined towards option 1, but however would like to have a discussion here before we raise an helpdesk issue to this effect.

Point to note here is that the last known JDT version is of March 5, 2025.

Opinions/suggestions - welcome.

Regards,
Manoj

[mpalat]

@stephan-herrmann @jarthana @srikanth-sankaran @iloveeclipse @noopur2507 @jjohnstn @HannesWell @jukzi @akurtakov others.. flagging to have a faster consensus

[akurtakov]

All the repos have Jenkinsfiles that were used for verification so from that POV the project should be fine even with new JIPP .
The question (I have no idea about) is whether there have been some jobs for Y/P builds that are not in jenkinsfiles in git and may need more work to be recreated.

[iloveeclipse]

1. We can provision a Jenkins instance with the last known version of the Jenkins data

If the data is OK, we are fine. If not, we are at point 2. anyway. So why not try 1. ? Y builds do not make much sense without working master build and known master state.

However, what is more interesting, is platform (SDK) build that is also down. I believe there all jobs were defined in code, so it would be 1. too. => eclipse-platform/eclipse.platform.releng.aggregator#3005

[noopur2507]

Option 1 - It makes sense to try the backup first.

[HannesWell]

Just want to link my response from eclipse-platform/eclipse.platform.releng.aggregator#3005 (comment)

I don't know the JDT JIPP in detail, so I cannot say much about it. The only thing I remember is that in the context of #3244 a free-style job was created, which would be lost in case a clean new JIPP is created.
However as suggested in #3244 (comment), I have already migrated it to a pipeline job at https://github.com/HannesWell/eclipse.jdt/tree/pBuild-jenkinsfile, just didn't have the time to contribute it yet (vacation, other things to do, lost track). So just in case a fresh JIPP is needed, there is a backup.
I plan to contribute it soon, as I think that format has advantages even if the configuration can be restored from back-up. But I assume that's not urgent, as the next time P-builds become relevant is in autumn for Java-25, isn't it?

[mpalat]

as the next time P-builds become relevant is in autumn for Java-25, isn't it?

BETA_JAVA 25 M2 milestone - June 10th would be when P build would start becoming relevant especially for testing. For production, it will be around 3rd week of September, the release date.

[mpalat]

And thanks @HannesWell for the suggestions. Since the majority is for option 1, will raise an issue for Option 1.

[stephan-herrmann]

as the next time P-builds become relevant is in autumn for Java-25, isn't it?

BETA_JAVA 25 M2 milestone - June 10th would be when P build would start becoming relevant especially for testing. For production, it will be around 3rd week of September, the release date.

Why not start right now (after recovery has finished)? I guess some people have already started using Java 25 ea. Why not let them use what we have?

[stephan-herrmann]

The only thing I remember is that in the context of #3244 a free-style job was created, which would be lost in case a clean new JIPP is created.

Not really lost, see the three lines (!) captured in https://github.com/eclipse-jdt/eclipse.jdt.core/wiki/Working-towards-Java-$N-plus-1-%E2%80%90-organizational-issues#p-builds 😄

[mpalat]

Issue raised at https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/5974

[stephan-herrmann]

For completeness: we had more than one free-style job (see also several "run.javac" jobs), so restoring from backup will be convenient, thanks.

None of those jobs have relevantly complex configuration though, so losing the old config wouldn't be a great loss. Actually, for those jobs where I'm the only one active, I'd appreciate if the strategy remains unchanged, as that's what I'm familiar with (and I don't think we need to see every configuration experiment in our git history). OTOH, if someone wants to step up and take responsibility (who?), then a change of strategy would surely be fine.

[iloveeclipse]

FYI: the jdt jenkins is back butPR's can't be built yet because it seems that not all data (or not at all???) is restored on https://repo.eclipse.org/content/repositories/ :-(

• https://ci.eclipse.org/jdt/job/eclipse.jdt.core-Github/job/PR-3954/2/console
• https://ci.eclipse.org/jdt/job/eclipse.jdt.debug-github/job/PR-688/1/pipeline-console/

[iloveeclipse]

SDK build works now, Jenkins too, closing.