CtrlK
BlogDocsLog inGet started
Tessl Logo

pr-enforcement-action

Use when changing or migrating the shared require-no-mistakes PR-enforcement action, its live PR lookup, or its workflow caller.

SKILL.md
Quality
Evals
Security

Shared PR-Enforcement Action (.github/actions/require-no-mistakes)

  • The shared implementation of the PR must be raised via no-mistakes gate is a composite action that lets enforcing repositories replace copied, drift-prone scripts. It verifies the signature line, parses the v1 pipeline-step attestation, binds head_sha to the PR head, and requires review, test, and document to be completed. Callers pin a release tag or commit SHA, never @main, which the judged PR can edit. Per-repo configuration is exemptions only (exempt-authors, exempt-bot-authors, exempt-head-branches); which steps are required is deliberately not an input, so no caller can weaken the gate while still reporting the same check name. The action README owns usage; CONTRIBUTING.md owns the contributor-facing contract.
  • This repository's own gate (.github/workflows/no-mistakes-required.yml) is a thin caller of the action, pinned at an already-published commit SHA. GitHub downloads uses: at job setup, so the pin must always name a ref that already carries the action. That pin IS the self-certification guard: a PR editing the action is fully tested on its own head (the Go tests execute the working-tree verify.py) while the required check judging it runs the published pinned copy, so the change cannot rewrite its own judge. Bumping the pin is a separate deliberate PR.
  • This repo's automation exemptions stay in the job-level if:, not in exempt-authors. An in-job exemption still needs the run to start, and a GITHUB_TOKEN PR's run is created in action_required and never starts; the paths-ignore entries exist for the same reason. Repos without that constraint should prefer the action's inputs.
  • Duplicate step records are LAST-WINS by design (check_required_steps in verify.py), and a skip-shaped sibling field on a completed record is deliberately not inspected. Some pre-migration inline gates were stricter (requiring every record of a name to be completed); that strictness is explicitly NOT the standard, and relaxing to last-wins on migration is the intended outcome, not a regression. Do not "harden" this without an owner decision.
  • All callers use the T2 trigger set (opened, edited, synchronize, reopened). Since the pre-push attestation change (#994), synchronize is the event that judges a pipeline-pushed head, so it is restored rather than dropped after head_sha binding.
  • Migrating a repository is rarely a one-file swap. Repos whose tests extract and execute the inline run: block (an extractGateScript() helper and its gate test) break at import once the block is gone, and repo-level AGENTS.md notes that tell agents to hand-copy the gate from a sibling repository must be rewritten - that copying is the drift the shared action exists to remove.
  • Regressions: require_no_mistakes_action_test.go executes verify.py the way a runner does (verdicts, exemption surface, event-payload binding); workflow_no_mistakes_required_test.go owns the CALLER - immutable-SHA pin, single delegating step, exemptions, triggers, concurrency identity, fork boundary - and drives the real action through the event payload.

Stale Actions Event Replay Can Resurrect a Superseded Check (require-no-mistakes)

  • .github/actions/require-no-mistakes/verify.py reads the PR body/head SHA it verifies from a live GitHub REST API lookup first (via live_pr_facts, a direct urllib.request GET to {GITHUB_API_URL}/repos/{repo}/pulls/{number} with the forwarded github-token as a Bearer token, no gh CLI), not from GITHUB_EVENT_PATH, whenever a caller forwards no explicit pr-body/pr-head-sha (the documented zero-input integration every caller actually uses). A GitHub Actions job rerun replays the event payload archived at the run's original trigger rather than delivering a fresh one; re-running an old, already-superseded failed run therefore used to reproduce its stale verdict with a brand-new check-run timestamp, which both GitHub's own required-check view and collapseLatestByName (internal/scm/github/github.go) treat as current - pinning a stale FAILURE next to an already-green commit with no clean recovery short of a new SHA. When a required live lookup is unavailable (no pull-requests: read, no token, or the API call fails), the gate fails closed rather than certifying compliance from the possibly-stale event payload; explicit pr-body/pr-head-sha inputs always skip the live lookup and win, unchanged.
  • Tests: require_no_mistakes_action_test.go (TestRequireActionLiveLookupOverridesStaleArchivedEvent and siblings).
Repository
kunchenguid/no-mistakes
Last updated
First committed

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.