Skip to content

ci: assert extension version dynamically against default_version#37

Open
jnasbyupgrade wants to merge 2 commits into
Postgres-Extensions:masterfrom
jnasbyupgrade:ci-dynamic-version-assert
Open

ci: assert extension version dynamically against default_version#37
jnasbyupgrade wants to merge 2 commits into
Postgres-Extensions:masterfrom
jnasbyupgrade:ci-dynamic-version-assert

Conversation

@jnasbyupgrade

@jnasbyupgrade jnasbyupgrade commented Jul 16, 2026

Copy link
Copy Markdown
Contributor

Problem

ci.yml asserted the extension version with hardcoded string greps like echo "$VERSION" | grep -q "0.2.2". Three such assertions existed:

  • pg-upgrade-test → "Verify extension version after upgrade"
  • extension-update-test → "Test upgrade from 0.2.0…"
  • extension-update-test → "Test upgrade from 0.2.1…"

This forced a hand-edit of the test on every release. The update test's job is to prove that ALTER EXTENSION … UPDATE (or pg_upgrade) reaches the current version, not to match a frozen literal.

Change

Each hardcoded grep is replaced with a dynamic assertion that compares the DB-reported installed version against the version that was built:

INSTALLED=$(psql -tAc "SELECT extversion FROM pg_extension WHERE extname = 'cat_tools'")
EXPECTED=$(make -s print-EXTENSION_cat_tools_VERSION 2>/dev/null | sed -n 's/.*set to "\(.*\)"$/\1/p')
echo "..."; echo "..."
test "$INSTALLED" = "$EXPECTED"

Why EXPECTED comes from make, not the database

An earlier revision read EXPECTED from pg_available_extensions.default_version. That value comes from the same make install the test is trying to validate. If something went wrong making the extension available to the database (wrong version's control file installed, extension not made available, etc.), then EXPECTED would be derived from that broken state — and INSTALLED == EXPECTED could pass spuriously because both sides reflect the same corruption.

Deriving EXPECTED from the build (make print-EXTENSION_cat_tools_VERSION, via pgxntool's print-% target) makes it authoritative and independent of the database. The assertion now verifies the DB-reported installed version against the build's source of truth, so it catches a broken or mismatched "make extension available" step that a DB-vs-DB comparison could not. stderr is discarded to drop a pre-existing, unrelated "overriding recipe" make warning.

The 0.2.1 case passes -d cat_tools_from_021 (the DB that step uses). Step names are made version-free.

This value (0.2.2 today) tracks control's default_version and will follow 0.2.3 then a future stable pseudo-version, so it stays release-agnostic with no edits. For the pg-upgrade-test leg, EXPECTED is the build's version and pg_upgrade preserves the installed version (that leg does not run ALTER EXTENSION … UPDATE).

CI-only change; no HISTORY.asc entry.

Replace the three hardcoded version greps (`grep -q "0.2.2"`) in the
pg-upgrade-test and extension-update-test jobs with a dynamic assertion
that compares the installed extversion to the extension's current
default_version, both read from PostgreSQL. This makes the update tests
release-agnostic: they prove UPDATE/pg_upgrade reaches the current
version without needing a hand-edit on every release. Step names are
also made version-free.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
@coderabbitai

coderabbitai Bot commented Jul 16, 2026

Copy link
Copy Markdown

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: cc57027c-0f63-474a-9d9f-57ff2ee59a22

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

  • 🔍 Trigger review
✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests

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.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

The previous approach read EXPECTED from pg_available_extensions.default_version,
which comes from the same make install the test is validating. A broken
"make extension available" step (wrong control installed, extension not made
available) would corrupt both INSTALLED and EXPECTED identically, so the
comparison could pass spuriously. Derive EXPECTED from the build instead
(make print-EXTENSION_cat_tools_VERSION) so it is authoritative and
independent of the database, while remaining release-agnostic.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.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.

1 participant