I’m working on it 
I have made some progress on the release script. It seems now to work and many steps are now automated.
There is however something that bothers me, and I don’t think I can fix it on my side, it is rather a change on Sonatype side with the new central portal. The problem is that once the artifacts have been created and uploaded (they are in the “validated” state, but not yet “published”), I can see them on central portal site once I am logged in, and I could publish it or drop it from there (or using one of the scripts I set up). However, I am not sure other people can see these files, and hence I don’t know if people could check the binary artifacts and vote on them.
So I would like to ask other community members to have a look at a temporary deployment I have made starting from branch issue-1760 and that contains a would-be 13.1 release (I will not publish this, it is just for test purposes). The link for the deployment is here, the URL contains an ID that was generated when “mvn deploy” was run.
Could other people access this URL? I guess at least people should create an account on central portal before they can, but I don’t know if people who have an account but are not declared as release managers for the org.orekit namespace can access it.
So could the orekit community try? I would like to have at least one of the declared release manager take a look, and also someone who is not a release manager but can create an account on Sonatype central portal.
Please report what you could do here (and for those who are allowed, please refrain from either dropping or publishing this release, it is for test purposes only and should NOT be published!)
Hi Luc,
first of all, thanks for all the effort you’re putting in easing the release process.
When I click on your link, it brings me to the “normal” page I see when I log into sonatype. Which doesn’t show much by the way, at least for me…
For people that are not release managers (so I guess most), I think it’s fine to be able to see the last SNAPSHOT here, at least for a non-patch release (which is fine since patches don’t need a vote).
Cheers,
Romain.
And once you are logged in, the URL doesn’t show up the deployment?
Sorry I should have been clearer, once logged in I don’t see much.
Nothing in deployements at all.
This is bad news since you are declared as allowed to publish releases for this namespace.
So I guess nobody but me can see these files 
OK, I will ask central support how we can perform peer review of binary artifacts.
1 Like
I got a complete answer from Sonatype. I will copy it directly, it is simpler:
Thank you for this feedback. For users who are publishers on the namespace, we rolled out a
feature today that allows publishers to view deployments associated with their authorized
namespaces. We intend to tweak this feature further to improve the UX (which we will describe
below), but we are quite busy with addressing support requests that are preventing publishers
from deploying entirely, given the sunset of OSSRH.
On https://central.sonatype.com/publishing, click the filter icon. That will cause a panel to appear
on the right side of the screen. Select the namespace and then click "Apply Filters" to see the
deployments.
<some screenshots here>
The UX adjustment that we intend to make is displaying all deployments that you have access
to by default instead of just the ones that you uploaded yourself.
As for the public URL, we do not have plans to make the deployments publicly accessible at this
time. We have received feedback from a few projects that perform a voting process that have
expressed a similar request. We do have plans on our roadmap for organizations, which
contains the feature of roles associated with permissions (e.g. some users should be
administrators on a namespace, some only publishers, and so forth). One of the roles that we
have in mind would be a reviewer. They would have access to download files and observe
deployments, but not publish or drop them. Would that meet your needs? If not, would you mind
giving us more information on your specific requirements?
For context, one of the reasons that deployments are private is that publishers have expressed
the need to keep security vulnerability releases private as they go through the release process
and so they prefer this over how the OSSRH process worked.
We noticed that you are using GitLab as your source repository. As a temporary solution, would
using [job artifacts](https://docs.gitlab.com/ci/jobs/job_artifacts/) or
[releases](https://docs.gitlab.com/user/project/releases/) meet your needs for publicly available
download URLs for voting purposes? Or is it specifically being a Maven repository important to
your process?
I also told them I could not find a way to remove spurious files added by the maven plugin (for an unknown reason, the plugin generates both -sources archives and .sources archives, and we used to remove the latter), which seemed not to be possible anymore. Here is their answer:
The current API does not allow you to modify the bundle after it is uploaded. We may provide
something similar to what was possible in OSSRH in the future, but that would be significantly
down the road, given the other work on our roadmap that is higher priority. Given that, if building
the bundle yourself allows you to have the control you need over the included files, we would
suggest that option.
So in my humble opinion, the filtering feature is a good step forward, but would not be sufficient for us. I really like the fact the anyone in the community can review artifacts and vote on them, not only the publishers.
So I think I will adapt the process and the release script as follows:
- don’t use the plugin anymore, but build the bundle with the files I need (and only the files I need) by myself
- upload these files to our project Nexus instance
- start the vote from there
- if the vote succeeds, download the artifacts from our Nexus instance and then upload them to central portal (this time we could use auto-publish)
So basically the idea would be to delay the use of central portal only to the very final step: making available the artifacts only after the vote.
Perhaps instead of building and uploading on Nexus, we could rely on the CI, this would be better from a quality point of view as only things built by the CI would ever be published. I like this idea but don’t know yet how to insert wait for a remote built in the release script. Perhaps having the release script entirely driven remotely by the CI would be possible?
This seems to me to be the strategy that best meets our needs.
We could perhaps add a manual job in the CI/CD pipeline or create a dedicated pipeline, i.e., a job that only starts under certain conditions, such as a manually launched pipeline for which we would have declared an environment variable:
This strategy will offer a huge advantage over the current situation: artifacts published on Maven Central will be those published in our Nexus instance. We will only have one binary archive, one checksum, and one signature for a given version.
1 Like
On second thought, we don’t even need a manual job, because we can filter the execution of the publish job on Maven Central, requesting that it only be executed if the tag matches the pattern X.Y.Z (and not X.Y.Z-RCN or X.Y.Z-SNAPSHOT).
2 Likes
Hi guys,
is there anything I can do to help out for this and version 13.1?
I don’t have a unix env at hand just now, but I can maybe set one up.
Cheers,
Romain.
I need to set up a staging repository on our Nexus instance. I will see if I can do that this week end.
Unfortunately, for now release will be automated only on Linux. Perhaps later on we could replace the shell scripts by Python scripts that could run also on Windows, but I don’t have the skills to do that.
I can’t create a staging repository, I don’t have the administration credentials.
Maybe @sdinot could, but I think he is not available yet.
OK, I am still working (a lot) on this.
I finally think we should just keep the existing repositories already configured in Orekit Nexus instance as is (i.e. just maven-releases and maven-snapshots). We should however change the assumptions and state to everyone that the maven-releases repository holds upcoming releases before they are official, i.e. it will act as a staging repository.
The officially released artifacts should only be on central repository after the vote.
The reason for this change of paradigm is that it seems to me difficult to set up a maven-staging repository where Orekit community could vote, and then to just move the artifacts (without changing a single bit to them) from maven-staging to maven-releases and also to central repository. The maven deploy goal does recompile everything, it does not just move files around, and the maven-releases repository seems unneeded if everything is anyway on central repository.
So I am still doing some experiments (currently looking at automated signing of artifacts). I hope I will finally find some way forward soon.
3 Likes
Some news about the release process.
I have made significant progress but am still struggling with glab, which is a command line tool for connecting to GitLab.
As the release-* branches are protected, I cannot just commit locally and push the modifications. I have to create the branch remotely, then create another branch with a non-protected name for the release candidate, push to it, then create a merge request from the non-protected release candidate branch to the protected release branch, then accept the merge request. All these steps are done using glab.
Once this is done, the Continuous Integration will be triggered automatically on the release branch, and it will compile, sign, and deploy the binary artifacts to our Nexus instance. I also want to monitor the pipeline, and I use glab ci status --live for this.
When I do these steps from a terminal, it seems to work. When I do this from the shell script, it fails when attempting to create the merge request. I don’t know why. Perhaps there is some race condition as the scripts launches the commands fast one after the other, but I am not sure.
I will try again later on, but for now I am exhausted and demoralized.
Hi Luc,
Thank you for all this!
Just a remark. About protected branches, instead of having a blanket “release-X” rule, we could have a few like “release-12.X”. And for the number still in use (13 at the moment), one per release. This way release-13.1 wouldn’t be protected already.
Cheers,
Romain.
Thank you for all your hard work, Luc !! I’d like to help, but I’m terribly bad at Shell…
1 Like
This would not be sufficient, because when we perform patch releases, we indeed add things to an existing branch that was considered protected. So we have to be able to work with protected branches.