I started reading the releasing.md and I realized there is a call for vote. Technically, I understand the committee must review everything from a sort of staging.
Based on this documentation, I propose the following:
push on develop will update the SNAPSHOT version of the maven site (note that this also trigger a publication of the package in the staging maven repository hosted at https://packages.orekit.org/).
push on release-X.Y will update the RELEASE version of the maven site, but as the website is not updated, it is not directly accessible from external users (note that this also trigger a publication of the package in the release maven repository hosted at https://packages.orekit.org/).
push on master will update the RELEASE version of the maven site and will update the link site-orekit-latest.
I think it would be great!
What about the non-maven artifacts hat are generated for review, and after vote put to the downloads page?
Currently, the manual provess for release candidates is to set up temporary staging/donwloads directory on the server (ssh, mkdir, vi index.html…), and to copy the new artifacts manually to the official download directory when the vote succeeds.
A generic answer: depending on the review process expected, but artifacts can be hosted directly by Gitlab, associated to the relevant pipeline. Please, look at my experiments: https://gitlab.orekit.org/gbonnefille/orekit/pipelines?scope=branches&page=1 This view focus on branches status. As you can see in the right, a button allow to download anything declared as artifact during the pipeline. When selecting a pipeline and then a job, you are also able to browse the artifacts avoiding a full download.
Having the full list of the artifacts that must be published and reviewed can help to draw a detailed picture.
OK, we have to add a step to deploy these artifacts.
As I recently also worked on website auto-publishing, I suggest a different approach.
Instead of using an explicit staging/download directory, I propose to publish the new maven site directly to its final destination (since my recent modifications, it is now /var/www/mvn-site/site-orekit-X.Y) and play with the new staging homepage (https://test.orekit.org/).
push a new release candidate -> bot will publish maven site on /var/www/mvn-site/site-orekit-X.Y and Maven packages to the project’s Nexus Release repository
update the whole website (mostly adding the new release to the release list) and push on develop branch -> bot will publish website on https://test.orekit.org/
call for vote: people can check the website and the release
Looking deeper, it seems this part is slightly different currently. It seems that:
artifacts are stored as attachments to the release publication on GitLab
links to downloads from website are a mix between specific links into maven site and Redirect rules to point to Gitlab dedicated artifacts.
I suppose all of this changes were made by @sdinot.
Before breaking anything, I’m interested in understanding why artifacts are stored in GitLab and not directly in the website (like maven site). It seems that such solution brings new complexity as Gitlab’s attachments use a not predictable internal id in the URL. Furthermore, there is now a Nexus repository that can be used to store raw artifacts. Perhaps it could be an option to store these artifacts with a predictable URL.
The sources.jar package as a maven artifact is a stripped-down version of sources.zip, created for a different purpose. It only contains the sources themselves (subdirectories of src/main/java) for use in an IDE, for debugging purposes. The sources.ziparchive contains everything needed to build the package (sources, tests, resources, build files, plugins configuration files…)
I don’t really want to force people using maven only, and sources.zip is not really a maven artifact, so its kind of awkward for me to use this as our primary download area. I would really prefer to have sources.zip handled by ourselves. However, this is only my opinion, if other people prefer otherwise, I’d like to read their point of view too.
Please, note that the packages provided by Gitlab can be obtained locally with git archive -o orekit-x.y-sources.zip --format zip HEAD. The main differences with the zip provided by maven is that it can embed local files not managed by git, while git archive is strictly limited to versioned files.