| [epp-dev] Release Day Concerns |
HI,
I'd like the final release day to go more smoothly than it has in the past. I'm concerned about a few things...
------------------ Stale Server Cache
-----------------------------
The most significant concern is that this problem does not happen yet again:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=548497#c29
It's not clear if this can only be fixed manually after the problem has been reported...
It's super important that these two calls yield a 404 not a 200 before
we publicly announce the release availability:
curl -I
http://download.eclipse.org/technology/epp/packages/2020-03/compositeContent.jar
curl -I
http://download.eclipse.org/technology/epp/packages/2020-03/compositeArtifacts.jar
Otherwise users with cached repository files will end up reusing
the cache and will have problems updating or installing.
---------------- Dropped Server Connections -----------------
These days, the download.eclipse.org server rapidly drops
connections:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=560808
I've worked around this in the installer with a retry loop while
loading a repository; this does not help for updates in the IDE.
---------------- Update-to-date Product Catalogs
-------------------
See the following thread for background of what I've needed to do to ensure up-to-date product labels, up-to-date incubation status, and up-to-date branding site links.
https://www.eclipse.org/lists/epp-dev/msg05767.html
I've generally tried to avoid EPP needing any special processes
or considerations in order for me to generate the product
catalogs. E.g., I can redirect to not-yet-made-visible
repositories to generate the catalog if if the repos are visible.
As such, I just keep on eye on the file system to see what's
there. But it's always kind of annoying that I'm never exactly
sure when the train site and the EPP site change to reveal the new
content...
Can I always expect that this happens at a certain time on
Fridays for the M and RC builds?
The issue with branding site links is also problematic because
the actual sites are not visible until after the announcement and
that's a bit too late. And that's made more problematic now by
the last minute rush to add incubation...
More specifically, the concern is the timing for creating this
page for the final release:
https://www.eclipse.org/downloads/packages/release/2020-03/r
I typically need to be able to scan this HTML in order to generate up-to-data branding site links and up-to-date incubation information.
Given I generally prefer to reduce timing demands on others---I
can live with predicable schedules---I've implemented some logic
that "anticipates/predicts" what the site URLs will be for the M,
RC, and R builds.
For example, the RCP the site is expected to be:
https://www.eclipse.org/downloads/packages/release/2020-03/r/eclipse-ide-rcp-and-rap-developers
As opposed to the current value:
https://www.eclipse.org/downloads/packages/release/2020-03/rc1/eclipse-ide-rcp-and-rap-developers-includes-incubating-components
I can then commit the anticipated site/incubation state to Git well ahead of schedule in order to make sure this job picks it up:
https://ci.eclipse.org/oomph/job/setup-archiver/
It takes significant time to propagate the changes such that they're available to the end-user via:
http://www.eclipse.org/setups/setups.zip
That's because firstly there's a delay because
https://git.eclipse.org/c/oomph/org.eclipse.oomph.git/plain/setups/org.eclipse.products.setup
takes a while to accurately deliver the changes to the setup
archiver job after a commit because of caching. And then because
of server caching, it takes a while before
http://www.eclipse.org/setups/setups.zip actually yields what's in
the file system as opposed to what's in the server cache.
As such, I generally try to commit an hour before the release time.
Regards,
Ed