[AndrewJackson2020]

Currently we reuse a lot of CI config across the 3 extension repos. Many of the CI jobs do basically the same thing: xpg build, xpg test, etc. Keeping them consistent is already a chore. This PR attempts to centralize these configs with xpg.

For an example of how this would look in action I opened this corresponding PR to demonstrate
supabase/pg_net#329

[steve-chavez]

Hmm, looking at the result on https://github.com/supabase/pg_net/pull/329/changes I'm not sure if it's the right way.

For example, I've argued before we should provide a reusable Makefile in xpg and by doing so it's still introspectable (make --just-print) and overridable (via include in Makefile).

But the mechanisms are not there for CI actions, it forces you look at another repo.

[AndrewJackson2020]

Hmm, looking at the result on https://github.com/supabase/pg_net/pull/329/changes I'm not sure if it's the right way.

For example, I've argued before we should provide a reusable Makefile in xpg and by doing so it's still introspectable (make --just-print) and overridable (via include in Makefile).

But the mechanisms are not there for CI actions, it forces you look at another repo.

I mean even if we had a reusable Makefile that encompassed more operations we would probably still want a reusable GitHub actions workflow to ensure all repos are on the same versions of all actions, same runner OS versions for a given step (no situations where some style actions are on macOS and others are on linux, bumping OS version happens in xpg while other repos just bump the xpg version), same invocations of all xpg actions, etc.

[steve-chavez]

Yes I fully get that, the problem I'm talking about is that it seems chaotic for maintenance because it's not easy to override the YAML files per project (very likely the need arises). Some projects could want to run on a blacksmith runner instead of ubuntu-latest, run in an older pg version or have loadtests like pg_net/supautils.

[steve-chavez]

Maybe we what we should do instead is to encapsulate most of the logic independent from CI, like this one here could be a Makefile target (which aligns with #12).

[AndrewJackson2020]

Yes I fully get that, the problem I'm talking about is that it seems chaotic for maintenance because it's not easy to override the YAML files per project (very likely the need arises). Some projects could want to run on a blacksmith runner instead of ubuntu-latest, run in an older pg version or have loadtests like pg_net/supautils.

I think that the load tests can remain project specific (unless there is some underlying commonality that can be generalized across extensions). WRT runners, I suspect that we should just move to blacksmith runners across the board. I think CPU/image can be parameterized though. I believe that the test matrix can also be parametrized in case some repo wants to run pg12 or whatever.

[steve-chavez]

Ok cool, let's see how it goes.