CI: derive changes job's PG floor from META.json instead of a hardcoded 10 - #51
Merged
jnasbyupgrade merged 1 commit intoAug 7, 2026
Conversation
…ed 10 META.json declares PostgreSQL 9.4.0 as count_nulls' true minimum (per META.in.json: "Depends on JSONB, created in 9.4"), but the changes job's PG-matrix derivation hardcoded FLOOR=10 with no explanation, leaving 9.4/9.5/9.6 permanently untested despite pgxn-tools' pg-start installing them fine on current Actions infra. Read the floor from META.json itself so the test matrix can't silently drift from the declared minimum again.
|
Important Review skippedAuto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Plus Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
jnasbyupgrade
merged commit Aug 7, 2026
b59056a
into
Postgres-Extensions:master
23 of 24 checks passed
jnasbyupgrade
added a commit
that referenced
this pull request
Aug 7, 2026
…oded majors old_pg=["10","12"] had no technical justification for the second leg (no dependency-version SQL, no other package tie) and old_pg=10 stopped being the real floor once #51 derived it as 9.4 from META.json. Add a floor_pg output to the changes job (same $FLOOR already computed for supported_pg, just re-emitted as a bare scalar like newest_pg) and drive both old_pg and new_pg from those single sources of truth instead of separately hardcoded literals. With only one leg left, the matrix.old_pg == '10'/'12' conditionals that used to pick which twin-database ordering(s) to run no longer make sense - both orderings now always run unconditionally.
jnasbyupgrade
added a commit
that referenced
this pull request
Aug 7, 2026
…g consumers The comments explaining supported_pg/newest_pg/floor_pg (and the newest_pg bare-scalar rationale) tied each output's reason for existing to a specific downstream job/feature (test's draft-PR matrix reduction, pg-upgrade-test's legs) and, for floor_pg, narrated the PR #51 history of the bug it fixed. Rework them to just state what each value is and its general purpose, so the comment doesn't need updating every time a new consumer is added or removed.
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
1 participant
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.
META.json declares PostgreSQL 9.4.0 as count_nulls' true minimum build prereq (META.in.json's comment: "Depends on JSONB, created in 9.4" - a real function, null_count(jsonb), genuinely needs it). But the
changesjob's "Derive the supported-PostgreSQL-major list" step hardcodedFLOOR=10with no comment explaining the gap, so 9.4/9.5/9.6 were never exercised by thetestmatrix even though pgxn-tools' pg-start installs them fine on current GitHub Actions infra.This reads the floor from META.json itself (
jq -r '.prereqs.build.requires.PostgreSQL' META.json) instead of a second hand-maintained constant, so the matrix can't silently drift from the declared minimum again. Handles the pre-10 X.Y major-version format (PostgreSQL switched from X.Y to a single integer starting at 10), and emitssupported_pgas a JSON array of strings ("9.4"isn't a valid bare integer token) so every leg - 10+ and 9.x alike - is a consistent type formatrix.pg.test's own matrix (pg: ${{ ... fromJSON(needs.changes.outputs.supported_pg) }}) and its steps only ever usematrix.pgin a job name label andpg-start ${{ matrix.pg }}- no arithmetic or package-name interpolation - so nothing else in that job needed to change.Out of scope / untouched:
pg-tle-test's matrix (a separately hardcoded, hand-intersected list that doesn't consumesupported_pg) andpg-upgrade-test(not on master yet, tracked separately on PR #31).