ci: publish the site by bumping kvartsi's content pin #1

oap · 2026-09-07T22:30:51-07:00

oap commented

2026-09-07 22:30:51 -07:00

This vault is the content submodule of oap/kvartsi, which builds ოუენი.გე. Until now that pin only moved when someone moved it by hand — so the deployed site drifted behind the vault by however long it had been since the last manual bump and rsync. Currently since June.

.forgejo/workflows/publish.yaml moves it from CI instead. Writing kvartsi's gitlink to the pushed SHA is both the record of what is live and the trigger for kvartsi's deploy job, so there is no second dispatch mechanism to keep working.

Why pin rather than track the tip

Letting kvartsi track main would be simpler, but the pin makes kvartsi's history say exactly which vault revision produced each deploy — which is what makes a bad build bisectable and rollback-able.

Why it retries

concurrency is not enough on its own. Forgejo documents it as best-effort and cancels asynchronously, so two publish runs can reach git push from the same base. The loser is rejected as a non-fast-forward — and if the loser carries the newer content, the site ends up pinned to the older vault revision with only a red job to show for it. Reproduced locally before writing the retry.

So the push re-fetches and replays on rejection, and refuses to move the pin to a commit the current pin already descends from. Back-to-back pushes converge on the newest in either arrival order. The same retry covers the other writer to v5 — you, pushing to kvartsi by hand.

Depends on

KVARTSI_TOKEN on this repo, provisioned by nas (nix-config forgejo-actions-secrets). The per-job token Forgejo injects is scoped to this repo and its pushes deliberately do not trigger workflows, so it cannot be used here.
kvartsi's deploy workflow, and the nix runner.

Nothing happens until those land; merging this early is harmless.

This vault is the content submodule of [oap/kvartsi](https://git.owenap.com/oap/kvartsi), which builds ოუენი.გე. Until now that pin only moved when someone moved it by hand — so the deployed site drifted behind the vault by however long it had been since the last manual bump and rsync. Currently since June. `.forgejo/workflows/publish.yaml` moves it from CI instead. Writing kvartsi's gitlink to the pushed SHA is both the record of what is live *and* the trigger for kvartsi's deploy job, so there is no second dispatch mechanism to keep working. ### Why pin rather than track the tip Letting kvartsi track `main` would be simpler, but the pin makes kvartsi's history say exactly which vault revision produced each deploy — which is what makes a bad build bisectable and rollback-able. ### Why it retries `concurrency` is not enough on its own. Forgejo documents it as best-effort and cancels asynchronously, so two `publish` runs can reach `git push` from the same base. The loser is rejected as a non-fast-forward — and if the loser carries the *newer* content, the site ends up pinned to the older vault revision with only a red job to show for it. Reproduced locally before writing the retry. So the push re-fetches and replays on rejection, and refuses to move the pin to a commit the current pin already descends from. Back-to-back pushes converge on the newest in either arrival order. The same retry covers the other writer to `v5` — you, pushing to kvartsi by hand. ### Depends on - `KVARTSI_TOKEN` on this repo, provisioned by nas (nix-config `forgejo-actions-secrets`). The per-job token Forgejo injects is scoped to this repo and its pushes deliberately do not trigger workflows, so it cannot be used here. - kvartsi's `deploy` workflow, and the `nix` runner. Nothing happens until those land; merging this early is harmless.

oap added 1 commit

2026-09-07 22:30:51 -07:00

ci: publish the site by bumping kvartsi's content pin e6cdd1d940

This vault is the content submodule of oap/kvartsi, which builds ოუენი.გე.
Until now that pin only moved when someone moved it by hand, so the deployed
site drifted behind the vault by however long it had been since the last
manual submodule bump and rsync — currently since June.

Move it from CI instead. Writing kvartsi's gitlink to the pushed SHA is both
the record of what is live and the trigger for kvartsi's deploy job, so there
is no separate dispatch mechanism to keep working.

The bump does not trust the scheduler to order runs. Forgejo documents
concurrency as best-effort and cancels asynchronously, so two publish runs can
reach `git push` from the same base; the loser is rejected as a non-fast-
forward, and if the loser carries the newer content the site ends up pinned to
the older vault revision with only a red job to show for it. So the push
retries from a fresh fetch, and refuses to move the pin to a commit the current
pin already descends from. Back-to-back pushes converge on the newest in either
arrival order. The same retry covers the other writer to v5 -- you.

Pinning beats letting kvartsi track main's tip: the pin makes kvartsi's history
say exactly which vault revision produced each deploy, which is what makes a
bad build bisectable and rollback-able.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

oap reviewed

2026-09-07 22:34:20 -07:00

.forgejo/workflows/publish.yaml Outdated

					
				@ -0,0 +77,4 @@

				            # 40-character pointer.

				            git update-index --cacheinfo "160000,$SHA,content"

				            git -c user.name="forgejo-actions" \

				                -c user.email="actions@git.owenap.com" \

Let's use "owen+forgejo-actions@owenap.com" instead.

oap added 1 commit

2026-09-07 22:36:16 -07:00

ci: attribute pin bumps to owen+forgejo-actions@owenap.com c5720adedc

Forgejo maps a commit to an account by author email, and actions@git.owenap.com
belongs to nobody — every pin bump would have shown as an unrecognised author.
Plus-addressing a real address keeps the attribution while the local part still
says which automation wrote it.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

oap commented

2026-09-07 22:36:21 -07:00

Done in c5720ad — owen+forgejo-actions@owenap.com. Added a note on why: Forgejo maps commits to accounts by author email, so the old actions@git.owenap.com would have shown every pin bump as an unrecognised author.

Done in c5720ad — `owen+forgejo-actions@owenap.com`. Added a note on why: Forgejo maps commits to accounts by author email, so the old `actions@git.owenap.com` would have shown every pin bump as an unrecognised author.

oap force-pushed forgejo-actions from c5720adedc to 5b1af0a10e

publish / bump (push) Failing after -3s

Details

2026-09-07 22:38:19 -07:00

Compare

oap merged commit 5b1af0a10e into main

2026-09-07 22:38:36 -07:00

oap deleted branch forgejo-actions

2026-09-07 22:38:36 -07:00

Sign in to join this conversation.

No reviewers

No labels

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

oap/kartuli-ena!1

Rows
Columns