pingtimeout opened a new pull request, #2383:
URL: https://github.com/apache/polaris/pull/2383
This PR is the next iteration of release automation. It builds on top of
#2156 and reuses the common bash libraries that were defined.
### Differences from the initial PR
* Release automation can only be triggered via Github Workflows. It is not
possible to perform a semi-automated release from a committer/PMC computer.
* It assumes that the following secrets are defined:
* `DOCKERHUB_USERNAME` and `DOCKERHUB_TOKEN` - the credentials that can be
used to push Docker images to Dockerhub
* `GPG_PRIVATE_KEY` and `GPG_PASSPHRASE` - the ASCII armored private key
that should be used to sign artifacts and its associated passphrase. The
associated public key is assumed to be added to the
[`KEYS`](https://downloads.apache.org/incubator/polaris/KEYS) file prior to
being entered here.
* `APACHE_USERNAME` and `APACHE_PASSWORD` - the credentials that can be
used to connect to the ASF SVN server **as well as** to the ASF Nexus server.
* All code that was used to perform release steps locally has been removed
to keep the PR as small as possible.
### Similarities with the initial PR
This PR builds on the same assumptions from the initial PR:
* Release cannot be fully automated as of today as there are concerns that
the release guide may not be comprehensive. Hence full automation is not
desirable yet.
* Release can only be semi-automated given that certain operations must be
manually performed by the release manager.
### Remaining known-unknowns
I can see that `apache/polaris` has [a `Nightly build` github
workflow](https://github.com/apache/polaris/actions/runs/17040500750) that
publishes snapshots every night to the Apache Nexus repository. In this
workflow's definition, I can find references two Nexus credentials
(`secrets.NEXUS_USER` and `secrets.NEXUS_PW`). However I cannot find any such
secret defined on https://github.com/apache/polaris/settings/secrets/actions,
nor am I sure whether those credentials can be used to interact with the ASF
SVN server. Some clarification is needed to ensure proper credentials
configuration.
### Example runs
I have used this PR to simulate the release of Polaris
99.98.97-incubating-rc1 on my own fork. No upload was performed, this is just
to prove out that things should be working as expected. You can find links to
the following workflow executions:
* This [Create Release
Branch](https://github.com/pingtimeout/polaris/actions/runs/17047641880)
workflow was used to cut the release branch with proper naming pattern:
`release/99.98.97-incubating`. It was run with `dry-run=0` so that the release
branch was actually created.
* This [Update version and Changelog for Release
Candidate](https://github.com/pingtimeout/polaris/actions/runs/17047650617)
workflow was used to set the Polaris version to `99.98.97-incubating`, update
the changelog and push the RC1 tag. It was also run with `dry-run=0` so that
the modifications were actually performed (on my fork only)
* From there, all subsequent workflows were run with `dry-run=1` so that no
interaction with any ASF server happened.
* This [Build and Publish Release
Artifacts](https://github.com/pingtimeout/polaris/actions/runs/17047712709)
workflow was run with `dry-run=1` to check the commands that would be executed,
if an actual release was to be performed. We can see the binaries would be
built, signed, checksum'ed and publish to ASF SVN and Nexus repositories.
* This [Build and Publish Docker
Images](https://github.com/pingtimeout/polaris/actions/runs/17047714039)
workflow shows that we would execute the two `./gradlew` commands to build and
publish the Docker images to docker hub, if `dry-run` was set to 0
* This [Build and Stage Helm
Chart](https://github.com/pingtimeout/polaris/actions/runs/17047715403)
workflow shows how Helm charts would be built, signed, checksum'ed and
published to the ASF SVN repository
* And finally, this [Publish Release After Vote
Success](https://github.com/pingtimeout/polaris/actions/runs/17047717342)
workflow shows how the artifacts would be moved from the dist dev space to the
dist release space on ASF SVN, the final release tag would be created and the
Nexus repository would be automatically released
### Next steps
If this PR is approved, it should be possible to use the `Create Release
Branch` and `Update Release Candidate` workflows to respectively cut the
release branch and set the RC version as well as create the RC tag.
### Recommendations for reviewers
* Please review the `releasey/release-process-flowchart.png` flowchart
first. It shows how each workflow participates to the overall release process.
It should substantially help make sense of the Github workflows for the rest
of the review.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@polaris.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
