feat: build a shared Dockerfile.azkaban per client #38

Merged
claudiomaradonna merged 3 commits from feat/shared-dockerfile into master 2026-10-07 21:55:55 +02:00
Collaborator

Why

A workspace that needs the same tools for every client had to carry one
near-identical Dockerfile.<client> per client, each naming its own base
image and user.

What changed

  • Without a Dockerfile.<client>, a launch builds the workspace's
    Dockerfile.azkaban with podman build --from localhost/<client image>:latest,
    which replaces the file's first FROM, so each client gets its own image
    under the usual tag. The client's own file still wins.
  • One approval, recorded in ~/.azkaban/approved/azkaban/, serves every
    client; the prompt says so, and the launch and dry-run lines name the base.
  • README Custom images documents the shared file, including USER 1000 and
    that only the first FROM changes.

Verification

  • make lint && .agents/hooks/shellcheck.sh repo && make test: 33 shell
    files clean, 307 tests, 0 failures.
  • Not run: --from on real Podman; one claude . and one codex . launch
    in a workspace with a Dockerfile.azkaban confirms it.
## Why A workspace that needs the same tools for every client had to carry one near-identical `Dockerfile.<client>` per client, each naming its own base image and user. ## What changed - Without a `Dockerfile.<client>`, a launch builds the workspace's `Dockerfile.azkaban` with `podman build --from localhost/<client image>:latest`, which replaces the file's first `FROM`, so each client gets its own image under the usual tag. The client's own file still wins. - One approval, recorded in `~/.azkaban/approved/azkaban/`, serves every client; the prompt says so, and the launch and dry-run lines name the base. - README Custom images documents the shared file, including `USER 1000` and that only the first `FROM` changes. ## Verification - `make lint && .agents/hooks/shellcheck.sh repo && make test`: 33 shell files clean, 307 tests, 0 failures. - Not run: `--from` on real Podman; one `claude .` and one `codex .` launch in a workspace with a `Dockerfile.azkaban` confirms it.
A workspace that needs the same tools for every client had to carry one
near-identical Dockerfile.<client> per client.

Without a Dockerfile.<client>, a launch now builds the workspace's
Dockerfile.azkaban with podman build --from set to the invoked client's
installed image, which replaces the file's first FROM, so one ordinary
Dockerfile gives each client its own image under today's tag rule. The
client's own file still wins. The shared file has one approval record
per workspace in ~/.azkaban/approved/azkaban/, which every client reads;
its prompt says the approval covers every client, and the launch and
dry-run lines name the base image. Podman 4.3 documents --from.
Custom images now explains that a Dockerfile.azkaban serves every
client without a file of its own, built on the invoked client's image
in place of its first FROM, with USER 1000 for the client's user and
one approval in ~/.azkaban/approved/azkaban/ for every client. The
Security model, the ~/.azkaban tree, the dry-run line, and the build
failure entry in Troubleshooting name the shared file as well.
The change review and the documentation audit found two behaviors no
test guarded and wording that did not match the launcher's output.

- Tests: a broken Dockerfile.<client> symlink is refused rather than
  passed over for the shared file, and a headless launch's warning
  names an unapproved Dockerfile.azkaban; each fails when its launcher
  line is reverted. The approval test drops a build check the per-client
  test already makes and is named for what it guards.
- README: what the shared file's FROM may name, the record and prompt
  sentence, the dry-run lines for either file, the build failure text,
  and only the first FROM changing, without the misleading multi-stage
  advice.
- examples: the skip control also skips Dockerfile.azkaban.
claudiomaradonna deleted branch feat/shared-dockerfile 2026-10-07 21:55:58 +02:00
Sign in to join this conversation.
No reviewers
No labels
No milestone
No project
No assignees
1 participant
Notifications
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!38
No description provided.