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]>
37 lines
2.0 KiB
Bash
Executable File
37 lines
2.0 KiB
Bash
Executable File
#!/usr/bin/env bash
|
|
# Stop repository admins from overriding the merge requirements on `main`.
|
|
#
|
|
# WHY. Gitea lets repo admins override branch-protection merge requirements unless
|
|
# `block_admin_merge_override` is set. It was FALSE, and jakman85 holds `owner` -- so
|
|
# required_approvals and the required status check were both overridable by the one account
|
|
# that actually merges. Evidence: PRs #5-#9 all merged with ZERO approvals recorded against
|
|
# `required_approvals: 1`.
|
|
#
|
|
# NOTE ON FIELD NAMES: this Gitea (1.24.3) has NO `apply_to_admins` field. Querying it with jq
|
|
# returns null, which reads like "set to false" but actually means "key absent". Enumerate the
|
|
# real keys (`to_entries`) rather than probing names you assume exist.
|
|
#
|
|
# Recoverable: an owner can PATCH this back to false if it gets in the way.
|
|
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") "$@"; }
|
|
B="https://${HOST}/api/v1/repos/${OWNER}/${REPO}/branch_protections/main"
|
|
|
|
echo "==> before: block_admin_merge_override = $(api "$B" | jq -r .block_admin_merge_override)"
|
|
api -X PATCH -H 'Content-Type: application/json' \
|
|
-d '{"block_admin_merge_override": true}' "$B" >/dev/null
|
|
AFTER=$(api "$B" | jq -r .block_admin_merge_override)
|
|
echo "==> after: block_admin_merge_override = $AFTER"
|
|
[ "$AFTER" = true ] || { echo "PATCH did not take -- do not record this as enforced." >&2; exit 1; }
|
|
|
|
api "$B" | jq -r '{enable_push,enable_status_check,status_check_contexts,required_approvals,block_admin_merge_override}'
|
|
cat <<'NOTE'
|
|
|
|
NOW PROVE IT -- the setting is not the evidence. On the next PR:
|
|
* let the gate go green, then try to merge WITHOUT approving it.
|
|
* Gitea must REFUSE. If it merges, this still is not doing its job.
|
|
Do not record approvals as enforced until you have seen a merge refused.
|
|
NOTE
|