Skip to content

feat: derive build matrix from distros and PG versions in extension's metadata#251

Merged
mnencia merged 7 commits into
mainfrom
dev/242
Jul 8, 2026
Merged

feat: derive build matrix from distros and PG versions in extension's metadata#251
mnencia merged 7 commits into
mainfrom
dev/242

Conversation

@NiccoloFei

@NiccoloFei NiccoloFei commented Jun 19, 2026

Copy link
Copy Markdown
Contributor

Description

Previously the build matrix was the cross-product of two hardcoded lists
(distributions × pgVersions), which forced:

  1. Every extension to build for each distribution defined in the list
  2. Every distribution to share the same exact set of PostgreSQL majors (custom combos were not allowed)

Compute the matrix instead from the explicit (distro, PgMajor) pairs declared in metadata.versions, so each extension can declare their own valid combinations:

  • docker-bake.hcl:

    • getBuildMatrix(): collapse the two distributions/pgVersions default variables into a single build
      object that contains explicit pairs of (distro, pgVersion), deriving them from metadata.versions
    • getBuildName() function to centralize the target name generation (this is useful because extension's that want to override variables or add extra args need to declare the correct bake target name inside metadata.hcl)
  • dagger/maintenance: mirror the new bake logic in the dagger module. buildMatrix now holds explicit []buildCombo pairs with hasDistribution/contains helpers and deterministic ordering.

    • parseBuildMatrix() now parses the extension's metadata.hcl directly instead of using bake.ParseFiles() and resolving both docker-bake.hcl + metadata.hcl together. Given that, github.com/docker/buildx is no longer needed and has been dropped as a module dependency (hence why all those indirect deps have been removed).
  • UpdateOSLibs and GenerateCatalogs updated accordingly.

  • Added unit-tests for buildMatrixFromMetadata() and buildMatrix methods.

  • Fixed load order between docker-bake.hcl and metadata.hcl to ensure per-extension overriding/appending of labels/annotations/args etc. now works properly.

Type of change

  • Update to an existing extension (version bump, fix)
  • Shared build infrastructure / tooling change
  • Documentation only
  • Other (please describe above)

Closes #242


Contributor checklist

  • My commits are signed off for DCO
    compliance (git commit -s).
  • This PR targets the main branch of the upstream repository.
  • task checks:all passes locally.
  • For changes affecting one or more extensions, the relevant build and E2E
    tests pass (e.g. task bake TARGET=<ext>, task e2e:test:full TARGET=<ext>).
  • Any // renovate: comments touched in metadata.hcl / README.md remain
    intact (suite=, depName=, extractVersion=).
  • Documentation (README.md, BUILD.md, ...) updated where relevant.

Maintainer review checklist

  • CI is green for all affected targets / shared changes.
  • DCO check passes.
  • Change reviewed for correctness and scope; no unintended targets rebuilt.
  • // renovate: annotations preserved so automated version tracking keeps
    working.
  • If shared infrastructure changed, the _shared filter in
    .github/workflows/bake.yml was updated when all extensions must rebuild.
  • PR targets main and is ready to merge.

@NiccoloFei NiccoloFei force-pushed the dev/242 branch 2 times, most recently from ef7e042 to 5268799 Compare June 24, 2026 17:09
@NiccoloFei NiccoloFei marked this pull request as ready for review June 25, 2026 11:48
@NiccoloFei NiccoloFei requested a review from a team as a code owner June 25, 2026 11:48
NiccoloFei and others added 5 commits July 7, 2026 12:07
… metadata

Signed-off-by: Niccolò Fei <niccolo.fei@enterprisedb.com>
Load order only matters for conflicts, e.g the same variable default or the same target attribute
defined in both files. There was never a data-dependency reason to put metadata first.
The override layering now works the intuitive way.
docker-bake.hcl is the shared base, metadata.hcl is the per-extension layer that
wins on conflicts (labels, args, file-level variable defaults), with annotations appending.

Signed-off-by: Niccolò Fei <niccolo.fei@enterprisedb.com>
Entries under requires.vars only support name and enum, there is no desc field in the schema.

Signed-off-by: Niccolò Fei <niccolo.fei@enterprisedb.com>
Signed-off-by: Niccolò Fei <niccolo.fei@enterprisedb.com>
Co-authored-by: Gabriele Fedi <gabriele.fedi@enterprisedb.com>
Signed-off-by: Niccolò Fei <niccolo.fei@enterprisedb.com>
mnencia added 2 commits July 8, 2026 17:13
parseBuildMatrix already parses metadata.hcl internally, so calling
it and then parseExtensionMetadata separately fetched and decoded
the same file twice per extension. Derive the matrix from the
already-parsed metadata instead.

Signed-off-by: Marco Nenciarini <marco.nenciarini@enterprisedb.com>
GenerateCatalogs re-parsed each extension's metadata.hcl for every
catalog (one per OS), even though the metadata never depends on the
catalog being processed. Hoist the parse above the catalog loop and
look it up by extension directory instead; the build matrix is
derived from it inline since that computation is pure and cheap.

Restore the original short-circuit on an empty catalog set by
checking it explicitly, right where the loop that used to guard it
started, so getExtensions still runs and can surface its own errors
first. This also makes the trailing catalogWritten bookkeeping dead
code, so drop it.

Signed-off-by: Marco Nenciarini <marco.nenciarini@enterprisedb.com>
@mnencia mnencia merged commit 9755a49 into main Jul 8, 2026
68 checks passed
@mnencia mnencia deleted the dev/242 branch July 8, 2026 16:22
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Cannot scaffold and build an extension that supports only Trixie

4 participants