jakman85andClaude Opus 5
fcc66c7858
enable_status_check and required_approvals were set earlier today and recorded as done. They did not bite. block_admin_merge_override was false, and Gitea lets repo admins override merge requirements without it. jakman85 holds owner, so both requirements were bypassable by exactly the account that performs every merge. The evidence was already on the record: PRs #5-#9 all merged while required_approvals: 1 was in force, with ZERO approvals recorded on any of them. Two process failures, both the same shape as the defect this whole session started with: 1. Verified with the wrong view. /branches/main reports protected, enable_status_check and required_approvals but NOT block_admin_merge_override -- it showed everything green while the rule was overridable. /branch_protections/main is authoritative. 2. Probed for a field name assumed to exist. This Gitea (1.24.3) has no `apply_to_admins`; asking jq for it returns null, which reads like "set to false" but means "key absent", so a PATCH that silently did nothing produced a convincing before/after. jq returning null is not a value -- it may be an absence. Enumerate with to_entries. require-gate.sh now sets block_admin_merge_override: true; block-admin-override.sh fixes it in isolation. Both carry the field-name warning. This PR is the test. If it merges WITHOUT an approval, the fix did not work. Also records the governance question: with only jakman85 (human) and gitea-admin (agent), a human-authored PR now needs the automation account to approve it. That is ceremony, not review, and the choice between keeping it, dropping approvals in favour of the status check, or adding a second human is the operator's to make. Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
61 lines
3.1 KiB
Bash
Executable File
61 lines
3.1 KiB
Bash
Executable File
#!/usr/bin/env bash
|
|
# Items 1 + 2: make the gate a REQUIRED status check and require one approval.
|
|
#
|
|
# RUN THIS LAST. Prerequisites, in order:
|
|
# a) PR #7 (dind native sidecar) is MERGED, and
|
|
# b) you have SEEN a real workflow run go green on the converted pod.
|
|
# The runner Deployment is the merge gate for the whole repo. Turning on a required check
|
|
# while the runner is broken means no PR can merge -- including the revert. (Recoverable:
|
|
# an owner can set enable_status_check back to false. But do not rely on that.)
|
|
#
|
|
# Requires exactly ONE context: `gate / gate (pull_request)`.
|
|
# * NOT `gate / conformance (*)` -- that job is `if: false`, and a skipped Gitea job reports
|
|
# SUCCESS ("Has been skipped"). Requiring it would pass VACUOUSLY forever while nothing
|
|
# ran, which under HARD RULE 4 is worse than a deadlock: a deadlock is loud.
|
|
# block_admin_merge_override: true is LOAD-BEARING and was missing on the first pass. Gitea
|
|
# lets repo admins override merge requirements without it, so required_approvals and the
|
|
# required status check are both bypassable by exactly the account that does the merging.
|
|
# Measured: PRs #5-#9 merged with ZERO approvals recorded against required_approvals: 1.
|
|
#
|
|
# FIELD NAMES: this Gitea (1.24.3) has NO `apply_to_admins`. Asking jq for it returns null,
|
|
# which reads like "false" but means "key absent" -- enumerate real keys with `to_entries`
|
|
# instead of probing names you assume exist. That mistake cost a wasted PATCH.
|
|
#
|
|
# * NOT the `(push)` variant -- after PR #6 there are no per-branch push runs at all, so a
|
|
# PR would never produce that context.
|
|
set -euo pipefail
|
|
HOST=gitea.home.keithjackson.dev; OWNER=Home-Network; REPO=home-network-k3s-impl
|
|
creds="$(printf 'protocol=https\nhost=%s\n\n' "$HOST" | git credential fill)"
|
|
U="$(sed -n 's/^username=//p' <<<"$creds")"; P="$(sed -n 's/^password=//p' <<<"$creds")"
|
|
api() { curl -sS --config <(printf 'user = "%s:%s"\n' "$U" "$P") "$@"; }
|
|
|
|
echo "==> updating branch protection on main"
|
|
jq -n '{
|
|
enable_push: false,
|
|
enable_status_check: true,
|
|
status_check_contexts: ["gate / gate (pull_request)"],
|
|
required_approvals: 1,
|
|
block_on_rejected_reviews: true,
|
|
dismiss_stale_approvals: true,
|
|
block_on_outdated_branch: false,
|
|
block_admin_merge_override: true
|
|
}' | api -X PATCH -H 'Content-Type: application/json' --data @- \
|
|
"https://${HOST}/api/v1/repos/${OWNER}/${REPO}/branch_protections/main" >/dev/null
|
|
|
|
echo "==> verifying"
|
|
api "https://${HOST}/api/v1/repos/${OWNER}/${REPO}/branches/main" \
|
|
| jq -r '{protected,user_can_push,enable_status_check,status_check_contexts,required_approvals}'
|
|
|
|
cat <<'NOTE'
|
|
|
|
NOTE ON required_approvals: 1 -- Gitea will not let an author approve their own PR.
|
|
* Agent-opened PRs (author gitea-admin) are approved by jakman85. Fine.
|
|
* PRs YOU open as jakman85 need gitea-admin to approve. If that is awkward, either open
|
|
agent work as gitea-admin and review as jakman85, or set required_approvals back to 0
|
|
and rely on the status check alone.
|
|
|
|
Then prove it, rather than trusting the API:
|
|
git commit --allow-empty -m probe && git push origin main # EXPECT: rejected
|
|
git reset --hard HEAD~1
|
|
NOTE
|