gitea: set a default branch and a pull request's base by named tools; announce a retargeted pull request again (issue 1422)

2026-10-28 11:07:31 +01:00
parent e057670bc4
commit 7c2aa0a739
10 changed files with 184 additions and 13 deletions
@@ -312,6 +312,15 @@ read-only. With a `user` it adds the teams that user is in and its effective rig
 listing those above read: the check that a build key's user, `nox-builder` in `builders`, reads and pushes nothing. The
 tools' token lacks `read:organization` (the forge answers 403), so the read goes with the administrator's login, GET only.

+### Two settings have named tools, and a retargeted pull request is judged again
+
+`gitea_api` refuses a repository's settings and a pull request's base (guard.ts). Issue 1422 note 7 gave each its tool:
+`gitea_default_branch_set` (owner, repo, branch, why) and `gitea_pull_base_set` (owner, repo, number, base, why). Both
+act as the tools' account, need a reason, refuse a branch the repository does not have, and answer the value before and
+after; a default must also be a branch a protection rule guards, and only an open pull request has its base changed.
+A pull request's announced head is kept under `owner/repo#number@base`, so a retarget (same head, new base) is
+announced again into the new base by the next poll instead of being skipped as already announced.
+
 ### The merging account writes the repositories the mesh delivers

 `mesh-tools` sets every commit status and merges; outside the organisation it only reads (above), so a pull request of