No pull-request pipeline: the most shared repository is the least checked #25

Closed
opened 2026-09-02 22:07:40 +00:00 by ahmad · 0 comments
Owner

Context

This repository has no pull-request pipeline. .forgejo/workflows/ holds only release.yml, and main's protection requires an approval and no status checks — so a change to a composite action reaches every consuming repository having been read by a reviewer and executed by nothing.

That is a wider blast radius than any application repository here: a bad deploy-vps or release lands on the moving v3 tag and every pipeline in the fleet picks it up on its next run.

The org standard is that every repository validates pull requests. This one is the least covered and the most shared.

Scope

  • In: a pr.yml that validates what can be validated without a host — the action YAML parses, the shell in each composite step is syntactically valid, and the README lints — plus registering it as a required status check on main.
  • Out: executing the actions against a real host or registry; that needs credentials this pipeline should not hold, and the consuming repositories' own runs are where that is exercised.

Acceptance criteria

  • Given a pull request, when the pipeline runs, then every action.yml in the repository is parsed and a syntax error fails the check.
  • Given a pull request, when the pipeline runs, then the shell of each composite run: step is checked for syntax errors (bash -n or shellcheck) and a broken script fails the check.
  • Given a pull request, when the pipeline runs, then the README is linted as it is in the application repositories.
  • Given a pull request that violates any of those, when the pipeline finishes, then the pull request cannot be merged.
  • Given branch protection on main, when it is read back, then the new check is listed as required.

Notes

bash -n on a composite step's run: body is not free to extract — the steps are YAML strings containing ${{ }} expressions, which are not valid shell. Substituting a placeholder for each expression before the syntax check is the straightforward approach, and it is worth writing down whichever way it is done.

### Context This repository has no pull-request pipeline. `.forgejo/workflows/` holds only `release.yml`, and `main`'s protection requires an approval and **no** status checks — so a change to a composite action reaches every consuming repository having been read by a reviewer and executed by nothing. That is a wider blast radius than any application repository here: a bad `deploy-vps` or `release` lands on the moving `v3` tag and every pipeline in the fleet picks it up on its next run. The org standard is that every repository validates pull requests. This one is the least covered and the most shared. ### Scope - In: a `pr.yml` that validates what can be validated without a host — the action YAML parses, the shell in each composite step is syntactically valid, and the README lints — plus registering it as a required status check on `main`. - Out: executing the actions against a real host or registry; that needs credentials this pipeline should not hold, and the consuming repositories' own runs are where that is exercised. ### Acceptance criteria - [ ] Given a pull request, when the pipeline runs, then every `action.yml` in the repository is parsed and a syntax error fails the check. - [ ] Given a pull request, when the pipeline runs, then the shell of each composite `run:` step is checked for syntax errors (`bash -n` or shellcheck) and a broken script fails the check. - [ ] Given a pull request, when the pipeline runs, then the README is linted as it is in the application repositories. - [ ] Given a pull request that violates any of those, when the pipeline finishes, then the pull request cannot be merged. - [ ] Given branch protection on `main`, when it is read back, then the new check is listed as required. ### Notes `bash -n` on a composite step's `run:` body is not free to extract — the steps are YAML strings containing `${{ }}` expressions, which are not valid shell. Substituting a placeholder for each expression before the syntax check is the straightforward approach, and it is worth writing down whichever way it is done.
ahmad self-assigned this 2026-09-03 04:32:36 +00:00
ahmad 2026-09-03 06:32:44 +00:00
Sign in to join this conversation.
No description provided.