ci: check pull requests with the shared PR check (PDAT ADR-0018) #4

New Issue

2026-10-08T16:30:56Z

claude_bot Bot commented

2026-10-08 16:30:56 +00:00

PDAT/vision ADR-0018 is accepted: PDAT/vision#126 was merged on 2026-10-08. Step 4 of methodology §Adopting is a pull request check, in which gov-lint reads each PR's description and diff. PDAT/ci-workflows provides it as a shared workflow, so this repo only needs a small caller.

Add .gitea/workflows/pr.yml:

name: PR
on:
  pull_request:
    branches: [main]
    types: [opened, edited, synchronize, reopened]
permissions:
  contents: read
jobs:
  pr-check:
    uses: PDAT/ci-workflows/.gitea/workflows/pr-check.yml@main
    secrets:
      MODULE_READ_TOKEN: ${{ secrets.MODULE_READ_TOKEN }}

What it checks on every PR:

Description: the sections ## Summary, ## Questions, ## Spec, ## Review focus and ## Verification, in that order, and an issue reference (Closes #N, Fixes #N or Refs #N). Editing the description re-runs the check.
Spec PR or code PR: a PR with more than 200 changed lines of non-test code needs an approved spec.
Changes the human must approve: changes to .gitea/workflows/ or to the spec renderer are flagged.
Repo-level rules: gov-lint's checks for CLAUDE.md and .context.json.

Why it is safe:

It runs on pull_request only, never on pull_request_target.
The PR is treated as data: nothing from it is built or run.
MODULE_READ_TOKEN is visible only to the step that installs gov-lint.
PDAT/ci-workflows has run it on its own PRs since PDAT/ci-workflows#11.

Steps:

Add pr.yml. The PR that adds it is already checked by it, so write that PR's description in the format above.
Provide the secret. The repo or its organisation must provide MODULE_READ_TOKEN.
Make it required. After the merge, make the PR workflow's status a required check in the branch protection of main. This needs repo admin. Take the exact name from the first run.
Finish adopting the methodology. Steps 1–3 of §Adopting put the "How we work" block into AGENTS.md instead of the pinned development.md block. They can come in the same PR or a separate one; the PR check works either way.

Questions go to PDAT/ci-workflows.

PDAT/vision **ADR-0018** is accepted: PDAT/vision#126 was merged on 2026-10-08. Step 4 of methodology §Adopting is a **pull request check**, in which gov-lint reads each PR's description and diff. PDAT/ci-workflows provides it as a shared workflow, so this repo only needs a small caller. **Add `.gitea/workflows/pr.yml`:** ```yaml name: PR on: pull_request: branches: [main] types: [opened, edited, synchronize, reopened] permissions: contents: read jobs: pr-check: uses: PDAT/ci-workflows/.gitea/workflows/pr-check.yml@main secrets: MODULE_READ_TOKEN: ${{ secrets.MODULE_READ_TOKEN }} ``` **What it checks on every PR:** - **Description:** the sections `## Summary`, `## Questions`, `## Spec`, `## Review focus` and `## Verification`, in that order, and an issue reference (`Closes #N`, `Fixes #N` or `Refs #N`). Editing the description re-runs the check. - **Spec PR or code PR:** a PR with more than 200 changed lines of non-test code needs an approved spec. - **Changes the human must approve:** changes to `.gitea/workflows/` or to the spec renderer are flagged. - **Repo-level rules:** gov-lint's checks for `CLAUDE.md` and `.context.json`. **Why it is safe:** - It runs on `pull_request` only, never on `pull_request_target`. - The PR is treated as data: nothing from it is built or run. - `MODULE_READ_TOKEN` is visible only to the step that installs gov-lint. - PDAT/ci-workflows has run it on its own PRs since PDAT/ci-workflows#11. **Steps:** 1. **Add `pr.yml`.** The PR that adds it is already checked by it, so write that PR's description in the format above. 2. **Provide the secret.** The repo or its organisation must provide `MODULE_READ_TOKEN`. 3. **Make it required.** After the merge, make the `PR` workflow's status a required check in the branch protection of `main`. This needs repo admin. Take the exact name from the first run. 4. **Finish adopting the methodology.** Steps 1–3 of §Adopting put the "How we work" block into `AGENTS.md` instead of the pinned `development.md` block. They can come in the same PR or a separate one; the PR check works either way. Questions go to PDAT/ci-workflows.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: PDAT/pda-fieldbus-profiles#4