docs(agents): why master requires CI / python* and not CI / docker #9

Merged

jlxq0 merged 1 commit from docs/branch-protection into master

2026-08-27 02:05:42 +00:00

jlxq0 commented

2026-08-27 02:02:27 +00:00

Owner

Fork patch. Records why this repository's branch protection is shaped the way it is.

master had a rule that enforced nothing — enable_push: true, enable_status_check: false, contexts: null — which reads as protected in any listing and lets git push origin master straight through. Worse than no rule: a reader checking whether the repo is protected sees one and stops looking.

Now armed:

flag	value
`enable_push`	`false`
`apply_to_admins`	`true`
`enable_status_check`	`true`
`status_check_contexts`	`["CI / python*"]`
`required_approvals`	`0`

CI / docker is excluded on a measurement. A job skipped because the job it needs: failed posts success to the commit status. Measured here rather than assumed, on throwaway branch commit e005d4b carrying one failing test:

CI / python (pull_request) = failure
CI / docker (pull_request) = success     <- and no docker task existed for that run

docker carries needs: python, so requiring it builds a gate that is green precisely when the work did not happen.

The glob is load-bearing: the context carries an event suffix, (pull_request) on a PR head and (push) on a branch push, so a literal string matches one and silently never matches the other.

The cost of excluding docker is in the file too. A real docker failure no longer blocks a merge, and this repository has had exactly one — d74a768, merged with python green and docker red on the missing FORGE_PUSH_TOKEN. Requiring the skipped-reports-success context would not have caught that either.

This PR is also the acceptance: it is the first merge under the new flags.

**Fork patch.** Records why this repository's branch protection is shaped the way it is. `master` had a rule that enforced nothing — `enable_push: true`, `enable_status_check: false`, `contexts: null` — which reads as protected in any listing and lets `git push origin master` straight through. Worse than no rule: a reader checking whether the repo is protected sees one and stops looking. Now armed: | flag | value | |---|---| | `enable_push` | `false` | | `apply_to_admins` | `true` | | `enable_status_check` | `true` | | `status_check_contexts` | `["CI / python*"]` | | `required_approvals` | `0` | **`CI / docker` is excluded on a measurement.** A job skipped because the job it `needs:` failed posts **`success`** to the commit status. Measured here rather than assumed, on throwaway branch commit `e005d4b` carrying one failing test: ``` CI / python (pull_request) = failure CI / docker (pull_request) = success <- and no docker task existed for that run ``` `docker` carries `needs: python`, so requiring it builds a gate that is green precisely when the work did not happen. **The glob is load-bearing**: the context carries an event suffix, `(pull_request)` on a PR head and `(push)` on a branch push, so a literal string matches one and silently never matches the other. **The cost of excluding docker is in the file too.** A real docker failure no longer blocks a merge, and this repository has had exactly one — `d74a768`, merged with `python` green and `docker` red on the missing `FORGE_PUSH_TOKEN`. Requiring the skipped-reports-success context would not have caught that either. This PR is also the acceptance: it is the first merge under the new flags.

jlxq0 added 1 commit

2026-08-27 02:02:27 +00:00

docs(agents): why master requires CI / python* and not CI / docker

CI / python (pull_request) Successful in 24s

Details

CI / docker (pull_request) Successful in 46s

Details

9916feb13d

Branch protection on `master` is now armed: `enable_push: false`,
`apply_to_admins: true`, `enable_status_check: true`,
`status_check_contexts: ["CI / python*"]`, `required_approvals: 0`. It
previously existed with `enable_push: true` and no contexts, which reads as
protected in any listing and lets `git push origin master` straight through —
worse than no rule, because a reader checking sees one and stops looking.

`CI / docker` is excluded on a measurement, not a preference. A job skipped
because the job it `needs:` failed posts `success` to the commit status:
measured here on `e005d4b`, a throwaway branch with one failing test, where
`python` reported failure, `docker` reported success, and no docker task
existed for that run at all.

The glob matters because the context carries an event suffix — `(pull_request)`
on a PR head, `(push)` on a branch push — so a literal string matches one and
never the other.

The cost of excluding docker is written down beside the reason: a real docker
failure no longer blocks a merge, and this repository has had exactly one
(`d74a768`, the missing FORGE_PUSH_TOKEN). Requiring the skipped-reports-success
context would not have caught that either.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EfH9dv5Ub8c9PRxipsBXBe