ci: DRY the supported-PostgreSQL-major list to a single source#48
Merged
jnasbyupgrade merged 1 commit intoJul 22, 2026
Merged
Conversation
|
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:
✨ Finishing Touches🧪 Generate unit tests (beta)
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
force-pushed
the
ci-pg-version-dry
branch
3 times, most recently
from
July 22, 2026 23:11
6d7ea48 to
2f9b090
Compare
The supported PostgreSQL-major list was embedded in three places in ci.yml -- the test job matrix (12..18), the extension-update-test matrix (10 + 12..18) and the pg-upgrade-stepwise climb loop (11..18) -- so adding a future major meant editing all three. Centralize it: the changes job now derives all three lists from a single set of constants (NEWEST, CURRENT_FLOOR, LEGACY_FLOOR) and emits them as job outputs; the test and extension-update-test matrices consume them via fromJSON, and the stepwise loop iterates the derived climb list passed through env. Adding the newest major is now a one-line NEWEST bump. Pure refactor: the three consumers resolve to the same major sets as before (test=12..18, extension-update=10+12..18, stepwise climb=11..18). No new job is added, so all-checks-passed needs is unchanged. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
jnasbyupgrade
force-pushed
the
ci-pg-version-dry
branch
from
July 22, 2026 23:30
2f9b090 to
8d09c9b
Compare
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.
The supported PostgreSQL-major list was embedded in three places in ci.yml -- the
testjob matrix (12..18), theextension-update-testmatrix (10 + 12..18) and thepg-upgrade-stepwiseclimb loop (11..18) -- so adding a future major meant editing all three. This centralizes it to ONE source: thechangesjob now derives all three lists from a single set of constants (NEWEST,CURRENT_FLOOR,LEGACY_FLOOR) and emits them as job outputs. Thetestandextension-update-testmatrices consume them viamatrix: pg: ${{ fromJSON(needs.changes.outputs.<...>) }}, and the stepwise loop iterates the derived climb list passed throughenv:. Adding the newest major is now a one-lineNEWESTbump; the legacy PG10 floor is defined once (LEGACY_FLOOR) and reused by both the update matrix and the stepwise loop start.Pure refactor: the three consumers resolve to the same major sets as before (
test=12..18,extension-update=10+12..18, stepwise climb=11..18). No new job is added -- the derivation rides on the existingchangesjob, which every heavy job already needs -- soall-checks-passed's self-check (asserting every defined job is in itsneeds) still passes unchanged, and the docs-only gate still composes (changesalways runs and emits the lists; heavy jobs stay gated onneeds.changes.outputs.docs_only != 'true').