Hi Volkan, On Mon, 15 May 2023 at 12:47, Volkan Yazıcı <vol...@yazi.ci> wrote: > > release deployment should **not** be triggered by a push. I should > > be a `workflow_dispatch` triggered manually with parameters (e.g. the > > release number). I almost triggered RC4 when merging `release/0.1.0` > > with `main`, > > Assuming that, as agreed, RC tags won't be generated by CI anymore, do you > still think this is a problem? Note that the entire release process > performed by CI is reversible. I personally really like the convenience of > "push a commit and see it getting released" compared to "push a commit, > trigger the job, and see it getting released". In particular, given "push a > commit" is often repeated many times.
What about triggering the release process when you push a tag with a specific format (e.g. `log4j-transform-0.1.1-rc1`) regardless of the branch? When I merge a PR I need to sign it. So I usually rebase the PR branch on top of main and push both branches. This way Github automatically closes the PR. That is why I would rather use something else for the release process to prevent errors due to muscle memory. > > we could reuse some Github Actions like > > https://github.com/apache/maven-gh-actions-shared/tree/v3 > > I did not know about that project, thanks for the tip. I have some > reservations about using an Apache-wide GHA template, but I support the > idea of moving the shared boilerplate to a central (Log4j?) repository. +1 for a `logging-log4j-actions` repo > > the CI build should use all bells and whistles. E.g. I will disable > > integration tests in the default build profile on `l-l-transform`, > > because it slows down builds considerably. But I want the CI to run > > them. > > I suppose you need to create a Maven profile that gets deactivated when the > `CI` environment variable > <https://docs.github.com/en/actions/learn-github-actions/variables#default-environment-variables> > is present and bind your tests to that profile. +1, I'll implement it in `l-l-transform`. > > a `verify-release` profile would be useful. There is no reason to > > verify build reproducibility manually. An `artifact:compare` execution > > should be able to do it. > > I am not able to follow here. Build reproducibility is tested in multiple > steps: What I meant is: it would be nice to have a `verify-release` profile so that PMC members can verify that their locally generated artifacts are identical with those in the Nexus staging repo. When a release vote comes out you just run something like: ./mvnw clean verify -Pverify-release -DstagingRepo=1234 Piotr
