Hi, On Tue, 2 Jun 2026 at 19:53, Andres Freund <[email protected]> wrote: > > On 2026-06-02 15:19:02 +0300, Nazir Bilal Yavuz wrote: > > +concurrency: > > + group: ${{ github.workflow }}-${{ github.ref }} > > + # Never cancel in-progress runs on master to ensure all commits are > > tested. > > + cancel-in-progress: ${{ github.ref != 'refs/heads/master' }} > > > concurrency: > > group: ${{ github.workflow }}-${{ github.ref }} > > - # Never cancel in-progress runs on master to ensure all commits are > > tested. > > - # FIXME: Should also not cancel REL_XY_STABLE > > - cancel-in-progress: ${{ github.ref != 'refs/heads/master' }} > > + # Never cancel in-progress runs on master or release branches, to ensure > > + # all commits are tested. > > + cancel-in-progress: ${{ github.ref != 'refs/heads/master' && > > !startsWith(github.ref, 'refs/heads/REL_') }} > > Experimenting with this, it actually seems neither really does what I think we > want. > > What I think we want is cirrus' behaviour, that is, not cancel workflows that > are on master/stable branches and, if on such a branch, allow multiple runs to > be in progress at the same time. > > The above achieves not cancelling workflows on those branches, but it does so > by waiting for the prior workflow to finish. Which I think is kinda bad, > because it makes it entirely possible to fall further and further behind. > > As-is, it'd afaik still cancel workflows, as soon as more than one workflow is > queued (we'd have to set queue: max to allow that). > > > Afaict what we should do is to instead set a unique group: when on a stable > branch. Something like > > concurrency: > # For anything other than stable branches, we want there to only be one > # workflow active for that branch. But on stable branches & master, we > # neither want to wait for prior runs, nor to cancel them, so that each > # separately pushed commit is tested. We achieve that by setting a unique > # concurrency group when on such a banch. > group: | > ${{github.workflow }}-${{ > case(github.ref == 'refs/heads/master' || > (startsWith(github.ref, 'refs/heads/REL_') && endsWith(github.ref, > '_STABLE')), > github.run_id, > github.ref) > }} > > seems to do the trick. > > > Does that make sense as an approach and goal?
You are right, I confirm that this approach solves the problem and I think this solution makes sense. >From another thread: On Tue, 2 Jun 2026 at 18:57, Andres Freund <[email protected]> wrote: > > On 2026-05-28 20:08:39 +0300, Nazir Bilal Yavuz wrote: > > > - Others have already mentioned about the potential for this to conflict > > > with downstream uses of GH Actions. I suggest renaming the file from > > > ci.yml to something like postgresql-ci.yml, so that there is no file > > > naming conflict or confusion. > > > > Done. > > I find postgresql-ci.yml a bit long, how about postgres-ci.yml or pg-ci.yml? I am okay with both but my choice would be postgres-ci.yml. -- Regards, Nazir Bilal Yavuz Microsoft
