Cut the first app release: Topology

[cshuttle]

Part of #25

Question

Cut Topology's first release through the shared workflow — the end-to-end proof.

Topology is the cleanest candidate: one image, one Komodo stack, a build workflow that already chains into komodo-deploy.yml. Adopting here exercises the whole path (tag → build → versioned image → deploy) with the least blast radius.

Done when: a version tag exists, ghcr.io/cshuttle/topology:<version> exists, the GitHub Release exists, the Komodo stack runs that version under whatever pinning model was chosen, and the topology dashboard is verified live afterwards.

Anything the shared workflow can't express, fix in the shared workflow — Topology is the proof, not a special case.

[cshuttle]

Resolution

The estate's first application release is live, and the model is proven end to end rather than in principle.

Release	Topology v1.0.0
Image	ghcr.io/cshuttle/topology:v1.0.0 = sha256:79b6a16b… — the same digest :latest already carried. Promoted, not rebuilt.
Git tag	On 177655b, not HEAD — the commit the image was actually built from
Deployed	Container running ghcr.io/cshuttle/topology:v1.0.0, healthy on consecutive checks
Bumps	Renovate custom manager, verified extracting from the live repo

What landed

• Topology#164 release dispatch workflow · #165 ghcr PAT · #166 compose cutover
• Komodo#156 TOPOLOGY_VERSION in the stack env
• renovate-config#25 custom manager + automerge rule
• workflows#51 → v1.1.1 · #52 → v1.2.0 — two guard fixes this ticket forced

Both guards were wrong, and only running them showed it

v1.1.0 demanded the image be tagged with the ref's HEAD sha. Build workflows carry paths filters, so a docs- or CI-only commit moves the branch without producing an image — and the repo becomes unreleasable until someone touches a build input. Adding the release workflow is itself such a commit, so Topology could never have released. Fixed in v1.1.1 by walking back to find the build's commit; the real run resolved 177655b, 2 commits behind the ref, and tagged there.

v1.1.1 then failed with ghcr.io/cshuttle/topology:latest does not exist. It existed — I had read its digest minutes earlier. cshuttle is a personal account, so a package bootstrapped by a manual push is user-owned and the repo-scoped GITHUB_TOKEN 403s on it, which the registry reports as not found. Topology's build.yml has used a classic PAT since July for exactly this. v1.2.0 adds an optional ghcr-token and rewrites that error, which stated absence as fact and would have sent the next person hunting a missing tag instead of a missing grant.

Ordering was the risk, and it held

TOPOLOGY_VERSION reached the stack (ResourceSync UpdateStack → DeployStack, 13:32) before any compose referenced it, so the stack was never pointed at an undefined variable. ${TOPOLOGY_VERSION:?} makes that failure loud rather than resolving to topology:.

The cutover deployed no new code — v1.0.0 is the digest already running — so the mechanism was proven while the payload was a no-op. The stack needed an explicit deploy: it is in CI_TRIGGERED_STACKS, so it derives no push hook and a compose-only change waits for the auto-pull poll. That is documented behaviour, not a fault.

Renovate verified by extraction, not by silence

A dry run proposing nothing proves nothing here — v1.0.0 is the only release, so a non-matching regex looks identical to a working one. Verified at debug level instead:

depName:      ghcr.io/cshuttle/topology
currentValue: v1.0.0
datasource:   docker
packageFile:  control-plane/stacks.toml
registryUrl:  https://ghcr.io      warnings: []      updates: []

It extracts, authenticates to ghcr, resolves the version, and correctly offers nothing.

(Scoping that run needed RENOVATE_AUTODISCOVER=false and RENOVATE_REPOSITORIES — autodiscovery in the mounted config overrides both a positional repo arg and RENOVATE_REPOSITORIES alone. Worth knowing for the next dry run.)

Left for elsewhere

The PAT is a workaround for user-owned ghcr packages. Atlas already fixed this properly by granting its repo access under the package's Manage Actions access settings, which is why it pushes with GITHUB_TOKEN. Doing that for the rest would let every repo drop GHCR_WRITE_TOKEN — one fewer long-lived credential. Noted on the map rather than expanded here.