jlxq0/hevy-mcp
1
0
Fork 0
Code Issues 1 Pull requests Projects Releases Packages 1 Wiki Activity Actions

docs: say why CI / docker is not a required status check #8

Merged
jlxq0 merged 2 commits from docs/why-docker-is-not-a-required-check into main 2026-08-27 01:57:33 +00:00
Conversation 1 Commits 2 Files changed 1 +15
jlxq0 commented 2026-08-27 01:53:12 +00:00
Owner
Copy link

main is now protected: enable_push: false, one required status context, CI / cargo*. CI / docker is excluded on purpose, and the reason is not visible from the rule, so the next person tidying it up adds it back.

A docker job skipped because needs: cargo failed posts success to the commit status. Measured here yesterday: failure CI / cargo at 05:23:03Z and success CI / docker at 05:23:04Z on #2, the same pair one second apart on #3, and no docker task in the run list for either. Requiring that context would build a gate satisfied by a commit where nothing was built.

Why the rule exists at all. hevy-mcp had no branch protection rule of any kind on main until today. Across the estate:

repo rules effect
jlxq0/matrix-mcp 1 enable_push=true, no status check — enforces nothing
jlxq0/jmap-mcp 0
jlxq0/caldav-mcp 0
jlxq0/carddav-mcp 0
jlxq0/m365-mcp 0
jlxq0/typst-mcp 0
oddie-apps/platform 1 enable_push=false, status check armed

Every green enforced in this repository so far has been discipline rather than a gate.

Proved the rule rejects before trusting it. On a throwaway branch: pushed a commit with no rule, armed enable_push: false, pushed a second commit.

remote: Forgejo: Not allowed to push to protected branch protection-probe
 ! [remote rejected] protection-probe -> protection-probe (pre-receive hook declined)
push exit=1

Probe branch and probe rule both deleted. git ls-remote shows only main and the open feature branches.

Confirmed it does not block legitimate work either: #5 still reads mergeable=true with CI / cargo (pull_request)=success.

Documentation only.

`main` is now protected: `enable_push: false`, one required status context, `CI / cargo*`. `CI / docker` is excluded on purpose, and the reason is not visible from the rule, so the next person tidying it up adds it back. A `docker` job skipped because `needs: cargo` failed posts `success` to the commit status. Measured here yesterday: `failure CI / cargo` at 05:23:03Z and `success CI / docker` at 05:23:04Z on #2, the same pair one second apart on #3, and no docker task in the run list for either. Requiring that context would build a gate satisfied by a commit where nothing was built. **Why the rule exists at all.** hevy-mcp had no branch protection rule of any kind on `main` until today. Across the estate: | repo | rules | effect | |---|---|---| | `jlxq0/matrix-mcp` | 1 | `enable_push=true`, no status check — enforces nothing | | `jlxq0/jmap-mcp` | 0 | | | `jlxq0/caldav-mcp` | 0 | | | `jlxq0/carddav-mcp` | 0 | | | `jlxq0/m365-mcp` | 0 | | | `jlxq0/typst-mcp` | 0 | | | `oddie-apps/platform` | 1 | `enable_push=false`, status check armed | Every green enforced in this repository so far has been discipline rather than a gate. **Proved the rule rejects before trusting it.** On a throwaway branch: pushed a commit with no rule, armed `enable_push: false`, pushed a second commit. ``` remote: Forgejo: Not allowed to push to protected branch protection-probe ! [remote rejected] protection-probe -> protection-probe (pre-receive hook declined) push exit=1 ``` Probe branch and probe rule both deleted. `git ls-remote` shows only `main` and the open feature branches. Confirmed it does not block legitimate work either: #5 still reads `mergeable=true` with `CI / cargo (pull_request)=success`. Documentation only.
docs: say why CI / docker is not a required status check
All checks were successful
CI / cargo (pull_request) Successful in 37s
Details
CI / docker (pull_request) Successful in 13s
Details
c97936c968
 
main is protected now: enable_push false, one required context, CI /
cargo*. docker is excluded on purpose and the reason is not visible from
the rule, so the next person tidying it up would add it.

A docker job skipped because needs: cargo failed posts success to the
commit status. Requiring that context builds a gate satisfied by a
commit where nothing was built.

Proved the rule rejects before trusting it: on a throwaway branch, a
push with no rule succeeded, then with enable_push false the next push
came back 'Forgejo: Not allowed to push to protected branch',
pre-receive hook declined, exit 1. Probe branch and rule deleted.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NCiHcHN6LrhiuLXbG9SBYG
docs: the rule refuses the ops token too, and what that costs
All checks were successful
CI / cargo (pull_request) Successful in 33s
Details
CI / docker (pull_request) Successful in 7s
Details
b0b8866877
 
apply_to_admins is true. Proved it bites rather than reading it back:
with an unsatisfiable context temporarily armed, merging PR #8 returned
405, 'Not all required status checks successful'. Context restored.

The cost is real and deliberate. PR #2 was merged red on purpose with
the reason stated in advance, and that is no longer possible without
patching the rule first.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NCiHcHN6LrhiuLXbG9SBYG
jlxq0 commented 2026-08-27 01:56:35 +00:00
Author
Owner
Copy link

apply_to_admins is now true, on Clark's point that a rule leaving it false reads as weaker than it is and forces the next person to know a measurement to know it holds.

Proved it bites rather than reading it back. Temporarily armed a second, unsatisfiable context alongside the real one, then tried to merge this pull request with the ops token:

PATCH branch_protections/main  {"status_check_contexts":["CI / cargo*","CI / never-runs"]}   200
POST  pulls/8/merge                                                                          405
      {"message":"not allowed to merge [reason: Not all required status checks successful]"}
PATCH branch_protections/main  {"status_check_contexts":["CI / cargo*"]}                      200

Restored immediately; the rule reads ctx=["CI / cargo*"] admins=true.

The cost is real and it is recorded rather than discovered later. PR #2 was merged red on purpose, with the reason stated in advance and reproduced locally in the workflow's own step order. That is no longer possible without patching the rule first. The escape hatch is two API calls and it should leave a trace: patch, merge, patch back, and say on the pull request that you did.

Both jobs on this branch are real tasks rather than ticks: 17576 cargo success, 17578 docker success.

Clark also reproduced the docker fault a second time, on a push event rather than a pull request, which makes it a property of the workflow rather than a one-off:

40bde27c  CI / cargo (pull_request)=failure @05:23:03Z   CI / docker (pull_request)=success @05:23:04Z
387f9e46  CI / cargo (push)=failure         @05:33:01Z   CI / docker (push)=success         @05:33:04Z

The estate-wide sweep is jlxq0/mantis#141. Four gates enforce anything across everything; fifteen repositories have no rule; about twenty carry push=true, status=false, which is the same object as no rule and worse, because a reader checking sees a rule.

`apply_to_admins` is now `true`, on Clark's point that a rule leaving it false reads as weaker than it is and forces the next person to know a measurement to know it holds. **Proved it bites rather than reading it back.** Temporarily armed a second, unsatisfiable context alongside the real one, then tried to merge this pull request with the ops token: ``` PATCH branch_protections/main {"status_check_contexts":["CI / cargo*","CI / never-runs"]} 200 POST pulls/8/merge 405 {"message":"not allowed to merge [reason: Not all required status checks successful]"} PATCH branch_protections/main {"status_check_contexts":["CI / cargo*"]} 200 ``` Restored immediately; the rule reads `ctx=["CI / cargo*"] admins=true`. **The cost is real and it is recorded rather than discovered later.** PR #2 was merged red on purpose, with the reason stated in advance and reproduced locally in the workflow's own step order. That is no longer possible without patching the rule first. The escape hatch is two API calls and it should leave a trace: patch, merge, patch back, and say on the pull request that you did. Both jobs on this branch are real tasks rather than ticks: `17576 cargo success`, `17578 docker success`. Clark also reproduced the `docker` fault a second time, on a push event rather than a pull request, which makes it a property of the workflow rather than a one-off: ``` 40bde27c CI / cargo (pull_request)=failure @05:23:03Z CI / docker (pull_request)=success @05:23:04Z 387f9e46 CI / cargo (push)=failure @05:33:01Z CI / docker (push)=success @05:33:04Z ``` The estate-wide sweep is `jlxq0/mantis#141`. Four gates enforce anything across everything; fifteen repositories have no rule; about twenty carry `push=true, status=false`, which is the same object as no rule and worse, because a reader checking sees a rule.
jlxq0 merged commit a950280304 into main 2026-08-27 01:57:33 +00:00
jlxq0 deleted branch docs/why-docker-is-not-a-required-check 2026-08-27 01:57:34 +00:00
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels   
waiting-on-julian
Blocked on Julian. The ask is in the issue.

No labels
waiting-on-julian
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
jlxq0/hevy-mcp!8
No description provided.