Re: ci: Follow-up CI patches

Hi,

On 2026-11-04 09:36:03 -0500, Andres Freund wrote:
> Peter, after all of this, I'd like to backpatch CI back to where we used to
> have CI support. One of the things that makes that slightly more painful is
> that there already are divergences between 19 and master. I'd like to
> backport
>
> 2026-10-25 4075409de08 ci: Enable PCH in mingw cross job
> 2026-10-25 3ca57291ff3 ci: Convert CompilerWarnings job to meson
>
> to 19, to keep the divergences smaller.

> I think
> 2026-10-19 0f3b42ce806 Add missing dependencies to meson headerscheck target
>
> ought to be in 19 regardless of anything, given that meson headerscheck was
> added to 19?

I'll do those backpatches in the next hour, unless somebody protests soon.

> > @@ -154,7 +148,8 @@ jobs:
> > warn-if-not-opted-in:
> > name: Report if not opted into CI
> > if: ${{vars.PG_CI_ENABLED != '1'}}
> > - runs-on: ubuntu-slim
> > + # See the setup task for an explanation
> > + runs-on: ${{ case(vars.PG_CI_RUNS_ON_SETUP != '', vars.PG_CI_RUNS_ON_SETUP, 'ubuntu-slim') }}
> > steps:
> > - name: Warn
> > env:
> > ...
> > + runs_on_linux: ${{ case(vars.PG_CI_RUNS_ON_LINUX != '', vars.PG_CI_RUNS_ON_LINUX, 'ubuntu-24.04') }}
>
> I'd love if there were a neater way to do this, but I don't know of any :(.
>
> I'll play around with it to see if I can come up with something neater,
> particularly the repetition of the variable name is annoying.

It turns out one can just do ${{ vars.PG_CI_RUNS_ON_LINUX || 'ubuntu-24.04' }}.
Not super well documented, but looks to be fairly widely used. Think that's a
good bit neater.

Also worked on making the image: simpler. There's now one format() template
(still a long line), but the individual tasks now are
- image: ${{ needs.setup.outputs.container_linux_ci_base }}/linux-autoconf:${{ needs.setup.outputs.container_tag }}
+ image: ${{ format(needs.setup.outputs.container_image, 'linux-autoconf') }}

which seems a lot easier to read to me.

Here's a mildly polished version:

- Adoped the simpler runs-on: and image: formulations

- An AI review raised the following, which I addressed:

- location: ${{github.workspace}} is suboptimal, because it means that the
directory will be searched for logs in case of a failure. Testing shows
that setup-msys2 will pick a sane directory, so I think just not
specifying a directory makes sense

- CHERE_INVOKING is now obsolete

- The socket dir could end up with a too long path. I don't entirely remember
how I ended up with the previous formulation, I think it had to do with
issues around the paths in the container being different than outside.
The new formulation of just creating it in the container seemed better

- added the discussion links, dropped references, as mentioned in my earlier
email

What do you think?

Greetings,

Andres Freund