Externalise plans to Gitea and accept approvals there (A4, Part H)
- approvals.py: PlanBoard opens one issue per project and posts each plan revision as a comment carrying its rev tag. The state store keeps only a pointer, so gate state can be re-derived from Gitea after a state-volume loss — external truth wins - Gitea comments are a second approval source: revision binding, the typed word approve, and first-approval-wins work exactly as over transport, with a per-channel allowlist because a Gitea login is not a Matrix MXID - Outcomes are echoed to the other channel, so the two records cannot silently disagree about what was approved - A Gitea outage degrades durability of the record, not the ability to approve: planning proceeds and Matrix remains a complete channel - Live test now asserts the server refuses the agent's own merge and its push to the protected branch. That property was previously true only because our code did not attempt it; branch protection makes it structural, and this test fails if the protection is ever relaxed - Fixed a race in the process-group test: killing a group is asynchronous and the grandchild is an orphan, so its exit is not synchronised with our return; the test now waits for death Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
1 parent
affdb9e8aa
commit
d508e9a9b7
6 files changed
+409
-4
No files matched your search
@@ -151,6 +151,12 @@ class GiteaClient:
|
||||
created_at=data.get("created_at", ""),
|
||||
)
|
||||
|
||||
def create_issue(self, repo: str, title: str, body: str) -> int:
|
||||
data = self._request(
|
||||
"POST", f"/repos/{repo}/issues", json={"title": title, "body": body}
|
||||
)
|
||||
return int(data["number"])
|
||||
|
||||
def close_pull_request(self, repo: str, index: int) -> None:
|
||||
self._request("PATCH", f"/repos/{repo}/pulls/{index}", json={"state": "closed"})
|
||||
|
||||
|
||||
Reference in new issue
Block a user