Skip to content

pg-tle-test: extend to the 0.9.6 -> current update path via DESTDIR sandboxing - #39

Draft
jnasbyupgrade wants to merge 1 commit into
phase6b-compare-in-pg-upgrade-testfrom
pgtle-update-and-report
Draft

pg-tle-test: extend to the 0.9.6 -> current update path via DESTDIR sandboxing#39
jnasbyupgrade wants to merge 1 commit into
phase6b-compare-in-pg-upgrade-testfrom
pgtle-update-and-report

Conversation

@jnasbyupgrade

Copy link
Copy Markdown
Contributor

pgxntool 2.3.0's installcheck-ordering fix (pgxntool#83) made installcheck
(and so make test) unconditionally depend on install, which writes a real
.control file to disk - defeating the whole point of a pg_tle-only-deployment
proof, and with no upstream fix yet (pgxntool#90). bin/test_existing's
run_suite gains a TEST_EXISTING_DEPLOY=pgtle mode that instead redirects
make test's install step through a scratch DESTDIR (harmless here since a
pg_tle-deployed database never needs those files), pre-seeding a stub
pgtap.control at the DESTDIR-prefixed path pgxntool's pgtap prerequisite
checks for - otherwise its DESTDIR-blind recipe (pgxn install pgtap --sudo)
would trigger a real, unwanted reinstall against the scratch dir.

Also fixes test/install/load.sql's existing-mode assertion, which cross-checks
the installed version against pg_available_extensions.default_version -
that view never sees pg_tle registrations (it only reads .control files off
disk), so it would return NULL under a pg_tle deployment even though CREATE
EXTENSION resolves correctly through pg_tle's own catalog. A new
count_nulls.test_existing_deploy GUC (driven by the same TEST_EXISTING_DEPLOY
var, Makefile-exported like TEST_SCHEMA/TEST_LOAD_SOURCE) selects
pgtle.available_extensions() instead when deploy=pgtle.

The pg-tle-test CI job now installs count_nulls at 0.9.6 into a second
scratch database (inheriting the job's template1 pg_tle registration),
plants + proves the dependency guard, ALTER EXTENSION UPDATEs to current,
then runs the real pgTAP suite against it via the new mode - with
bin/assert_fs_clean verify checked after every one of those steps, not just
at the end, since that's what actually proves the DESTDIR sandboxing worked.

Verified locally (no real pg_tle in this container): confirmed via
mtime comparison that the real count_nulls.control and pgtap.control are
untouched by a full prepare-old/update/run-suite(pgtle) cycle, that the
scratch DESTDIR is cleaned up on both success and a forced regression
failure (EXIT trap surviving set -e), and exercised the
count_nulls.test_existing_deploy branch in load.sql against a stubbed
pgtle.available_extensions() function. The genuine pg_tle-registered
version needs a real CI run to confirm end to end.

🤖 Generated with Claude Code

@coderabbitai

coderabbitai Bot commented Aug 4, 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: 11912ad5-c742-44b1-a3f3-378b2ebe3319

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

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.

@github-actions

github-actions Bot commented Aug 4, 2026

Copy link
Copy Markdown

Code review

No issues found. Checked for bugs and CLAUDE.md compliance.

@jnasbyupgrade
jnasbyupgrade force-pushed the pgtle-update-and-report branch from c3e0736 to f058f2b Compare August 4, 2026 20:14
@jnasbyupgrade
jnasbyupgrade changed the base branch from phase6-compare-and-report to phase6b-compare-in-pg-upgrade-test August 4, 2026 20:14
@github-actions

github-actions Bot commented Aug 4, 2026

Copy link
Copy Markdown

Code review

No issues found. Checked for bugs and CLAUDE.md compliance.

@jnasbyupgrade
jnasbyupgrade marked this pull request as draft August 4, 2026 21:11
@jnasbyupgrade
jnasbyupgrade force-pushed the pgtle-update-and-report branch from f058f2b to 7da0baf Compare August 4, 2026 21:34
…andboxing

pgxntool 2.3.0's installcheck-ordering fix (pgxntool#83) made `installcheck`
(and so `make test`) unconditionally depend on `install`, which writes a real
.control file to disk - defeating the whole point of a pg_tle-only-deployment
proof, and with no upstream fix yet (pgxntool#90). bin/test_existing's
run_suite gains a TEST_EXISTING_DEPLOY=pgtle mode that instead redirects
`make test`'s install step through a scratch DESTDIR (harmless here since a
pg_tle-deployed database never needs those files), pre-seeding a stub
pgtap.control at the DESTDIR-prefixed path pgxntool's `pgtap` prerequisite
checks for - otherwise its DESTDIR-blind recipe (`pgxn install pgtap --sudo`)
would trigger a real, unwanted reinstall against the scratch dir.

Also fixes test/install/load.sql's existing-mode assertion, which cross-checks
the installed version against pg_available_extensions.default_version -
that view never sees pg_tle registrations (it only reads .control files off
disk), so it would return NULL under a pg_tle deployment even though CREATE
EXTENSION resolves correctly through pg_tle's own catalog. A new
count_nulls.test_existing_deploy GUC (driven by the same TEST_EXISTING_DEPLOY
var, Makefile-exported like TEST_SCHEMA/TEST_LOAD_SOURCE) selects
pgtle.available_extensions() instead when deploy=pgtle.

The pg-tle-test CI job now installs count_nulls at 0.9.6 into a second
scratch database (inheriting the job's template1 pg_tle registration),
plants + proves the dependency guard, ALTER EXTENSION UPDATEs to current,
then runs the real pgTAP suite against it via the new mode - with
bin/assert_fs_clean verify checked after every one of those steps, not just
at the end, since that's what actually proves the DESTDIR sandboxing worked.

Verified locally (no real pg_tle in this container): confirmed via
mtime comparison that the real count_nulls.control and pgtap.control are
untouched by a full prepare-old/update/run-suite(pgtle) cycle, that the
scratch DESTDIR is cleaned up on both success and a forced regression
failure (EXIT trap surviving `set -e`), and exercised the
count_nulls.test_existing_deploy branch in load.sql against a stubbed
pgtle.available_extensions() function. The genuine pg_tle-registered
version needs a real CI run to confirm end to end.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
@jnasbyupgrade
jnasbyupgrade force-pushed the pgtle-update-and-report branch from 7da0baf to cf1913b Compare August 4, 2026 23:17
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