[vthorsteinsson]

Every merged PR is tested twice: once by its pull_request run and again by the push run on master. That's 8 jobs (about 15 job-minutes) each time.

Changes (.github/workflows/python-package.yml)

• gate job (Ubuntu, about 10 s). It skips the test matrix on a master push when all of these hold:

  • the pushed commit is a merge;
  • its first parent (master's previous head) is an ancestor of its second parent (the PR head), i.e. the branch was up to date with master;
  • the PR head has a successful pull_request run of this workflow.

  The merge commit then has exactly the tree the PR run tested. Direct pushes, squash merges and PRs that were behind master still get the full run. GitHub empties a workflow run's pull_requests list after merging, which is why the check uses commit ancestry rather than PR metadata.

• Concurrency: a new push to a PR cancels its run in progress. Master runs are never cancelled (the group key is the commit SHA).

• paths-ignore: **.md on both triggers, so Markdown-only changes don't run CI. There are no required status checks, so a docs-only PR is not left waiting.

Verified against past merges

I ran the gate logic locally against the real history:

Commit	Branch state	Gate
ca6464f (#72)	up to date	skip
3c7d88d (#71)	up to date	skip
6c53a71 (#63), dc777ba (#64)	diverged (dependabot, 44 behind)	full run
64b07a2 "Bump version to 3.9.0"	direct push	full run

This PR's own run exercises the pull_request path, where the gate always passes through. If this branch is still up to date with master when merged, the push run on master should show the matrix as skipped.

🤖 Generated with Claude Code