feat: pull the published image on launch #55

Merged

claudiomaradonna merged 4 commits from feat/auto-pull into master 2026-10-26 19:15:09 +01:00

Conversation 0 Commits 4 Files changed 13 +336 -49

motoko commented 2026-10-26 19:06:55 +01:00

Collaborator

Copy link

Why

The client images are now republished nightly for Linux amd64 and arm64
(#53, #54), but a host only picks them up when someone reruns
./install.sh. Until then claude, codex and opencode keep running
the clients from the day of the install. The launcher could keep them
current by itself.

Two alternatives were set aside. Checking at most once a day would need
a state file per client. Stopping the launch when a pull fails would
block offline work. A marker written by the installer, to protect local
builds automatically, would add state and tie the installer to the
launcher; instead, a setting turns the pull off.

What changed

On Linux x86_64 and aarch64, a launch on the default image now pulls
git.unitoo.it/claudiomaradonna/<image>:latest and tags it with the
local name before it starts. A workspace Dockerfile.<client> or
Dockerfile.azkaban then builds on the fresh image during the same
launch. Nothing is pulled:

• with --image or AZKABAN_IMAGE;
• on macOS or on other architectures;
• under --dry-run, which prints # would pull ... instead.

If the pull or the tag fails, the launch warns and runs the local image.
It stops only when there is no local image.

AZKABAN_AUTO_PULL=0 in an identity's env, or in its env.<client>,
turns the pull off. Any value other than 0 or 1 stops the launch.
The image is shared by every identity, so keeping an image built with
--build, --tz or --no-cache means setting the control in each
identity that launches the client. After such a build on a host that
pulls, the installer prints a reminder.

The registry address now lives only in clients/registry.sh, which the
installer and the launcher both read. Updating azkaban itself still
takes ./install.sh.

How to verify

1. On a Linux amd64 or arm64 host with rootless Podman, install from this
   branch, then run claude .. Standard error shows
   claude: pulling git.unitoo.it/claudiomaradonna/claude-code:latest
   and Podman's output, then the client starts. On master no pull
   happens.
2. Add AZKABAN_AUTO_PULL=0 to ~/.azkaban/identities/default/env and
   launch again: no pull line appears. AZKABAN_AUTO_PULL=false stops
   the launch with AZKABAN_AUTO_PULL must be 0 or 1.
3. With the network down, a launch prints
   claude: WARNING: updating claude-code:latest from ... failed; running the local image
   and starts.

make lint && .agents/hooks/shellcheck.sh repo && make test passes on
the tip. The new tests/integration/test_auto_pull.sh tests, the
AUTO_PULL control check, and the installer reminder fail on master.
The first commit pins that launches on other machines and on macOS do
not pull. Not tried: a real pull with rootless Podman, and
make test-e2e.

Considerations

Each launch now adds a registry round trip, about a second when the
image is already current. Every launch also replaces the image with
whatever was last pushed, with no signature or digest check. The trust
is the same as for an install, but now it applies on every launch.
Each new image leaves the previous one untagged; the README points to
podman image prune and to podman rmi for installed version tags.

## Why The client images are now republished nightly for Linux amd64 and arm64 (#53, #54), but a host only picks them up when someone reruns `./install.sh`. Until then `claude`, `codex` and `opencode` keep running the clients from the day of the install. The launcher could keep them current by itself. Two alternatives were set aside. Checking at most once a day would need a state file per client. Stopping the launch when a pull fails would block offline work. A marker written by the installer, to protect local builds automatically, would add state and tie the installer to the launcher; instead, a setting turns the pull off. ## What changed On Linux x86_64 and aarch64, a launch on the default image now pulls `git.unitoo.it/claudiomaradonna/<image>:latest` and tags it with the local name before it starts. A workspace `Dockerfile.<client>` or `Dockerfile.azkaban` then builds on the fresh image during the same launch. Nothing is pulled: - with `--image` or `AZKABAN_IMAGE`; - on macOS or on other architectures; - under `--dry-run`, which prints `# would pull ...` instead. If the pull or the tag fails, the launch warns and runs the local image. It stops only when there is no local image. `AZKABAN_AUTO_PULL=0` in an identity's `env`, or in its `env.<client>`, turns the pull off. Any value other than `0` or `1` stops the launch. The image is shared by every identity, so keeping an image built with `--build`, `--tz` or `--no-cache` means setting the control in each identity that launches the client. After such a build on a host that pulls, the installer prints a reminder. The registry address now lives only in `clients/registry.sh`, which the installer and the launcher both read. Updating `azkaban` itself still takes `./install.sh`. ## How to verify 1. On a Linux amd64 or arm64 host with rootless Podman, install from this branch, then run `claude .`. Standard error shows `claude: pulling git.unitoo.it/claudiomaradonna/claude-code:latest` and Podman's output, then the client starts. On `master` no pull happens. 2. Add `AZKABAN_AUTO_PULL=0` to `~/.azkaban/identities/default/env` and launch again: no pull line appears. `AZKABAN_AUTO_PULL=false` stops the launch with `AZKABAN_AUTO_PULL must be 0 or 1`. 3. With the network down, a launch prints `claude: WARNING: updating claude-code:latest from ... failed; running the local image` and starts. `make lint && .agents/hooks/shellcheck.sh repo && make test` passes on the tip. The new `tests/integration/test_auto_pull.sh` tests, the `AUTO_PULL` control check, and the installer reminder fail on `master`. The first commit pins that launches on other machines and on macOS do not pull. Not tried: a real pull with rootless Podman, and `make test-e2e`. ## Considerations Each launch now adds a registry round trip, about a second when the image is already current. Every launch also replaces the image with whatever was last pushed, with no signature or digest check. The trust is the same as for an install, but now it applies on every launch. Each new image leaves the previous one untagged; the README points to `podman image prune` and to `podman rmi` for installed version tags.

motoko added 4 commits 2026-10-26 19:07:01 +01:00

test: pin that launches without published images do not pull ... a40ca2a247

Launches on machines without published images and on macOS run the
local image without pulling. A uname stub whose machine tests choose
with stub_machine lets the suite name the machine.

feat: pull the published image on launch ... 40681ed244

On Linux amd64 and arm64, a launch on the default image now pulls the
image the forge publishes nightly and names it as the local one, so the
clients stay current without rerunning the installer. AZKABAN_AUTO_PULL=0
in an identity's env or env.<client> turns it off. A failed pull warns
and runs the local image, and stops the launch only when there is none.
The published registry moves to clients/registry.sh, which the installer
and the launcher both read.

feat(install): suggest AZKABAN_AUTO_PULL=0 after a local build ... b7c78288cb

On a Linux amd64 or arm64 host, every launch now pulls the published
image over a local build, so the installer says how to keep it.

docs: describe the pull on launch ... 4fa0ee4bac

The README tells which launches pull the published image, how a failed
pull behaves, and how AZKABAN_AUTO_PULL=0 keeps a local image; the
development guide names the registry's new home.

claudiomaradonna merged commit 4fa0ee4bac into master 2026-10-26 19:15:09 +01:00

claudiomaradonna deleted branch feat/auto-pull 2026-10-26 19:15:15 +01:00

Sign in to join this conversation.

Reviewers

No reviewers

Labels

Clear labels

No items

No labels

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

claudiomaradonna/azkaban!55

No description provided.