ci: tighten path filters on PR-triggered workflows

[samrose]

Summary

Three workflows fire on every PR push regardless of what changed. This PR adds paths: filters to their pull_request triggers, scoped to what each workflow actually inspects. Findings come from a pgci-graph workflows analysis (Phase 1).

Filters

ci.yml — "Check merge requirements"

Reads ansible/vars.yml to validate postgres_release version strings. That's the entire workflow.

paths:
  - 'ansible/vars.yml'
  - '.github/workflows/ci.yml'

check-shellscripts.yml

Runs ShellCheck against ./ansible/files/admin_api_scripts and its pg_upgrade_scripts subdir. The ** glob covers both.

paths:
  - 'ansible/files/admin_api_scripts/**'
  - '.github/workflows/check-shellscripts.yml'

nix-build.yml — "Nix CI"

Scoped to actual Nix derivation inputs and the workflow's own dependencies.

paths:
  - 'flake.nix'
  - 'flake.lock'
  - 'nix/**'
  - 'ansible/files/**'
  - 'migrations/**'
  - 'audit-specs/**'
  - 'Dockerfile-*'
  - 'docker/**'
  - '.github/workflows/nix-build.yml'
  - '.github/workflows/nix-eval.yml'
  - '.github/actions/nix-install-ephemeral/**'
  - '.github/actions/nix-install-self-hosted/**'
  - '.github/actions/nix-build-retry/**'

Deliberately excluded from nix-build.yml's filter (with verification)

• ansible/vars.yml — empirically the only Nix derivation with vars.yml as an inputSrc is dbmate-tool. Verified via nix derivation show against all packages and a representative sample of checks (postgres builds, extensions, devShell, pre-commit, treefmt, etc.) — none had vars.yml as an input. Furthermore, dbmate-tool's build cannot fail on vars.yml content changes (it only embeds the file's store path; the script body and shellcheck don't depend on the content). Content validation is handled by ci.yml, which keeps vars.yml in its filter.
• test.yml, testinfra-ami-build.yml — reusable workflows called by nix-build.yml, but changes to them don't affect the Nix derivation graph, only how downstream tests run. Re-running every package build × architecture × PG version on a test-logic tweak is wasteful. Merge queue still validates them at merge time.
• docker-image-test.yml — has its own independent pull_request trigger, so it fires regardless.
• .github/actions/** (wide glob) — only 3 of 6 actions in that directory are used by nix-build.yml. Listing the specific 3 avoids re-evaluation when unrelated actions (build-ami, check-docker-image-changes, shared-checkout) are edited.

Left un-filtered (intentional)

• merge_group: everywhere — GitHub ignores paths: on this event, and it's the merge-time safety net.
• nix-build.yml's push.branches: [release/*] — release pushes always need full validation.
• workflow_dispatch: — manual.

Required status checks interaction

The three filtered workflows produce required status checks on develop:

• ci.yml → check-release-version
• check-shellscripts.yml → build
• nix-build.yml (via test.yml) → run-tests / prepare, run-tests / build (15 | 17 | orioledb-17)

When GitHub skips a workflow due to paths:, no status is reported — which would normally block merge if required checks were evaluated on the PR commit.

Mitigated by merge queue (verified enabled on develop via recent gh-readonly-queue/develop/pr-NNNN-... merge_group runs):

• Required status checks are evaluated on the merge_group commit, not the PR commit.
• paths: filters are ignored on merge_group events.
• All three workflows retain merge_group: triggers (un-filtered).

PRs that don't match paths: skip CI at PR-time (the desired savings); merge queue runs all required checks at merge time and gates merge on them.

Caveats

• The nix-build.yml paths list is a manual stop-gap. Phase 2 of pgci-graph will derive it from inputSrcs automatically; until then, treat it as a quarterly review item. Merge queue mitigates the cost of any drift.
• The merge-queue mitigation has not been empirically tested on this repo with a PR that touches none of the filtered paths. Verifying that requires this PR to be merged first, then opening a follow-up no-op PR. Revert is one commit if anything misbehaves.

Test plan

• Open a docs-only follow-up PR after merge: confirm workflows skip at PR-time, merge_group fires all three at queue time, PR merges.
• Confirm release pushes (push.branches: release/*) still trigger full nix-build.yml.
• Confirm a PR touching only ansible/vars.yml triggers ci.yml only (not nix-build.yml, not check-shellscripts.yml).
• Confirm a PR touching only ansible/files/admin_api_scripts/ triggers check-shellscripts.yml only.
• Confirm a PR touching only nix/** triggers nix-build.yml only.

[hunleyd]

looks sane to me

[darora]

looks sensible, definitely haven't exhaustively verified the nix-build patterns