Build the release image and tag it with the commit it was built from.

Usage

mix ymer_node.build

No options and no arguments. The version comes from mix.exs, the image is built for the machine's own architecture, and three tags move to it: the version, latest, and the revision — the short sha of the commit the build was made from, marked when the tree carried uncommitted changes. That same revision rides on the image's OCI revision label and inside the node's own serverInfo.version, so docker images, the label, and a live initialize all name one commit. Where no revision can be named — no git, or a directory that is no work tree — the image gets the version tag and latest only, carries no label, and answers with the bare version.

What moves ymer-node:latest

docker-compose.yml runs that tag and never builds it, so no compose up moves it. Only a build does — this task, or a plain docker build -t ymer-node:latest . for a reader without Elixir — or a deliberate docker tag, which is how an older image is put back under the name compose reads. A container picks the new image up on the next docker compose up -d, and mix ymer_node.deploy is what performs that against the install.

Keeping the image set in hand

A revision tag is minted per commit built, so revision tags accumulate where the version tag and latest merely move. Nothing here deletes any of them. Trimming is a judgement about which builds are still worth going back to — yours to make, not a build's — so the commands live here, beside the code that mints the tags, rather than running on their own.

What has accumulated, with the dates to judge it by. Read the dates rather than the order: this listing is not sorted by creation time, and it prints it only to the second.

docker images ymer-node --format '{{.Tag}} {{.ID}} {{.CreatedAt}}'

Which containers exist and what image each is on — the check to make before removing anything, since a container may be the only thing still holding an image:

docker ps -a --format '{{.Names}} {{.Image}} {{.Status}}'

Dropping one revision tag. Without -f, so Docker itself is the safety net: it removes a tag from an image that has others, and refuses outright to delete an image's last tag while any container — running or stopped — still uses it.

docker rmi ymer-node:<revision>

Whether superseded images linger at all depends on the image store. Measured on Docker's containerd store (docker info names it): moving every tag off an image reclaims it there and then, so nothing is left to prune. On a storage driver that does leave them, docker image prune removes what no tag names.

What stops the build, and what only warns

A missing docker, a daemon that does not answer, and a non-zero build all stop with a message naming the next action. A dirty working tree does not: the revision records the dirt instead, refusing would block every build-to-test cycle, and tagging only some of the tags would make the tag set depend on state the caller never passed. The warning says the image will carry uncommitted code, and the build proceeds. Where the check itself cannot run — no git, or a directory that is no work tree — the task says so in one line and still builds.

The subprocess's own output never stops a build either, whatever bytes it carries: Mix.Tasks.YmerNode.Build.LiveOutput is where that is kept.

A build that dies inside mix deps.get usually means the network intercepts TLS, so hex's certificate no longer chains. This image carries no company certificate by design (the Dockerfile header says why), so the failure message names that case; the network itself is never probed.

The module is wrapped in if Mix.env() in [:dev, :test], which keeps it callable under the default :dev and out of the prod release — the release runs the image this task builds and has no use for the builder.