public inbox for [email protected]  

help / color / mirror / Atom feed

From: Jelte Fennema-Nio <[email protected]>
To: Andres Freund <[email protected]>
Cc: Nazir Bilal Yavuz <[email protected]>
Cc: Thomas Munro <[email protected]>
Cc: [email protected]
Subject: Re: Heads Up: cirrus-ci is shutting down June 1st
Date: Wed, 27 May 2026 22:33:30 +0200
Message-ID: <CAGECzQQBCF=HSk4eCc1fEYTpCt59rgpcwWp47+6M-CDMYEaM2A@mail.gmail.com> (raw)
In-Reply-To: <qe4lh2i5di2gh7bxkbfisifaohrvyfukbybwxwzxdnll45hnt3@luod7i2mon67>
References: <3ydjipcr7kbss57nvi67noplncqhesl5eyb6wgol4ccjxynspv@yatlykpribmm>
	<[email protected]>
	<CAN55FZ30Np67cATsqYxF1SsP598VoRv4hJQZ4w9RA3Qe55prnQ@mail.gmail.com>
	<CAN55FZ13uX0cLSbgtSnnFeh5sTLeMr7+8UzmqpU6QjOtrRJTLg@mail.gmail.com>
	<qe4lh2i5di2gh7bxkbfisifaohrvyfukbybwxwzxdnll45hnt3@luod7i2mon67>

I didn't look at the patch, and I won't be able too before June 1st.
But I wanted to give some quick context on the things andres called
out, that I'm pretty sure originate from the patch I submitted.

On Wed, 27 May 2026 at 20:10, Andres Freund <[email protected]> wrote:
> > +# NB: intentionally NO workflow-level `concurrency:` block. The native
> > +# concurrency mechanism makes a new run wait for the previous one to fully
> > +# cancel before it starts — which can take a while. Instead the
> > +# `cancel-previous` job below fires a cancel API call asynchronously,
> > +# so the new run gets going immediately. On master the cancel job is skipped,
> > +# so every push runs to completion.
>
> Is this really worth having our own code? Seems like it'd not be that frequent
> to push if there are already running runs?  What kind of delays are we talking
> about?

I agree this doesn't pull its weight and can be removed. It was part
of me trying to iterate quickly. I think it could take a few minutes
to cancel some of the jobs BSD nested virtualized jobs (might have
been other jobs though).

> I wonder if we should split the meson task into two, one for 32bit and one for
> 64bit.

+1

> > +      # Install dependencies via Homebrew rather than Macports. On stock
> > +      # GH runners macports requires a heavy bootstrap, and the relevant
> > +      # Postgres deps are all available in brew.
>
> What does "heavy bootstrap" mean?

Not sure. This was Claude's doing. MacOS was green pretty quickly, so
I didn't bother questioning details while all the other builds were
still red.

> We do spend ~95s on this every run, that's not nothing. And it puts a bunch of
> load onto the brew's mirrors to do that every run.

I think we can only avoid that if we have our own runners.

> > +      # The TAP tests build an initdb template under build/tmp_install and
> > +      # then `robocopy` it into per-test data directories. Robocopy with the
> > +      # default /COPY:DAT flag doesn't copy ACLs — destinations inherit from
> > +      # their parent dir. On GitHub-hosted Windows runners the workspace's
> > +      # inherited ACL grants Administrators:(F) and Users:(RX) but does NOT
> > +      # grant the runner user (runneradmin) directly. That matters because
> > +      # pg_ctl on Windows uses CreateRestrictedProcess to drop admin
> > +      # privileges from postmaster, so the postmaster process has the user
> > +      # SID in its token but no longer the Administrators group — leaving it
> > +      # with only "Users:(RX)" on pg_control and friends, which causes
> > +      # "PANIC: could not open file global/pg_control: Permission denied".
> > +      #
> > +      # Fix it once on the workspace dir with (OI)(CI) inheritance flags so
> > +      # every file/dir created underneath gets an explicit grant for the
> > +      # current user.
> > +      - name: Grant workspace ACL to runner user
> > +        shell: pwsh
> > +        run: |
> > +          icacls "${{ github.workspace }}" /grant "${env:USERNAME}:(OI)(CI)F" /Q | Out-Null
> > +          Write-Host "Granted Full Control to $env:USERNAME on ${{ github.workspace }}"
>
> Perhaps this would be better to fix by changing the robocopy flags?

Getting the Windows build working took a lot of work. To be clear that
involved me copy-pasting log output into Claude or pointing it to
download log tarballs. All of these huge comments I *did not* write.
While iterating the comments seemed believable (but LLMs are good at
that). My intent was to review them for correctness and for cleaner
solutions. But I did not have time nor energy for that anymore. So
yeah other fixes might very well be better (similarly for the
python3 or openssl stuff).

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected]
  Subject: Re: Heads Up: cirrus-ci is shutting down June 1st
  In-Reply-To: <CAGECzQQBCF=HSk4eCc1fEYTpCt59rgpcwWp47+6M-CDMYEaM2A@mail.gmail.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox