Conversation
ef7e042 to
5268799
Compare
GabriFedi97
approved these changes
Jun 26, 2026
hh24k
approved these changes
Jul 7, 2026
… 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>
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
approved these changes
Jul 8, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
Previously the build matrix was the cross-product of two hardcoded lists
(distributions × pgVersions), which forced:Compute the matrix instead from the explicit
(distro, PgMajor)pairs declared inmetadata.versions, so each extension can declare their own valid combinations:docker-bake.hcl:getBuildMatrix(): collapse the two distributions/pgVersions default variables into a singlebuildobject that contains explicit pairs of (distro, pgVersion), deriving them from
metadata.versionsgetBuildName()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 insidemetadata.hcl)dagger/maintenance: mirror the new bake logic in the dagger module.buildMatrixnow holds explicit[]buildCombopairs with hasDistribution/contains helpers and deterministic ordering.parseBuildMatrix()now parses the extension'smetadata.hcldirectly instead of usingbake.ParseFiles()and resolving bothdocker-bake.hcl+metadata.hcltogether. Given that,github.com/docker/buildxis 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()andbuildMatrixmethods.Fixed load order between
docker-bake.hclandmetadata.hclto ensure per-extension overriding/appending of labels/annotations/args etc. now works properly.Type of change
Closes #242
Contributor checklist
compliance (
git commit -s).mainbranch of the upstream repository.task checks:allpasses locally.tests pass (e.g.
task bake TARGET=<ext>,task e2e:test:full TARGET=<ext>).// renovate:comments touched inmetadata.hcl/README.mdremainintact (
suite=,depName=,extractVersion=).README.md,BUILD.md, ...) updated where relevant.Maintainer review checklist
// renovate:annotations preserved so automated version tracking keepsworking.
_sharedfilter in.github/workflows/bake.ymlwas updated when all extensions must rebuild.mainand is ready to merge.