fix(ci): accept the override from a PR review, and stop misdiagnosing an unreadable comments API

The override did not work on its first real test, and the reason was invisible from the outside. Run 203 on PR #38: a well-formed `/approve-override` posted by jakman85 in the PR comment box, 29 minutes newer than the head commit, and the stage still blocked with: approval-override: COMMENTS_JSON is not a list SETTINGS_API_TOKEN is minted [read:repository, read:admin], and Gitea puts /issues/{n}/comments behind the *issue* scope — so Gitea answered with an error OBJECT, `jq -e .` accepted it as valid JSON, and the stage fell through to 'no approving review'. A permission failure wearing the costume of a missing override. /pulls/{n}/files and /pulls/{n}/reviews are under read:repository, which is why every other part of the same stage worked. 1. The diagnosis no longer lies. COMMENTS_JSON leaves the must-parse-or-block loop and is checked for being an ARRAY; when it is not, the stage prints Gitea's own .message, names the missing scope and says where to post instead. An unreadable source can only cause a false BLOCK, never a false pass, so a loud warning is the honest behaviour and blocking was not. 2. An override is accepted from a PR REVIEW body as well as a comment, so the hatch is not hostage to one API scope — a review of type 'Comment' works on the token CI has today. The gate names which source it used; PENDING (unsubmitted, author-only) reviews are dropped. 3. set-ci-token.sh requests read:issue, making the ordinary comment box work — on a RE-RUN only, since an existing token's scopes cannot be widened. ci/tests/approval-override.test.sh: 23 -> 38 assertions, covering the reviews source, PENDING reviews, an error object from the comments API, 'an unreadable comments source must not suppress a valid review override', latest-wins across both sources, and that the diagnostic quotes Gitea's message. Also measured and recorded: run 203 shows gitea-settings PASS after the operator ran the live PATCH, with block_admin_merge_override still true — the narrow change held, the approval count moved and the gate's teeth did not. Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
2026-10-02 00:44:31 -05:00
1 changed files with 6 additions and 13 deletions
@@ -185,12 +185,6 @@ missing from its test. `make -C ci test` goes from **FAILED to all suites passed
 - **`?limit=1000` is not the culprit.** Queried `/issues/38/comments` with `limit=1000`, `limit=50`
  and no limit using my own credentials: `type=array` in all three. So the difference is the
  credential, not the query.
- **The root cause is confirmed by Gitea, in its own words.** Run 206 (the fix in place):
-  `[warn] cannot read PR COMMENTS from Gitea — token does not have at least one of required
-  scope(s), required=[read:issue], token scope=read:admin,read:repository.` followed by the
-  instruction to post the override as a review. That is the diagnosis the first attempt should
-  have produced, and `gitea-settings: pass` in the same run. The stage still ends `FAIL`, correctly
-  — there is no valid override on the PR yet.
 - **Toolbox merge gate** (`./infra/devcontainer/dev.sh run bash -c './ci/gate.sh'`), run on the
  rebased branch: **rc 3, `MERGE GATE: UNDETERMINED`**. Green stages: spec-immutability,
  decisions-log, lint, l0 (23 offline cases, 0 failures), render-golden including the new
@@ -208,13 +202,12 @@ missing from its test. `make -C ci test` goes from **FAILED to all suites passed
  diagnoses itself. The **accepting** branch — directive found → live permission lookup → exit 0 —
  has never executed. Posting the override as a **review** on PR #38 is its first real test, and
  I would not be surprised by a third round.
- **`read:issue` is the right scope name — Gitea said so itself, so this is no longer a guess.**
-  Run 206 printed Gitea's own message: `token does not have at least one of required scope(s),
-  required=[read:issue], token scope=read:admin,read:repository`. That both confirms the root
-  cause and names the string, which matters because this repo has been burned by a token *name*
-  that could not exist (`GITEA_SETTINGS_TOKEN`). What is **still** unverified is that the token
-  *mint* accepts it — `POST /users/{u}/tokens` with that scope has not been run. The review route
-  does not depend on it.
+- **The `read:issue` scope name is unverified.** `set-ci-token.sh` now requests it, but I did not
+  mint a token to confirm Gitea 1.24.3 accepts that exact string — the script's own header warns
+  that "Gitea token scopes are coarse; grant the least that works on your version and confirm the
+  check goes green rather than assuming the scope name", and this repo has already been burned by
+  a *name* that could not exist (`GITEA_SETTINGS_TOKEN`). **If the mint fails, the scope string is
+  the first suspect.** The review route does not depend on it.
 - **I did not verify that Gitea lets a PR's own author submit a `COMMENT`-type review.** Gitea
  blocks author self-*approval*; "Comment" is expected to be allowed, and that expectation is now
  load-bearing for the recommended route. It is one click to find out, and I deliberately did not