Run pull-request AWS tests on the newest Python version only

[laughingman7743]

WHAT

• In test.yaml, the changes job now also outputs python-versions:
  • pull_request: the newest supported version only (["3.14"]).
  • schedule and workflow_dispatch: every supported version (["3.10","3.11","3.12","3.13","3.14"]).
• The full list is defined once, in the changes job's PYTHON_VERSIONS, with a comment to keep it in sync with the pyproject.toml classifiers. The newest version is its last element.
• test-suite.yaml takes a required python-versions input (a JSON array). Its matrix is now fromJSON(inputs.python-versions) instead of a fixed list. All three suites (test, test-sqla, test-sqla-async) pass the selected list.
• Job names stay <suite> / run (<version>).
• docs/testing.md:
  • The trigger table gets a "Python versions" column.
  • The dispatch sentence now says it runs every version.

WHY

Closes #850, part of #834 (the test account's bill for September is heading past $200).

• Cost Explorer shows the cost is almost all from Test workflow runs: about $19–37 on active days (not counting a one-off EC2 benchmark), versus $0.3 on 9/22, when nothing ran.
• Run AWS test suites only on ready pull requests and related changes #837 merged on 2026-09-26 at 07:00 UTC. Of the 30 Test runs after it, up to 2026-09-27:
  • 22 ran no AWS jobs (Draft).
  • 4 ran 5 AWS jobs (the PyAthena suite × 5 Python versions).
  • 4 ran 15 AWS jobs (3 suites × 5 Python versions), because their pull requests changed SQLAlchemy paths, pyproject.toml, or uv.lock.
• The AWS cost of a run is proportional to the number of Athena queries, and the queries are repeated for each Python version.
• With one version, a pull request runs 3 or 1 AWS jobs instead of 15 or 5, which should cut pull-request AWS cost by about 80%. This is an estimate that assumes each Python version issues about the same queries; Measure the CI cost after the #834 changes #846 measures the actual effect.

Trade-off:

• A regression that affects only an older Python version is found by the weekly run, a dispatch, or the pre-release run instead of on the pull request.
• The same applies to the dependency versions that uv.lock resolves differently by Python version. Pull requests test only the Python 3.14 set. The other sets are tested by the weekly run, a dispatch, or the pre-release run. Notably, pandas 2.3.3 (numpy 2.2.6) is locked only for Python 3.10, while 3.11+ get pandas 3.0.6. So a pandas 2-only regression in the pandas cursor is also found later. This stops mattering in 4.0.0, which supports pandas 3.x only (Raise the pandas and pyarrow minimum versions to tested versions #852) and drops Python 3.10 (Drop Python 3.10 support in 4.0.0 #864).
• To get the full matrix on a pull request, dispatch the Test workflow on its branch (gh workflow run test.yaml --ref <branch>), as before.

Merge order: this goes in before #862, to cut the test volume first. #862 will make the Release workflow run every suite on every Python version before publishing, so the reduced pull-request matrix cannot reach a release untested.

TEST

Tested commits: a2eb20a, and 738d64c (comment-only change: the versions comment no longer refers to the release gate).

• just scripts passed. This includes actionlint with ShellCheck on the embedded run script; SC2129 was fixed by grouping the outputs.
• just docs lint passed.
• The selection script was checked locally with the same jq expressions: pull_request → ["3.14"], other events → ["3.10","3.11","3.12","3.13","3.14"]. The versions stay strings, so 3.10 is not turned into 3.1.
• This pull request changes the Test workflows. When it is marked Ready, its own CI selects every suite (including SQLAlchemy and Spark) but only Python 3.14. The expected result is 3 AWS jobs: test / run (3.14), test-sqla / run (3.14), and test-sqla-async / run (3.14).

Not yet observed: that a schedule or workflow_dispatch run after merge still runs all 15 jobs. The next dispatch before a release, or the next weekly run, will show it, and after #862 the Release workflow itself runs the full matrix.

🤖 Generated with Claude Code

[laughingman7743]

Self-review round one (implementation behavior): CLEAN

Base 531185619465b809331a9a8cf2083884365de193, head a2eb20acf406a0e603ba37b562f1878c562e2c86.

Covered:

• .github/workflows/test.yaml
• .github/workflows/test-suite.yaml
• docs/testing.md

Checked:

• Version selection.
  • pull_request → jq -c '[last]' → ["3.14"].
  • Other events → the full list, emitted in the same grouped write as sqla=true and spark=true.
  • The values stay JSON strings, so fromJSON yields "3.10", not 3.1. Job names (run (3.10)) and the setup-python condition on '3.13'/'3.14' are unchanged.
• Skipped changes job. For Draft and fork pull requests, changes is skipped. The dependent suite jobs are then skipped as before, so the required python-versions input is never evaluated with an empty value.
• Callers. test-suite.yaml has three callers, all in test.yaml, and all three pass the input. No other workflow calls it (benchmarks.yaml and database-sweep.yaml do not).
• Branch protection. It has no required status contexts, so fewer matrix jobs on pull requests do not leave an expected check pending.
• actionlint (with ShellCheck on the run script) passes. SC2129 was fixed before this review.

No findings.

[laughingman7743]

Round-one follow-up (a2eb20acf406a0e603ba37b562f1878c562e2c86 → 738d64cf0939592ef4f395eb2a15c379689242de, same base 531185619465b809331a9a8cf2083884365de193): CLEAN

• The repair changes one comment line in .github/workflows/test.yaml, removing "which the Release workflow checks".
• No workflow logic changed: the PYTHON_VERSIONS value, both selection branches, and the outputs are identical.

[laughingman7743]

Self-review round two (claims, callers, operations): FINDINGS, PR description corrected (no code change)

Base 531185619465b809331a9a8cf2083884365de193, head a2eb20acf406a0e603ba37b562f1878c562e2c86.

Findings:

1. Claim: "Since Run AWS test suites only on ready pull requests and related changes #837, most Ready pull-request runs on 9/25–9/27 still ran 15 AWS jobs" was wrong. Run AWS test suites only on ready pull requests and related changes #837 merged at 2026-09-26 07:00 UTC, and the 9/25 runs predate it. Measured over the 30 Test runs after the merge:
   • 22 ran no AWS jobs.
   • 4 ran 5 AWS jobs.
   • 4 ran 15 AWS jobs.
     The description now states these counts.
2. Unstated trade-off. uv.lock resolves pandas 2.3.3 and numpy 2.2.6 only for Python 3.10, while 3.11+ get pandas 3.0.6 (and numpy 2.4.6/2.5.3). Pull requests on 3.14 therefore never exercise pandas 2 (the pandas>=1.3.0 range), and pandas 2-only regressions move to the weekly, dispatch, or pre-release run. This is now stated in WHY. The decision itself (newest only) is Run pull-request AWS tests on the newest Python version only #850's and is not changed here.
3. Claim: "cuts pull-request AWS cost by about 80%" is an estimate. It is reworded as one: it assumes each version issues about the same queries, and the actual effect is measured in Measure the CI cost after the #834 changes #846.
4. Claim: "$20–35 on active days": Cost Explorer shows about $19–37 per active day, excluding the one-off EC2 benchmark on 9/25. Corrected.

Checked and held:

• The docs table and the dispatch sentence match the workflow: PR → [last], schedule and dispatch → full list.
• The comment "keep in sync with the pyproject.toml classifiers, which the Release workflow checks" depends on Require a full Test run on the release commit before publishing #862 merging first, as stated in the PR.

Not observed: a post-merge dispatch or schedule run with 15 jobs (stated in TEST).

[laughingman7743]

Round-two follow-up (738d64cf0939592ef4f395eb2a15c379689242de): CLEAN, and the description was updated.

• The maintainer decided to merge this PR before Require a full Test run on the release commit before publishing #862. Require a full Test run on the release commit before publishing #862 is being reworked so the Release workflow runs the full matrix itself.
• So the comment no longer claims a release check that is not on master, which resolves the independent reviewer's P2 at its root.
• In the description:
  • The merge-order paragraph now matches the decision.
  • The pandas 2 trade-off notes that 4.0.0 supports pandas 3.x only (Raise the pandas and pyarrow minimum versions to tested versions #852 comment) and drops Python 3.10 (Drop Python 3.10 support in 4.0.0 #864).

[laughingman7743]

Independent review (relayed): Codex CLI 0.157.0, model gpt-6-sol, reasoning effort high, codex exec -s read-only, session 01a0e0df-6730-7ba1-b3ab-ee60847bd7b4.

• Snapshot: detached worktree at head a2eb20acf406a0e603ba37b562f1878c562e2c86, base 531185619465b809331a9a8cf2083884365de193. The prompt contained the literal diff and repository context only. The review was static: no tests, no network, no edits. The snapshot was unchanged afterwards.

Reviewer result, verbatim:

Surfaces covered: the specified diff, both Test workflows, the release workflow, Python classifiers and tox configuration, and the testing docs. This was a read-only review; I did not run tests.

Verdict: FINDINGS

• P1 — .github/workflows/test.yaml:96: jq '[last]' wraps the last input document. Here the input is one array, so it produces a nested array rather than ["3.14"]. A ready PR therefore passes an array as its sole Python matrix value; the Python setup steps cannot use it as a version, so the PR’s AWS suites fail before testing. Use [.[-1]] to select the final array element.

• P2 — .github/workflows/test.yaml:84: The comment says the Release workflow checks that this list matches the classifiers, but release.yaml has no such check. If a maintainer adds a supported version to pyproject.toml but misses this list, dispatch runs omit that version and the release can still publish. Add the check or remove the claim.

Non-blocking suggestion: Add an offline check of the generated PR and dispatch version arrays; this change has no test covering that output.

Author verification:

1. jq '[last]' nests the array (P1): rejected, disproved by execution.
   • last without arguments is jq's builtin def last: .[-1]; (jq ≥ 1.5). It is not last(f) over input documents.
   • echo '["3.10", "3.11", "3.12", "3.13", "3.14"]' | jq -c '[last]' prints ["3.14"] (jq 1.8.2 locally; the ubuntu-24.04 runner's apt jq 1.7.1 has the same builtin).
   • This PR's own Ready CI will show run (3.14) jobs.
2. "which the Release workflow checks" (P2): holds once Require a full Test run on the release commit before publishing #862 is merged, which is the stated merge order.
   • The reviewer's snapshot is origin/master + this PR, and does not contain Require a full Test run on the release commit before publishing #862.
   • In Require a full Test run on the release commit before publishing #862, scripts/verify_release_tests.py requires <suite> / run (<version>) to succeed for every classifier version. If a version is added to the classifiers but not to PYTHON_VERSIONS, dispatch runs lack its jobs and the release is refused.
   • This PR will not be marked Ready before Require a full Test run on the release commit before publishing #862 is merged.
3. Offline test of the version arrays (non-blocking): declined. The selection is two jq expressions checked by execution above. The PR's own CI (pull_request) and the next dispatch or schedule run exercise both branches.

[laughingman7743]

Independent follow-up (relayed): Codex CLI 0.157.0, model gpt-6-sol, reasoning effort high, codex exec -s read-only, session 01a0e21f-5ebf-76d0-bada-7de1f44f0cca.

• Scope: git range-diff from a2eb20a to 738d64cf0939592ef4f395eb2a15c379689242de (base 531185619465b809331a9a8cf2083884365de193), plus the full current diff.
• The review was static, and the snapshot was unchanged afterwards.

Reviewer result, verbatim:

Covered surfaces: repair delta and full base-to-head diff; all reusable-workflow callers; event gates, suite filters, JSON matrix propagation; Python classifiers, tox configuration, Release workflow, and changed documentation.

Verdict: CLEAN. The repair correctly removes the unsupported Release-verification claim. Eligible PRs select Python 3.14; schedule and dispatch select 3.10–3.14, matching the classifiers. All three callers supply the required input. No unsupported claims or workflow defects found in scope.