feat: new release process using PRs #3422
Conversation
Signed-off-by: Adrien Mannocci <[email protected]>
|
Given the significant alterations to the release process introduced by this PR, I'm seeking feedback on its implementation. |
|
Is there any particular reason to use a separate PR for the version bump ? This is part of the usual release process, and merging non-snapshot version directly into main will make the CI attempt to build non-snapshot artifacts when merged which is not necessary. Ideally if everything is in the same PR, it means we only have to review the changes once, however in this case the commit that will be used to generate the release would be the HEAD~1 from the release branch (and not the state that we see in the PR review). Alternatively, we could have one PR with two reviews needed: one for the commit that generates the release binaries, then another one for the next snapshot version (which should only contain version changes in the |
Are talking about the PR to push changes in the major 1.x branch? |
My bad, I misunderstood which branch we were talking about here. The 1.x branch update will of course require a separate PR and that makes sense, I thought that it was bumping the agent version to the next snapshot, which is one of the commits that the release process does. |
There was a problem hiding this comment.
I cannot find the changes related to using the nexus staging rather than the production one. IIRC, that's configured in the settings.xml or pom.xml
| url: ${{ secrets.VAULT_ADDR }} | ||
| roleId: ${{ secrets.VAULT_ROLE_ID }} | ||
| secretId: ${{ secrets.VAULT_SECRET_ID }} | ||
| - name: "Build docker image" |
There was a problem hiding this comment.
I'd envision the release-from-pr.yml to consume the artifacts generated in the release.yml. This can help with ensuring that no artifacts need to be generated in two different places the ones in release.yml and the ones in release-from-pr.yml. But making the release-from-pr.yml to be the orchestrator.
There was a problem hiding this comment.
AFAIU, the docker build script will consume artifacts from the Sonatype repository since they aren't present locally.
There was a problem hiding this comment.
I'm not talking about the docker build image but a more generic aspect, I'd say the release.yml workflow shall be the one creating all the required artifacts, and the release-from-pr.yml workflow being the one promoting them - while promotion means interacting with Nexus, Docker, AWS or similar artifact managers.
There was a problem hiding this comment.
On side note regarding the docker build script, will it work when using the staging nexus repository? As I mentioned #3422 (review), this proposal will need to use the staging nexus repository, so releases won't be public available, only after the PR with the bumps is merged (that's the task in release-from-pr.yml).
The promotion in Nexus from staging to production could be done in a follow up. The process for the Release Manager, aka RM, could be something like:
- RM runs the
release.ymlworkflow with the relevant input parameters - RM waits for some notification regarding the PR with the bumps to be approved.
a) Once approved therelease-from-pr.ymlworkflow will do the remaining steps. - RM promotes from stating to production in Nexus (manually if no automated).
| @@ -12,28 +12,6 @@ on: | |||
| version: | |||
| description: 'The version to release (e.g. 1.2.3). This workflow will automatically perform the required version bumps' | |||
| required: true | |||
| update_changelog: | |||
There was a problem hiding this comment.
That's a good point. Let me try to reintroduce some of them where possible or relevant.
|
run docs-build |
|
Superseded by #3567 |
What is the change being made?
release.mainbranch.1.xmajor branch.Why is the change being made?
mainbranch even for the automation.