Uh oh!
There was an error while loading. Please reload this page.
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
f058f2bCompareCode reviewNo issues found. Checked for bugs and CLAUDE.md compliance. |
7da0baf to
cf1913bCompare4bda7ce to
bb51bbdComparebb51bbd to
e2e2498Compare7e47f01 to
bd83e37Comparebd83e37 to
0c2867dCompare0c2867d to
7b7e134Compare7b7e134 to
687a450Compare687a450 to
409741bCompare409741b to
9c65f64Compare9c65f64 to
78bd02cCompare78bd02c to
7b619c0Compare7b619c0 to
ebeefa7Compareebeefa7 to
b9cec5bCompareb9cec5b to
02c805dComparea18ee3b to
288bdccCompare…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>
288bdcc to
26ea3fbCompare
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