The remote release tree is never pruned, so the deploy host grows without bound

[ptr727]

Found while reviewing this pipeline against the new fleet hugo type (ptr727/ProjectTemplate#560), which asserts hugo.deploy.retention. This is the one finding with an outage attached, so it is worth reading before the other two.

The gap

deploy/make-release.sh prunes correctly and even asserts the result, which is what makes this easy to miss:

# deploy/make-release.sh:212-230
echo "==> pruning to the newest $KEEP_RELEASES releases"
mapfile -t all < <(find "$ROOT/releases" -mindepth 1 -maxdepth 1 -type d -printf '%f\n' | sort)
target="$(basename "$(readlink "$ROOT/current")")"
...
remaining=$(find "$ROOT/releases" -mindepth 1 -maxdepth 1 -type d | wc -l)
if [ "$remaining" -gt "$KEEP_RELEASES" ]; then
    echo "prune failed: $remaining releases remain, expected at most $KEEP_RELEASES" >&2
    exit 1
fi

But $ROOT in CI is the scratch bundle, not the host:

# .github/workflows/deploy-site-task.yml:89
deploy/make-release.sh "${RUNNER_TEMP}/bundle" "${{ steps.release.outputs.id }}"

${RUNNER_TEMP}/bundle is a fresh tree holding exactly one release, so remaining is always 1, the assertion passes trivially, and the prune has never touched the deploy host. grep -n 'ssh |prune|rm -rf' .github/workflows/deploy-site-task.yml returns only the two -e "ssh ..." transport flags. There is no remote prune step anywhere in the deploy path.

The upload deliberately carries no --delete, which is correct (at an environment root it would remove the rollback targets), so nothing else reclaims the space either. OPERATIONS.md:162-166 describes the ten-release policy against the local-mirror path, which is accurate for that path and reads as coverage for this one.

Why it matters

<environment>/releases/ grows by one full release per deploy, forever. --link-dest keeps the marginal cost low while releases stay similar, but nothing bounds the count, and the failure surfaces as the site going down when the disk fills rather than as a red deploy. That is the exact shape the assertion in make-release.sh was written to prevent, applied to the wrong tree.

The fix

A step after the pointer flip that prunes <environment>/releases/ on the host and asserts the count converged, failing the deploy when it does not. Two constraints worth carrying over from the local implementation, both already right there:

• The release current resolves to is never a prune candidate, whatever the sort order says.
• The assertion is the point. A prune whose pattern stops matching reports success while the disk fills, which is the same failure class as a gate that stops gating.

Worth noting the deploy key is rrsync -wo confined, so a remote prune needs either a second forced command or a host-side timer. A host-side timer is the option that keeps the deploy key with no delete capability at all, at the cost of the deploy no longer being able to assert the outcome. If the timer is preferred, the deploy should still read the count back and fail on divergence, so the assertion survives.

The fleet reference leaf (catalog/snippets/workflows/deploy-site-task.yml in ptr727/ProjectTemplate#560) carries this step, so it currently leads this repo by one.

Recorded in the hub registry as a driftNote against hugo.deploy.retention until it clears.

[ptr727]

Correcting this. The premise is wrong and the repo side is right, so I am closing it rather than leaving a work item that would make this repo worse.

What I missed

OPERATIONS.md:172-179 already assigns the prune to the host, explicitly:

This repo	The host
...	Config-watchdog and release-prune timers
...	Where a release may be written, and what happens after

And OPERATIONS.md:248-251 records why the deploy cannot do it: the key is an rrsync forced command confined to /srv/blog/sites, and write-only. Write-only blocks the server acting as sender, so that key can neither delete a release nor read the destination back to count what is there. Both halves of what I asked for are impossible for it, by design.

So the only way to satisfy the issue as I filed it would have been to widen the deploy key until it could delete and list. That trades a genuine confinement boundary for a green check, and the boundary is worth more. The design here is correct and the reasoning for it is already written down.

What was actually true, and what it changed

The narrow factual observation stands: deploy/make-release.sh prunes $ROOT, CI passes ${RUNNER_TEMP}/bundle, so the assertion at :227-230 runs against a one-release scratch tree and is vacuous on that path. That is a real property. What I got wrong was the consequence: I read it as unbounded growth, when the growth is bounded by a host-side timer the ownership table already assigns.

The defect was in the hub check I was reviewing against, not here. hugo.deploy.retention and WORKFLOW.md D5.6 demanded an in-pipeline prune and assertion, which is unsatisfiable for any repo that confines its credential properly. Both are fixed in ptr727/ProjectTemplate#560: retention is now bounded by a declared count with one side recorded as owning the prune, asserted in the deploy where the credential can observe the destination and owned by the host where it cannot. What it still rejects is a scratch-tree prune, a best-effort prune, and neither side owning it. This repo satisfies the corrected version as it stands, and its registry driftNote for retention has been dropped.

Thank you for the ownership table being there to be read. Without it this would have looked like an omission rather than a decision, which is the failure mode it exists to prevent.

One thing worth a look, separately

Not a defect and not tracked here. make-release.sh's prune and its assertion are dead code on the CI path while being live on the local-mirror path, and the same script serves both. If the local path ever stops being used, a reader would reasonably take that assertion as covering the deploy. A comment at :212 naming which path it guards would keep that honest. Entirely your call, and not worth a ticket on its own.

Closing as invalid, with the correction recorded here rather than by deleting it.