Hey Piotr, > 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. > 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. > 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. > 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: 1. `./mvnw clean install` 2. `./mvnw clean verify artifact:compare` 3. Store the failure context (optional) How can we attach this sequence to a single (Maven?) profile? On Fri, May 5, 2023 at 11:13 PM Piotr P. Karwasz <piotr.karw...@gmail.com> wrote: > Hi Volkan, > > On Fri, 5 May 2023 at 10:47, Volkan Yazıcı <vol...@yazi.ci> wrote: > > Yet I get the team's sentiment on provenance and I agree with it. Yet the > > RC (release candidates) case is a bit muddy. I propose the following: For > > voting purposes, only share the commit ID, and only create a `rel/x.y.z` > > tag if the vote passes. > > > > This captures two conditions stated so far: > > 1. Not polluting the tag-space > > 2. Immutable references to release commits > > > > Unless you have objections, I will implement this for `l-l-tools` and > > `l-l-transform`. > > +1 > > Some remarks on my experience with the automatic release process: > > * 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`, > * we could reuse some Github Actions like > https://github.com/apache/maven-gh-actions-shared/tree/v3 > * 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. > * 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. > > Piotr >
