Add extension-update-test and pg-upgrade-stepwise CI jobs - #19
Open
jnasbyupgrade wants to merge 3 commits into
Open
Add extension-update-test and pg-upgrade-stepwise CI jobs#19jnasbyupgrade wants to merge 3 commits into
jnasbyupgrade wants to merge 3 commits into
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:
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
u-and-u-extension-update-ci
branch
from
August 9, 2026 19:46
7a1c538 to
7d038b9
Compare
jnasbyupgrade
force-pushed
the
u-and-u-extension-update-ci
branch
from
August 10, 2026 20:29
7d038b9 to
e4a302b
Compare
jnasbyupgrade
force-pushed
the
u-and-u-extension-update-ci
branch
2 times, most recently
from
August 10, 2026 21:49
749ea5f to
078c033
Compare
jnasbyupgrade
force-pushed
the
u-and-u-extension-update-ci
branch
from
August 10, 2026 22:03
078c033 to
63c9325
Compare
jnasbyupgrade
force-pushed
the
u-and-u-extension-update-ci
branch
from
August 10, 2026 22:54
63c9325 to
80aedc7
Compare
jnasbyupgrade
force-pushed
the
u-and-u-extension-update-ci
branch
from
August 10, 2026 23:17
80aedc7 to
2c2a2d9
Compare
jnasbyupgrade
force-pushed
the
u-and-u-extension-update-ci
branch
from
August 11, 2026 17:22
2c2a2d9 to
dccefe8
Compare
jnasbyupgrade
force-pushed
the
u-and-u-extension-update-ci
branch
5 times, most recently
from
August 11, 2026 19:52
b843e4c to
462a968
Compare
jnasbyupgrade
force-pushed
the
u-and-u-extension-update-ci
branch
from
August 11, 2026 22:12
462a968 to
e940f8c
Compare
…ting Adds the committed install->guard->update->assert->run-suite script (bin/test_existing, modeled on cat_tools's bin/test_existing) plus a generic per-extension structural-diff tool (bin/structural_diff[.sql], copied near-verbatim from cat_tools -- it's already written generically off pg_depend's deptype='e' membership edge) and a new CI job that exercises the 0.1.0->stable update path end to end: install 0.1.0, plant + prove the dependency guard, ALTER EXTENSION UPDATE, structurally compare against a fresh "stable" install, then run the full suite in existing mode. No binary pg_upgrade job is added: object_reference has no view/function that SELECTs * over a system catalog in either its current or 0.1.0 install script (checked directly), so the cross-PostgreSQL-major risk that job protects against is low here. Left as noted future work rather than built preemptively -- see the ci.yml "Test strategy" comment and the PR description. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Adds the binary pg_upgrade coverage this PR previously deferred: ONE
cluster starting at the floor PostgreSQL major with 0.1.0 installed,
updated straight to the current version, then climbing every later
supported major in sequence via a real binary pg_upgrade, running the
full suite (existing mode) and re-proving the dependency guard after
every step.
Per review of advanced-extension-testing.md's guidance: "unlikely to
catch anything today" (no SELECT * over a system catalog found in
object_reference's views/functions) is a weaker, non-self-correcting
reason to skip a cheap job than a genuine cost argument -- an
extension can grow catalog-touching code later without anyone
revisiting a stale "skip, it's simple" decision.
- bin/test_existing: add `prepare-old DB [INSTALL_VERSION]`, refactored
out of update-scenario's existing create+guard logic. Simpler than
cat_tools's own (no BRIDGE_TO parameter) since 0.1.0 has no identified
pg_upgrade-unsafe construct to bridge away from.
- .github/workflows/ci.yml:
- `changes` job now also derives `climb_pg`, an ascending PG-major
list from the same NEWEST/CURRENT_FLOOR constants the `test` job's
matrix already uses -- no separate LEGACY_FLOOR, since 0.1.0
installs cleanly across the whole supported range.
- New `pg-upgrade-stepwise` job, gated behind lint+test like
extension-update-test.
- `all-checks-passed` needs updated to include it.
- Top-of-file "Test strategy" comment updated: pg_upgrade coverage is
no longer deferred.
make lint clean.
Move the _sentry_mv / binary-pg_upgrade root-cause analysis into a code comment on the job itself, so it's visible to anyone reading ci.yml directly, not just in the PR description.
jnasbyupgrade
force-pushed
the
u-and-u-extension-update-ci
branch
from
August 11, 2026 22:40
e940f8c to
76f7997
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.
Adds
bin/test_existing(install→guard→update→assert→run-suite, modeled onPostgres-Extensions/cat_tools's own script of the same name) andbin/structural_diff, then wires two CI jobs on top of #18's localtest/install/load.sqlmachinery:extension-update-test(0.1.0→stableviaALTER EXTENSION UPDATE, structurally compared against a fresh install, then the full suite run against the real updated database) andpg-upgrade-stepwise(a binarypg_upgradeclimb from the floor PostgreSQL major through every later supported major, re-proving the dependency guard at each step).bin/test_existingsubcommands:plant-guard,update,prepare-old,run-suite,update-scenario,diff-fresh.prepare-oldomits cat_tools'sBRIDGE_TOparameter, andupdate-check/update-check-versionaren't included — neither applies to this repo (see the script's own header for why).bin/structural_diff/bin/structural_diff.sql: generic per-extension structural comparison, copied from cat_tools without modification (already written generically, no cat_tools-specific object names). Wired intoupdate-scenarioasassert_matches_fresh.extension-update-testruns on a single PostgreSQL major (the newest supported) —0.1.0has no identified PostgreSQL-version floor, so crossing the full matrix would add job count with no added coverage.pg-upgrade-stepwiseclimbs the full matrix (12→18) on one cluster via a real binarypg_upgradeper step; thechangesjob now also derivesclimb_pg(the ascending major list) from the sameNEWEST/CURRENT_FLOORconstants thetestjob's matrix already uses.all-checks-passed'sneeds:list and the top-of-file "Test strategy" comment are updated for both new jobs.bin/test_existing's version assertion derives the current version frommake -s print-EXTENSION_object_reference_VERSION, notprint-PGXNVERSION(which cat_tools's own script uses) — this repo'sPGXNVERSIONis frozen at0.1.0(the last real numbered PGXN release) and no longer tracks the current build'sdefault_versiononce thestablepseudo-version is in play, so the two diverge here in a way they don't for cat_tools.Known issue:
pg-upgrade-stepwisecurrently failsThe job's first binary
pg_upgradestep fails restoring_sentry_mv(pg_class heap OID value not set when in binary upgrade mode) — a materialized view markedpg_extension_config_dump()cannot survive binarypg_upgrade. Confirmed as a general PostgreSQL limitation (reproduced independently against a bare, non-extension materialized view in a scratch cluster), not specific to this extension's own code. Fixing_sentry_mvneeds a maintainer decision, since it's load-bearing for this extension's restore-repair contract —pg-upgrade-stepwise/all-checks-passedwill stay red until that's resolved separately.lint, thetestmatrix, andextension-update-testare all green.Also confirmed:
diff-freshexits non-zero on a genuine structural divergence (verified by deliberately corrupting a comment on a real table post-update), and itsEXITtrap still drops the scratch reference database even when the failure isn't the trap-registering subshell's last command.Co-Authored-By: Claude noreply@anthropic.com