Ability to create and release staging repository in separate calls (e.g. after manual verification)
szpak opened this issue · 5 comments
Proposal by @vlsi placed originally here, extracted to a separate (this) issue.
I propose the following workflow:
Stage release artifacts
- As release manager starts the release, they decide release version. For instance, it could be
v1.0-rc1. The version could be configured in the sources or passed via parameters (it does not matter) initializeStagingRepositorytakes that version number, and puts it to the staging repository metadata. I'm not sure what are the possibilities, however, I'm sure the version can be put to the "comment" fieldinitializeStagingRepositoryproduces an@OutputwithstagingRepositoryId. It could save the id to file (files are commonly expected task inputs and outputs). It could provide the id viaProperty<String>.
Verify release
- Everybody might want to verify the artifacts. They know "release candidate index", and they can pass it to the build script, so it locates the relevant staging repository, dowloads the artifacts, and validates them.
Publish release
The release manager remembers "release candidate version" to be released, and it passes that parameter to the build script.
4) findStagingRepository(version=...) task queries Nexus, and it detects the staging repository id. Then regular closeRepositoryOrWhatever task could be used to close&promote the repository.
^^^ Note: the above is not something that must be used by everybody. It is just a sample.
Of course, one could combine all the tasks into a single Gradle execution.
In other words, I suggest using Nexus Server for storage of "repository id" rather than "repository extension".
The subsequent comment by @visi:
In 99.42% of the cases, users want reasonable comments for their staging repositories.
For instance, I have the following:
It corresponds to ~5 or so "release candidates".
The version tree between them looks as follows:
I have multiple "closed" repositories, and I can easily test each version individually, and later I can decide which one is better.
What if I want to promote v3.0-rc5 as the final release?
There's no clear way to tell which staging repository belongs to each RC number :(
On the other hand, if staging repositories did include user-provided reference (e.g. version number, git sha, or whatever else), then end user would be able to promote the relevant repository.
In other words, it would be possible to promote the release candidate by specifying a single rc index: ./gradlew publishDist -Prc=5
Note: as you might guess, I have built a lot of different release candidates, and I probably did ./gradlew clean in between. So I keeping rc index <-> staging repo id link in the build folder is not really an option.
I think we could add a stagingRepositoryId property to the InitializeNexusStagingRepository task and write it to a file. I don't see this as must-have for the initial release, though.
An output property sounds good for me. I'm not sure about the file. Where should it be kept (in build/)? How about the cleaning policy? Do you think that outdated id file could be problematic?
Ideally, the plugin should be able to infer the staging repository id based on the comment.
In other words: if user wants to release v3.0-rc5, then the plugin should enumerate the closed repositories, detect v3.0-rc5 there, and use its id.
I believe that is the best approach as it won't add an accidental dependency on the local filesystem.
I'd like to see this implemented as well. Ideally it would be implemented using the entire GAV (group:artifact:version) and not just the version. The reason is that some projects have a single account to publish more than one artifact. This would avoid problems for scenarios where two teams are publishing the same version but different artifacts at the same time.
Thinking about it a bit more it is likely that the strategy needs to be able to be customized for a multi-module build to work. Perhaps it should default to group:version instead.