fix(tools): run the publish guard as the committing user, not ci-runner

Documented with `sudo -u ci-runner`, copied from the neighbouring tools that
call the Gitea API. Wrong here: the guard fetches, fetching writes
.git/FETCH_HEAD, and that file belongs to the committing user -- so as
ci-runner it died with "impossibile aprire '.git/FETCH_HEAD': Permesso negato"
before comparing anything.

A guard that cannot run is worse than no guard, since the failure looks like
infrastructure noise rather than an answer. The question it asks is "does what
I have match what is published", so it belongs to whoever holds the working
tree.
This commit is contained in:
2026-07-22 20:38:32 +02:00
parent df77c02b81
commit 385eaca98b
3 changed files with 12 additions and 4 deletions
+5 -1
View File
@@ -11,8 +11,12 @@ That is not hypothetical: 59 commits sat unpushed for a day while a downstream
repo debugged a snapshot-name bug we had already fixed locally (thread entry
furyrs#14, 2026-07-22).
Run it as the user who commits, not as ``ci-runner``: it fetches, which needs
write access to ``.git``, and the question it answers is "does what I have
match what is published".
Usage:
sudo -u ci-runner /opt/ci/venv/bin/python tools/ci-action-published.py
/opt/ci/venv/bin/python tools/ci-action-published.py
... --ref main --no-fetch # skip the network round-trip
Exit 0 when the published `.gitea/` tree matches this working tree, 1 when it