Re: ci: Follow-up CI patches

Hi,

On 2026-11-04 11:28:02 +0300, Nazir Bilal Yavuz wrote:
> Andres shared some CI patches in the 'Heads Up: cirrus-ci is shutting
> down June 1st' thread [1]. Since this thread is already quite long, I
> wanted to create a new thread for them.

Thanks!

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?

All: I'm planning to put all of these into both 19 and master, I don't want to
end up with different container names across branches, nor with a partial
ability to change which runner CI runs on. Speak up now, or forever hold your
piece :)

> - 0004-ci-Make-our-own-msys2-install-from-scratch-inst.patch
>
> 'msys2/setup-msys2(at)66cd2cce69caa17b53920067426061ca1de3a884 # v2.31.1'
> this SHA points to v2.32.0, it is fixed.

We should probably update it to v2.33.0 now. I'll do that, no need to send a
new version just for that.

> - 0007-ci-get-build-test-concurrency-from-environment.patch
>
> I used %NUMBER_OF_PROCESSORS% instead of 'bash -c nproc' to not depend
> on bash.

Ah, nice.

>
> - 0008-ci-Make-runs-on-overridable.patch
>
> Separatd MacPorts caches by runner architecture to avoid restoring
> incompatible binaries when changing runners.

Hm. I'd perhaps split that aspect out into is own commit.

> Subject: [PATCH v14 1/6] ci: get build/test concurrency from environment

LGTM, I think I'll test and then apply this.

> Subject: [PATCH v14 2/6] ci: Make msys2 install smaller
> Subject: [PATCH v14 3/6] ci: Make our own msys2 install from scratch, instead
> of moving

Dito.

> Subject: [PATCH v14 4/6] squash-or-drop: Use pacboy for shorter package names

Since there were no clear votes, I'm going to use a roll of dice to decide :)

More seriously, I am inclined to go with it, it seems possible that we'll want
to run CI on arm windows in the future, and due to the lack of environment
variables support in the install: block (at least i don't think there is),
that'll be more painful with the prefixes.

> Subject: [PATCH v14 5/6] ci: Make runs-on overridable
>
> Previously what runners CI ran on was hardcoded. Unfortunately that makes it
> harder to use faster or self hosted runners (e.g. in a private repository
> where the runners are very slow, or self hosted runners for cfbot).
>
> Fix that by allowing to override the runner types via repository/organization
> variables. How to do that is documented in src/tools/ci/README.
>
> Testing faster github hosted runners showed that we have some dependencies on
> specific locations, fix most of those. The MSYS2 installation changes are
> handled in a separate commit.

Note to self: I think this msys2 note should be dropped before pushing, given
that those were addressed in a preceding commit.

> Author: Andres Freund <andres(at)anarazel(dot)de>
> Co-authored-by: Nazir Bilal Yavuz <byavuz81(at)gmail(dot)com>
> Discussion: https://postgr.es/m/a2ejn7lfqolutzz7kozalbhy3bixdrujb4buc3pgbtlk4am2ba@wbv6v7riia33

Note to self^2: Add additional links.

> @@ -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.

Greetings,

Andres Freund