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
