pg-tle-test: extend to the 0.9.6 -> current update path via DESTDIR sandboxing - #39
pg-tle-test: extend to the 0.9.6 -> current update path via DESTDIR sandboxing#39jnasbyupgrade wants to merge 1 commit 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 |
Code reviewNo issues found. Checked for bugs and CLAUDE.md compliance. |
c3e0736 to
f058f2b
Compare
Code reviewNo issues found. Checked for bugs and CLAUDE.md compliance. |
f058f2b to
7da0baf
Compare
…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>
7da0baf to
cf1913b
Compare
pgxntool 2.3.0's installcheck-ordering fix (pgxntool#83) made
installcheck(and so
make test) unconditionally depend oninstall, 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 apg_tle-deployed database never needs those files), pre-seeding a stub
pgtap.control at the DESTDIR-prefixed path pgxntool's
pgtapprerequisitechecks 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 thecount_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