Re: Heads Up: cirrus-ci is shutting down June 1st

Hi,

On Tue, 2 Jun 2026 at 19:53, Andres Freund <andres@anarazel.de> 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 <andres@anarazel.de> 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