README has said `docker run ... ghcr.io/coffey-labs/ihasmail:latest` since the
Docker instructions were written, and the docs site repeats it in four places.
Nothing ever pushed that image. `docker pull` answers `denied`, because the
package does not exist: .github/workflows held ci.yml and nothing else, and
there is no reference to ghcr.io, docker/build-push or docker push anywhere in
this repo. The instructions have been wrong the whole time.
Adds the workflow that makes them true. It fires on a published release, and
by hand for a ref -- the same dispatch trigger ci.yml carries, and the only
way to build an image for the tags that predate this file.
Two architectures on native runners rather than one build under QEMU.
Emulated arm64 runs `npm ci` and the Vite build through instruction
translation, which takes tens of minutes and sometimes exhausts memory;
ubuntu-24.04-arm is free for public repositories and does it at native speed.
The cost is pushing by digest and joining the two into one manifest at the
end, which is what the third job does.
`latest` moves only for a real release. A prerelease that moved it would hand
every `:latest` deployment an unfinished build, and a dispatch run has to ask
for it deliberately.
Also documents the images in README: which tags exist, that the dated tag is
the one to pin, and that building it yourself is still fully supported --
`docker compose up --build` is unchanged and the image is a convenience, not a
new requirement.
Worth knowing before the first run: GHCR creates a new package **private**,
even for a public repository, so an anonymous pull will still be refused until
the visibility is changed by hand. That is written at the top of the workflow,
because it is the failure that looks like success.
CI triggers on a push to main and on pull requests, and on nothing else.
That left no way to put a check on 7a1e5ee -- the commit production is
running -- after GitHub's Actions outage on 2026-08-26 orphaned every run
created during it.
Those runs are not merely slow. GitHub accepted them, allocated zero
jobs, and left them in a state its own API contradicts itself about:
gh run rerun -> "cannot be rerun; This workflow is already running"
gh run cancel -> "Cannot cancel a workflow run that is completed"
gh api -> status=queued, conclusion=null, jobs=0
Neither recoverable nor clearable, and with no manual trigger the only
remaining option would have been an empty commit pushed to main to move
the ref -- which is both a junk commit and against how changes land here.
workflow_dispatch also covers the ordinary case of wanting a check on a
commit that predates a CI change.
jcoffey-dev