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

Hi,

On Tue, 2 Jun 2026 at 19:53, Andres Freund <andres(at)anarazel(dot)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(at)anarazel(dot)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