Verify branch protection on main requires the Check workflow before merge #180

New Issue

clawbot · 2026-08-07T18:41:07+02:00

clawbot commented

2026-08-07 18:41:07 +02:00

main is protected and .gitea/workflows/check.yml runs
script/cibuild (docker build, which runs make check) on every push
and pull request targeting main. What has not been verified is
whether the branch protection rule actually lists the Check job as a
required status check — i.e. whether a PR with a red build is blocked
from merging, or merely decorated.

TODO.md calls this out under Future Steps: "Confirm
.gitea/workflows/check.yml gates merges on make check so main cannot
regress."

Steps:

inspect the branch protection settings for main in the Gitea repo
settings (requires repo admin)
if status-check enforcement is off, enable it and add the check
job of the Check workflow to the required checks list
verify empirically: open a PR (any open lint-fix PR works), confirm
the merge button is blocked until the workflow passes

Definition of done:

branch protection for main requires the Check workflow to pass
before merge
verified on a real PR (screenshot or comment noting the observed
blocked/unblocked state)
outcome recorded in a comment on this issue

`main` is protected and `.gitea/workflows/check.yml` runs `script/cibuild` (docker build, which runs `make check`) on every push and pull request targeting `main`. What has not been verified is whether the branch protection rule actually lists the `Check` job as a required status check — i.e. whether a PR with a red build is blocked from merging, or merely decorated. `TODO.md` calls this out under Future Steps: "Confirm `.gitea/workflows/check.yml` gates merges on make check so main cannot regress." Steps: - inspect the branch protection settings for `main` in the Gitea repo settings (requires repo admin) - if status-check enforcement is off, enable it and add the `check` job of the `Check` workflow to the required checks list - verify empirically: open a PR (any open lint-fix PR works), confirm the merge button is blocked until the workflow passes Definition of done: - branch protection for `main` requires the `Check` workflow to pass before merge - verified on a real PR (screenshot or comment noting the observed blocked/unblocked state) - outcome recorded in a comment on this issue

clawbot added this to the 1.1.0 milestone 2026-08-07 18:41:07 +02:00

clawbot referenced this issue

2026-08-07 18:41:25 +02:00

Tag and publish release 1.1.0 #182

clawbot commented

2026-09-03 18:28:43 +02:00

Blocked on repo admin — reassigning to @sneak

Attempted the verification step on 2026-09-03. clawbot cannot read (or set) branch protection on this repo:

GET /repos/sneak/upaas/branch_protections
403 {"message":"user should be an owner or a collaborator with admin write of a repository"}

So the central question here — whether the Check job is actually in the required status checks list for main, versus merely being decorative — cannot be answered or fixed by an agent. It needs someone with repo-admin rights.

What I can confirm from the tree, as supporting context:

.gitea/workflows/check.yml does trigger on both push and pull_request targeting main, running script/cibuild
script/cibuild is docker build ., and the Dockerfile runs make fmt-check, make lint, and make test as build stages — so a green workflow really does imply a green make check
verified today: docker build . on main passes (exit 0, lint 0 issues.)

The workflow side is sound. Only the enforcement setting is unverified.

@sneak — this needs you: in repo Settings → Branches → main, confirm "Enable Status Check" is on and that the check job is in the required-checks list, then note the observed state here. Everything else on this issue is done.

## Blocked on repo admin — reassigning to @sneak Attempted the verification step on 2026-09-03. `clawbot` cannot read (or set) branch protection on this repo: ``` GET /repos/sneak/upaas/branch_protections 403 {"message":"user should be an owner or a collaborator with admin write of a repository"} ``` So the central question here — whether the `Check` job is actually in the **required status checks** list for `main`, versus merely being decorative — cannot be answered or fixed by an agent. It needs someone with repo-admin rights. What I can confirm from the tree, as supporting context: - `.gitea/workflows/check.yml` does trigger on both `push` and `pull_request` targeting `main`, running `script/cibuild` - `script/cibuild` is `docker build .`, and the `Dockerfile` runs `make fmt-check`, `make lint`, and `make test` as build stages — so a green workflow really does imply a green `make check` - verified today: `docker build .` on `main` passes (exit 0, lint `0 issues.`) The workflow side is sound. Only the enforcement setting is unverified. @sneak — this needs you: in repo Settings → Branches → `main`, confirm **"Enable Status Check"** is on and that the `check` job is in the required-checks list, then note the observed state here. Everything else on this issue is done.

sneak was assigned by clawbot

2026-09-03 18:28:44 +02:00

clawbot referenced this issue

2026-09-03 18:29:27 +02:00

Tag and publish release 1.1.0 #182

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: sneak/upaas#180