Skip to content

ci: run repo checks only on pull requests - #237

Merged
jacderida merged 1 commit into
mainfrom
chrisoneil/v2-1353-ci-run-repo-checks-only-on-pull-requests-across-all-six
Sep 28, 2026
Merged

jacderida merged 1 commit into
mainfrom
chrisoneil/v2-1353-ci-run-repo-checks-only-on-pull-requests-across-all-six

Conversation

@jacderida

Copy link
Copy Markdown
Member

Part of a six-repo change (V2-1353) making repo CI run on pull requests only. The push triggers on
main and rc-* re-ran the exact checks that had just passed on the PR head, and with a limited
runner pool that duplicate work queues behind checks on open PRs — so it costs review latency, not
just wasted minutes.

  • Drop the push: trigger from ci.yml (MSRV, fmt, clippy, tests)
  • Drop the push: trigger from adr-governance.yml

pr-checks.yml and claude.yml are untouched, and release.yml keeps its tag trigger. It carries
no CI gate to remove — its validate job only checks the tag against the Cargo.toml version.

Linear issue

Closes V2-1353

Risk tier

  • T0 — docs / tooling / CI / pure UX-output. Repo CI only.
  • T1 — client-only, no network-facing behavior change. CI + prod compat smoke.
  • T2 — node/client logic with behavioral surface, no protocol/format/economics change. Dev testnet + ADR.
  • T3 — protocol / storage format / payments / routing. T2 evidence + adversarial testing.

Compatibility

  • Wire: none
  • Storage: none
  • API: none

Semver impact

  • breaking
  • feature
  • fix

No crate source changes — only .github/workflows, so this needs no version bump of its own.

Test evidence

T0: repo CI only.

  • Both workflows still parse, and the remaining trigger on each is pull_request against
    main + rc-*, unchanged from before.
  • The default branch is main and no workflow targeted any other branch, so every job that ran
    on a push also ran on the PR — no check loses coverage.
  • release.yml was read through: no job runs fmt, clippy or tests, so nothing there needed
    changing.

New dependency

none

ADR

n/a

Mitigation / rollback

Revert this commit; the triggers come back exactly as they were. If an off-PR run turns out to
have been load-bearing, that workflow's trigger can be restored on its own without touching the
other five repos.

🤖 Generated with Claude Code

The push triggers on main and rc-* re-ran the exact checks that had just passed on the PR head.
The organisation's runner pool is small enough that the duplicate work queues behind checks on
open PRs, so the second run costs real review latency rather than just wasted minutes.

- Drop the push trigger from ci.yml (MSRV, fmt, clippy, tests)
- Drop the push trigger from adr-governance.yml

pr-checks.yml, claude.yml and the tag-triggered release.yml are unchanged. release.yml carries no
CI gate — its validate job only checks the tag against the Cargo.toml version. The default branch
is main and nothing targets another branch, so no check loses coverage.

Closes V2-1353

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

@dirvine dirvine left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reviewed by Hermes Agent (dirvine identity), per <@UDK3BBUE8>'s request.

CI-only change, verified against head 945b587:

  • ci.yml: removes the push trigger on main / rc-*; pull_request trigger unchanged — no effect on PR gating.
  • adr-governance.yml: removes the push trigger on main/master; PR trigger unchanged.

No source changes, no secrets. CI on head: fully green (builds, clippy, MSRV, security audit, storage fs suite, WebRTC devnet, ADR validation).

@jacderida
jacderida merged commit 4f78154 into main Sep 28, 2026
21 checks passed
@jacderida
jacderida deleted the chrisoneil/v2-1353-ci-run-repo-checks-only-on-pull-requests-across-all-six branch September 28, 2026 21:05
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants