Remove 4.36 from 4.37-I-builds

[merks]

To keep

• https://download.eclipse.org/eclipse/updates/4.37-I-builds/

from being empty at the start of the cycle, we composed

• https://download.eclipse.org/eclipse/updates/4.36-I-builds/I20250528-1830

So currently it looks like this:

We should improve the processes such that 4.36 is removed as soon as a proper 4.37 I-build is added and should remove 4.36-I-builds as soon as possible, i.e., especially before the 4.36 I-builds are deleted.

FYI @MohananRahul

[MohananRahul]

It appears this issue was caused by the change mentioned in this comment.
@HannesWell, could you please advise which job was previously used to add the earlier released version?

[HannesWell]

I'm currently on it. It should be gone soon. I added it with a manually assembled prototype job and I'm currently using a modified version to remove it. If I fail to remove it this morning (I only have limited available), I'll continue this evening.
The most important part is that nobody else deletes the referenced 4.36-I-builds repo in the meantime.
I'll let you know once the reference is removed.

We should improve the processes such that 4.36 is removed as soon as a proper 4.37 I-build is added and should remove 4.36-I-builds as soon as possible, i.e., especially before the 4.36 I-builds are deleted.

Yes, absolutely. I think it should be sufficient to update https://ci.eclipse.org/releng/job/Cleanup/job/pruneDailyRepos/, to always just keep three (or whatever threshold is specified builds).

I think it's even worth to consider to implement a hard coded limit of references that are retained in the composite when a new build is added to the composite. Then when adding a new build an old one is immediately removed and we don't need an extra job to clean-up.
The current approach only has the advantage that, if a build is marked unstable later, that then the clean-up might not have happened and more repos remain in the composite. But since the limit is currently three (we could increase it to four if necessary) there should be sufficient back-up in the composite to not run empty. Unless we mark three consecutive builds unstable. But for that case we could also enhance the mark-unstable job to at least warn about it or by adding back older builds?

[HannesWell]

And while I have written my previous message the job to remove the reference already completed and the reference is gone.
You should be able to verify that by downloading the composite-jars from https://download.eclipse.org/eclipse/updates/4.37-I-builds/ (for me there was even no caching of old content 👍🏽 ).

[HannesWell]

I think it's even worth to consider to implement a hard coded limit of references that are retained in the composite when a new build is added to the composite. Then when adding a new build an old one is immediately removed and we don't need an extra job to clean-up.

This is now implemented with

• [Build] Remove old builds from composite p2-repo when adding new ones #3153