What's wrong
The design spec commits to publishing a container image after each release (docs/superpowers/specs/2026-08-18-gitlfscache-design.md L199 and L228):``
A container publish step is added after a successful release, gated on the release having produced a version
The plan header claims the same: "a multi-architecture container image publishing from CI". The original dotnet.yml did this in a container: job that ran dotnet publish GitLfsCache.Service/GitLfsCache.Service.csproj -t:PublishContainer -m:1 -p:ContainerRegistry=ghcr.io -p:ContainerImageTags="<version>;latest", gated on should_release.
Commit 6fcbc1b ("ci: adopt the unified dotnet workflow", 2026-08-26) replaced that workflow and deleted the container: job. Commit bb21398 then moved CI onto ktsu-dev/.github's ci-shared.yml. Neither the new ci.yml nor any workflow in ktsu-dev/.github mentions containers or ghcr.
What still exists:
GitLfsCache.Service/GitLfsCache.Service.csproj still has the container properties: EnableSdkContainerSupport, chiseled base image, linux-x64;linux-arm64, ContainerRepository=ktsu-dev/gitlfscache.README.md L46 still documents docker pull ghcr.io/ktsu-dev/gitlfscache:latest.deploy/k8s/statefulset.yaml L28 still deploys image: ghcr.io/ktsu-dev/gitlfscache:latest.
Failure scenario
Anyone deploying with the documented image or the k8s base gets the image built from the last release before 2026-08-26. None of the fixes since then are in it: #30/#32, #45, #47/#61, #46/#60, #57/#68, #48/#67, and the rest. The release notes and NuGet version then disagree with what is actually running.
Suggested fix / acceptance criteria
- After a CI run that produced a release version, a multi-arch (
linux-x64, linux-arm64) image tagged <version> and latest is pushed to ghcr.io/ktsu-dev/gitlfscache. Use GITHUB_TOKEN, with packages: write, which ci.yml already grants, and -m:1, as the old job did.
- Where it lives is a choice. It can be a follow-on job in this repo's
ci.yml that runs after the shared ci job and reads its release output, or an opt-in input on ci-shared.yml so other service repositories can reuse it. If the shared pipeline doesn't expose the released version as an output yet, that is part of this work.
- A release publishes a new
latest, and docker pull ghcr.io/ktsu-dev/gitlfscache:<version> works for that version.
What's wrong
The design spec commits to publishing a container image after each release (
docs/superpowers/specs/2026-08-18-gitlfscache-design.mdL199 and L228):``The plan header claims the same: "a multi-architecture container image publishing from CI". The original
dotnet.ymldid this in acontainer:job that randotnet publish GitLfsCache.Service/GitLfsCache.Service.csproj -t:PublishContainer -m:1 -p:ContainerRegistry=ghcr.io -p:ContainerImageTags="<version>;latest", gated onshould_release.Commit 6fcbc1b ("ci: adopt the unified dotnet workflow", 2026-08-26) replaced that workflow and deleted the
container:job. Commit bb21398 then moved CI ontoktsu-dev/.github'sci-shared.yml. Neither the newci.ymlnor any workflow inktsu-dev/.githubmentions containers or ghcr.What still exists:
GitLfsCache.Service/GitLfsCache.Service.csprojstill has the container properties:EnableSdkContainerSupport, chiseled base image,linux-x64;linux-arm64,ContainerRepository=ktsu-dev/gitlfscache.README.mdL46 still documentsdocker pull ghcr.io/ktsu-dev/gitlfscache:latest.deploy/k8s/statefulset.yamlL28 still deploysimage: ghcr.io/ktsu-dev/gitlfscache:latest.Failure scenario
Anyone deploying with the documented image or the k8s base gets the image built from the last release before 2026-08-26. None of the fixes since then are in it: #30/#32, #45, #47/#61, #46/#60, #57/#68, #48/#67, and the rest. The release notes and NuGet version then disagree with what is actually running.
Suggested fix / acceptance criteria
linux-x64,linux-arm64) image tagged<version>andlatestis pushed toghcr.io/ktsu-dev/gitlfscache. UseGITHUB_TOKEN, withpackages: write, whichci.ymlalready grants, and-m:1, as the old job did.ci.ymlthat runs after the sharedcijob and reads its release output, or an opt-in input onci-shared.ymlso other service repositories can reuse it. If the shared pipeline doesn't expose the released version as an output yet, that is part of this work.latest, anddocker pull ghcr.io/ktsu-dev/gitlfscache:<version>works for that version.