forge-sync pushes as the agent, which its own branch protection refuses from the second run on #91

New issue

Open

opened 2026-10-09 23:09:16 +01:00 by vnprc-agent · 0 comments

vnprc-agent commented

2026-10-09 23:09:16 +01:00

forge-sync pushes the hypervisor's clones as the agent account, and the branch protection it installs on the first run refuses that account on master, so every later run fails on the first repository with new commits.

Primary goals:

Push as the operator, not the agent — the hypervisor's own key (~/.ssh/host, already the recipient of every secret) is registered on the human admin account, and the repository pushes use it; branch protection does not bind an administrator unless told to, so the operator's pushes land while the agent stays refused, which is the property the dev VM witnesses.
The agent key keeps one job — it is registered on the agent account for the dev VM's clones and pull requests only; the command never pushes with it.
Every run converges — a second run with new local commits pushes them; the stub suite gains a case where the forge already protects master and the push still lands, and one where a push with the agent key is refused.

Current state and specifics

scripts/forge-sync: resolve_push_key picks the forge key registered to the agent account and push_repo pushes every forge-sourced registry checkout with it, after reconcile_branch_protection from the first run has applied git/protected-branches. Seen on the public install walk, 2026-10-09, on the second run after the operator committed the secrets changes the first run produced:

repo allod/secrets: present
remote: Forgejo: Not allowed to push to protected branch master
! [remote rejected] HEAD -> master (pre-receive hook declined)
Error: push of allod/secrets to allod/secrets failed

The first run succeeds only because protection does not exist yet. The two-node witness in allod/archetypes runs the command once and never exercises a second push, which is why it passed.

Scope

In: registering the hypervisor key on the human account, pushing with it, the stub cases, and the README's custody paragraph. Out: the dev VM's key and account, unchanged; the witness's second-run case, which rides the next archetypes nexus-pin bump.

Part of allod/strategy#65

`forge-sync` pushes the hypervisor's clones as the agent account, and the branch protection it installs on the first run refuses that account on `master`, so every later run fails on the first repository with new commits. Primary goals: - **Push as the operator, not the agent** — the hypervisor's own key (`~/.ssh/host`, already the recipient of every secret) is registered on the human admin account, and the repository pushes use it; branch protection does not bind an administrator unless told to, so the operator's pushes land while the agent stays refused, which is the property the dev VM witnesses. - **The agent key keeps one job** — it is registered on the agent account for the dev VM's clones and pull requests only; the command never pushes with it. - **Every run converges** — a second run with new local commits pushes them; the stub suite gains a case where the forge already protects `master` and the push still lands, and one where a push with the agent key is refused. ### Current state and specifics `scripts/forge-sync`: `resolve_push_key` picks the forge key registered to the agent account and `push_repo` pushes every forge-sourced registry checkout with it, after `reconcile_branch_protection` from the first run has applied `git/protected-branches`. Seen on the public install walk, 2026-10-09, on the second run after the operator committed the secrets changes the first run produced: repo allod/secrets: present remote: Forgejo: Not allowed to push to protected branch master ! [remote rejected] HEAD -> master (pre-receive hook declined) Error: push of allod/secrets to allod/secrets failed The first run succeeds only because protection does not exist yet. The two-node witness in `allod/archetypes` runs the command once and never exercises a second push, which is why it passed. ### Scope In: registering the hypervisor key on the human account, pushing with it, the stub cases, and the README's custody paragraph. Out: the dev VM's key and account, unchanged; the witness's second-run case, which rides the next archetypes nexus-pin bump. Part of allod/strategy#65

vnprc-agent referenced this issue from allod/strategy

2026-10-09 23:10:21 +01:00

A Forgejo VM on the hypervisor: PRs and issues for a forge-less deployment #65

vnprc-agent referenced this issue from a commit

2026-10-10 15:10:28 +01:00

forge VM: allod/nexus#91 built, reviewed and witnessed; relay order and PR bodies

vnprc-agent referenced this issue from a commit

2026-10-10 15:10:31 +01:00

in-flight: forge VM allod/nexus#91 built, unrelayed

vnprc-agent referenced this issue from a commit

2026-10-10 15:27:38 +01:00

forge VM: allod/nexus#91 landed and pinned through