Correct me if I read you wrong: *"you have added a timestamp, so you can update it to trigger the CI"*. Adding a timestamp creates an RM responsibility. It adds one extra manual step to the release procedure. And I am against this. (I think everybody should be against it.) Do you want to trigger the CI? There are, IMO, better alternatives you can take:
1. Fix a minor issue (e.g., typo) in docs – there are hundreds of them 2. Talk with INFRA so we can manually trigger workflows, which is not allowed right now due to the way they integrated GitHub Are you bothered with reusing the timestamp from the parent? Pass the precise timestamp at CI. My point is: You can solve your problem without creating yet another burden for the RM. On Fri, Oct 20, 2023 at 8:42 AM Piotr P. Karwasz <piotr.karw...@gmail.com> wrote: > Hi Volkan, > > On Thu, 19 Oct 2023 at 23:40, Volkan Yazıcı <vol...@yazi.ci> wrote: > > > > We shouldn’t manually provide a value each time. If you are adamant about > > it, we should ideally pass it from command line in CI workflow. But > again, > > not manually please. This undermines our objective of relieving RM’s > load. > > The real problem is: the CI does not start if `main == release/*`. I > tried a concurrency setting, but it doesn't seem to be enough. > > The timestamp bump mainly serves as an "intelligent" alternative to > "add whitespace to trigger CI run". > > BTW: there are WARNING messages in the build if the timestamp is > inherited from `logging-parent` instead of being set up in the repo. > > Piotr >
