Skill: cover publishing images to a registry from CI - #294
Merged
Conversation
The skill took local builds as the only path: it never mentioned --publish-images, the build policies, or CI, and named a registry once, in the k8s init example, where it reads as a Kubernetes requirement rather than a build strategy. An agent following it end to end produces a project that rebuilds every image on every deploy host with no route to prebuilt images. Adds an optional section after the build step explaining the discovery pair (name from stack.yml + tag from the recipe repo commit hash, registry inferred from the git host), the publish flag, and a GitHub Actions workflow. Also tightens the container-name rule. It said names are <organization>/<name> without saying which organization, so a name that reads well but does not match the GitHub org passes validation and silently defeats registry discovery later — a breaking rename to fix. Says which namespace, and that the second segment is free-form so one repo can publish several images. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_019ooJdzrsdCT2QSFnRida4j
Hit this on a real project: the workflow the skill now recommends built both images and pushed neither, with only a WARN in the log saying they were not built from committed, pinned inputs. The cause was that stack.lock did not exist in the repo, so CI generated it at build time; an uncommitted lock is treated as unpinned and yields a stackdev- tag, which is never published. The bullet said "only clean, committed, fully-pinned state publishes" but did not say that generating and committing the lock is a setup step, so following the skill exactly produces a workflow that silently never publishes. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_019ooJdzrsdCT2QSFnRida4j
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
skills/deploy-with-stack/SKILL.mdis the only file that reaches an agent's context, and it treats local builds as the only path. It never mentions--publish-images, the build policies, or CI, and names a registry exactly once — the--image-registryflag in the k8sinitexample, where it reads as a Kubernetes requirement rather than a build strategy.The result is that an agent following the skill end to end produces a project that rebuilds every image on every deploy host, with no route to prebuilt images.
docs/fetching-containers.mdanddocs/image-names.mdcover this well; the skill just never points at it.Found while using the skill on a real project — the container names came out as
kestrel/apiandkestrel/frontendin a repo under a different GitHub org, which validates fine and would have silently defeated ghcr discovery.What
--publish-images, and a ready-to-copy GitHub Actions workflow modelled on the one instack-test-stacks. Closes with the three things that actually bite: namespace correctness,stackdev-versions never publishing, and architecture matching.<organization>/<name>without saying which organization. Now says the namespace is the one the images publish under (for github, the org owning the repo), that the second segment is free-form and not derived from the repo name — so one repo can publish several images, asexample-todo-listdoes withtodo-frontend/todo-backend— and that nothing validates the namespace, so a wrong one is a silent miss rather than an error.Docs only; no code paths touched.
🤖 Generated with Claude Code
https://claude.ai/code/session_019ooJdzrsdCT2QSFnRida4j