From 8647cf993ba329b7a35152a5ec1f81f377e38f81 Mon Sep 17 00:00:00 2001 From: jnasbyupgrade Date: Sat, 1 Aug 2026 16:13:33 -0500 Subject: [PATCH] Phase 5: cross extension-update-test/pg-upgrade-test with TEST_SCHEMA The novel piece this whole redesign was building toward: nobody in this org currently tests update/upgrade crossed with schema scenarios (checked directly - cat_tools' own extension-update-test/pg-upgrade-test matrices are PG-version-only, extension_tools has no U&U testing at all). Phase 2's schema-invariant assertion descriptions make this free - zero new expected-output files needed for either job, exactly as designed. - extension-update-test: added `schema: ["", Quoted]` to the matrix, TEST_SCHEMA env var - the job's own `make verify-results TEST_LOAD_SOURCE=update` picks it up automatically via Make's environment auto-import. - pg-upgrade-test: added the same schema axis (old_pg/new_pg were already plain matrix dimensions, not an `include:` list, so adding a third axis cross-products cleanly into the same 4 legs cat_tools would produce for 2 old_pg values x 2 schema values), and threaded matrix.schema through to bin/test_existing's prepare-old/run-suite calls (previously hardcoded to ""). Verified locally against PG17: prepare-old -> update -> run-suite passes end to end with TEST_SCHEMA=Quoted (previously only verified with an untargeted schema). Co-Authored-By: Claude Sonnet 5 --- .github/workflows/ci.yml | 33 +++++++++++++++++++++------------ 1 file changed, 21 insertions(+), 12 deletions(-) diff --git a/.github/workflows/ci.yml b/.github/workflows/ci.yml index 40bcbf2..481e069 100644 --- a/.github/workflows/ci.yml +++ b/.github/workflows/ci.yml @@ -10,21 +10,28 @@ # see TEST_SCHEMA in the Makefile). # extension-update-test -- IN-PLACE update: CREATE EXTENSION at 0.9.6 # then ALTER EXTENSION UPDATE (same PostgreSQL, -# no pg_upgrade), same PG matrix as test. +# no pg_upgrade), same PG x schema matrix as +# test. # pg-upgrade-test -- BINARY pg_upgrade: install 0.9.6 on an OLD # PostgreSQL major, binary-upgrade the cluster # to a NEWER major, then update the extension # to current - proves objects created on an # old server still work when read on a new -# one. A smaller old_pg/new_pg matrix (not the -# full PG matrix - by far the most expensive -# job here, installing two full PostgreSQL -# majors and running the real pg_upgrade -# binary per leg). +# one. A smaller old_pg/new_pg x schema matrix +# (not the full PG matrix - by far the most +# expensive job here, installing two full +# PostgreSQL majors and running the real +# pg_upgrade binary per leg). # pg-tle-test -- pg_tle DEPLOYMENT: fresh install registered # through AWS pg_tle's database-backed catalog # instead of a filesystem .control file. # +# test / extension-update-test / pg-upgrade-test all cross PostgreSQL major +# with the TEST_SCHEMA axis: without a schema specified at all (empty) and +# with one explicitly targeted, using a name that requires SQL identifier +# quoting. Every leg of every job passes against the SAME expected output - +# see test/README.md for how the suite stays schema/load-mode invariant. +# # `changes` is a cheap gate that lets the heavy jobs above skip themselves on # doc-only pushes, and also derives the shared PostgreSQL-major list those # jobs consume from a single set of constants. `all-checks-passed` is the @@ -191,9 +198,12 @@ jobs: matrix: # From the single source in the changes job. pg: ${{ fromJSON(needs.changes.outputs.supported_pg) }} - name: ⬆️ Extension update test on PostgreSQL ${{ matrix.pg }} + schema: ["", Quoted] + name: ⬆️ Extension update test on PostgreSQL ${{ matrix.pg }} (schema ${{ matrix.schema == '' && 'none' || matrix.schema }}) runs-on: ubuntu-latest container: pgxn/pgxn-tools + env: + TEST_SCHEMA: ${{ matrix.schema }} steps: - name: Start PostgreSQL ${{ matrix.pg }} run: pg-start ${{ matrix.pg }} @@ -221,8 +231,6 @@ jobs: # json/jsonb, nothing version-sensitive to break at a specific boundary. # Revisit if count_nulls ever grows something catalog-touching. # - # Not yet crossed with TEST_SCHEMA (a later phase adds that, once it can - # do so for both this job and extension-update-test together). pg-upgrade-test: needs: [changes] if: needs.changes.outputs.docs_only != 'true' @@ -230,7 +238,8 @@ jobs: matrix: old_pg: ["10", "12"] new_pg: ["18"] - name: 🔄 Binary pg_upgrade ${{ matrix.old_pg }} → ${{ matrix.new_pg }} + schema: ["", Quoted] + name: 🔄 Binary pg_upgrade ${{ matrix.old_pg }} → ${{ matrix.new_pg }} (schema ${{ matrix.schema == '' && 'none' || matrix.schema }}) runs-on: ubuntu-latest container: pgxn/pgxn-tools env: @@ -259,7 +268,7 @@ jobs: # the dependency guard, so a later accidental CASCADE drop anywhere # in this job cannot silently make the eventual existing-mode run # test a fresh install instead. - run: bin/test_existing prepare-old count_nulls_upgrade "" 0.9.6 + run: bin/test_existing prepare-old count_nulls_upgrade "${{ matrix.schema }}" 0.9.6 - name: Install PostgreSQL ${{ matrix.new_pg }} run: apt-get install -y postgresql-${{ matrix.new_pg }} postgresql-server-dev-${{ matrix.new_pg }} - name: Install count_nulls into new cluster @@ -298,7 +307,7 @@ jobs: # + updated database via --use-existing (so pg_regress does not # drop/recreate it) - a plain fresh `make test` would silently test # a fresh install instead of the migrated objects. - run: bin/test_existing run-suite count_nulls_upgrade "" + run: bin/test_existing run-suite count_nulls_upgrade "${{ matrix.schema }}" pg-tle-test: needs: [changes]