Skip to content

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

Open
NiccoloFei wants to merge 5 commits into
mainfrom
dev/242
Open

feat: derive build matrix from distros and PG versions in extension's metadata#251
NiccoloFei wants to merge 5 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.

… 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>
@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 3 commits June 25, 2026 15:14
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>
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

2 participants