fix: the README's first command pointed at an image that did not exist - #21
Merged
Conversation
…not exist Reported by the first person to try it, which is the whole point of writing a section for people who have not seen the project before — and an unambiguous failure of the milestone that added it. The README said `docker run ghcr.io/…/oxinit:demo`. No tag had been pushed, so the release workflow that published that image had never run. `test-demo` passed the entire time: it builds the image locally and checks that one, so the test and the README were talking about two different images and nothing compared them. The demo image is documentation, not a release artifact. It is published from main by CI now, rather than from a tag by the release workflow — tying it to a release meant the README pointed at something that would not exist until a version number had been declared, which is a separate decision and was not about to be made. The release workflow adds a versioned tag and nothing else. The README leads with the two commands that need no registry, and offers the pull second. And CI checks that the image reference in the README is the one the publish step pushes. That is the half a test on a locally built image structurally cannot cover, and it is the half that failed. Not automatable, and stated in ROADMAP rather than left to be discovered again: a package pushed by Actions is private by default, and an anonymous pull against a private package fails with the same `denied`. Making it public is a one-time setting on the repository's package page.
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.
Reported by the first person to try it — which is the whole point of
writing a section for people who have not seen the project before, and an
unambiguous failure of the milestone that added it.
No tag had been pushed, so the release workflow that published that image
had never run.
The test passed the whole time
test-demobuilds the image locally and checks that one. The test andthe README were talking about two different images, and nothing compared
them. A guard that cannot see the thing it is guarding is not a guard.
Three fixes, one of them obvious
The demo image is documentation, not a release artifact. It is now
published from
mainby CI. Tying it to a release meant the READMEpointed at something that would not exist until a version number had been
declared — a separate decision, and not one anybody was about to make.
The release workflow adds a versioned tag and nothing else.
The README leads with what works with no registry at all —
cargo xtask fetchandcargo xtask demo— and offers the pull second.CI checks that the image reference in the README is the one the publish
step pushes. That is the half a locally-built-image test structurally
cannot cover, and it is the half that failed.
One thing nobody can automate
A package pushed by Actions is private by default, and an anonymous
pull against a private package fails with exactly the
deniedabove.After this merges and CI publishes the image once, the package has to be
made public on the repository's package settings page — that belongs to
whoever owns the account, not to CI, and I have not claimed the pull
command works until that is done and verified.