Repository navigation
Expand file tree
/
Copy pathDockerfile
More file actions
126 lines (117 loc) · 7.31 KB
/
Copy pathDockerfile
File metadata and controls
126 lines (117 loc) · 7.31 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
# Global ARG — must be declared before the first FROM to be visible inside a
# later FROM. openabdev/openab's Dockerfile.unified has the identical comment for
# the identical reason: an ARG declared between stages is scoped to the stage
# that follows it and is invisible to FROM itself, so putting it there silently
# builds `FROM ghcr.io/openabdev/openab@` with nothing after the @ — this was
# caught by actually running the build, not by reading the Dockerfile spec.
ARG OPENAB_BASE_DIGEST=sha256:f466b5641bb9a687b5ffa8c80ce0e6c470ff91e49586e3a75be6c62a35f57839
# openab-pty — internal image. Not published; see README.
#
# Multi-stage so that `docker build .` from a clean checkout is the whole build.
# The previous shape needed the binary produced out-of-band and dropped into the
# context, which meant the image and the source could disagree with nothing to
# detect it.
#
# Both stages are pinned by digest. The builder digest is the same one
# openabdev/openab pins in Dockerfile.unified, and for the same stated reason: a
# rolling tag lets a base change alter the output of an unchanged commit, and in
# CI nobody is watching when that happens.
# --- build ------------------------------------------------------------------
FROM docker.io/library/rust:1-bookworm@sha256:e70e2eec3d495fd5c8e0be74adda86507dfac7f51a724fbf9813ff59b2b247c7 AS builder
# musl, so the result is immune to whatever libc the runtime base ships. This is
# not theoretical tidiness: the runtime base is a separately released image, and
# a static binary is the reason a base bump cannot break the process.
RUN apt-get update \
&& apt-get install -y --no-install-recommends musl-tools \
&& rm -rf /var/lib/apt/lists/* \
&& rustup target add x86_64-unknown-linux-musl
WORKDIR /src
COPY runtime/Cargo.toml runtime/Cargo.lock ./
# Prime the dependency layer against the manifests alone, so editing src/ does
# not re-download and rebuild the tree.
RUN mkdir -p src && echo 'fn main() {}' > src/main.rs && echo '' > src/lib.rs \
&& cargo build --release --locked --target x86_64-unknown-linux-musl \
&& rm -rf src
COPY runtime/src ./src
# The touch is load-bearing, not tidiness. Cargo decides freshness by mtime, COPY
# preserves the context's timestamps, and if those land older than the stub
# artifacts above then cargo declares the stub build fresh and the image ships a
# binary whose main() does nothing -- a failure that builds green and only shows
# up as a container that exits instantly.
RUN touch src/main.rs src/lib.rs \
&& cargo build --release --locked --target x86_64-unknown-linux-musl \
&& strip target/x86_64-unknown-linux-musl/release/openab-pty
# --- runtime ----------------------------------------------------------------
# The OAB image is the point rather than a convenience: it already carries the
# agent CLI and already runs as uid 1000, so a session opened here lands in the
# same toolchain the agent uses. That adjacency is the ADR's stated positioning,
# and it is why this image is ~700 MB of base plus a few MB of runtime rather
# than a 20 MB scratch image that would be useless for the purpose.
#
# Pinned to the amd64 manifest inside ghcr.io/openabdev/openab:pre-beta-kiro, not
# :latest. Checked against the fleet rather than assumed: B0 (the real running
# bot) is deployed on pre-beta-kiro, and at the time this was pinned that tag was
# openab 0.10.0 while :latest was still 0.9.0 -- two different images, not two
# names for one. Adjacency means matching what an agent actually runs next to,
# so the pin follows the fleet's tag rather than the one that sounds newest.
#
# A digest, not the tag, for the same reason AGENTS.md pins the Rust builder in
# Dockerfile.unified: a rolling tag lets a base change alter an unchanged
# commit's output, with nothing in the build log to say so. This default only
# applies to local `docker build .`. CI (.github/workflows/image.yml) resolves
# the variant's base digest at build time, records it in the job log and in the
# dev.openab.pty.base-digest label, and a daily scheduled run rebuilds a variant
# when that digest moves. Update this default by hand when needed with:
# T=$(curl -s "https://ghcr.io/token?scope=repository:openabdev/openab:pull&service=ghcr.io" | jq -r .token)
# curl -s -H "Authorization: Bearer $T" \
# -H 'Accept: application/vnd.oci.image.index.v1+json,application/vnd.docker.distribution.manifest.list.v2+json' \
# https://ghcr.io/v2/openabdev/openab/manifests/pre-beta-kiro | jq -r '.manifests[]|select(.platform.architecture=="amd64").digest'
# LICENSING BOUNDARY. This repository is MIT (see LICENSE). That covers the recipe
# below, not what the recipe pulls in: the image built from this line aggregates
# the openab base and, for every variant except `native`, a third-party agent CLI
# under its vendor's own terms. MIT does not and cannot relicense those. See NOTICE.
FROM ghcr.io/openabdev/openab@${OPENAB_BASE_DIGEST}
COPY --from=builder --chown=root:root --chmod=755 \
/src/target/x86_64-unknown-linux-musl/release/openab-pty /usr/local/bin/openab-pty
# --chmod is deliberate, not decoration: entrypoint.sh is 644 in the repository
# (nobody had ever set +x on it — the prior single-stage build only worked
# because it started from a binary built and chmod'd elsewhere) and COPY
# preserves the source mode by default. Without this the image builds clean and
# fails at `crun: open executable: Permission denied` on every single container,
# including as root, which is a confusing way to learn a file has no x bit.
COPY --chown=root:root --chmod=755 deploy/ecs/entrypoint.sh /usr/local/bin/openab-pty-entrypoint
# The startup hook (see runtime/src/hook.rs) merges the tools MCP into the CLI's
# JSON config, and jq is how it does that without the runtime learning any CLI's
# format. The base has no jq, python or (for kiro) node. jq comes from the
# base's Debian release (trixie: 1.7.1); not version-pinned, because Debian
# point releases drop superseded versions and a pin would break the build.
COPY --chown=root:root --chmod=755 deploy/hooks/startup-hook.sh /usr/local/libexec/openab-pty/startup-hook
USER root
RUN apt-get update \
&& apt-get install -y --no-install-recommends jq \
&& rm -rf /var/lib/apt/lists/*
USER 1000
# The listener default is loopback, and the runtime refuses an off-loopback bind
# while it holds no TLS key. Reachability is the deployment's job — a tailscale
# sidecar sharing the network namespace — not this image's.
ENV HOME=/workspace \
RUST_LOG=info \
PTY_LISTEN=127.0.0.1:8090 \
PTY_COMMAND=/usr/bin/bash \
PTY_MAX_SESSIONS=3 \
PTY_ABSOLUTE_TTL=12h \
PTY_IDLE_TTL=8h \
PTY_TOKEN_TTL=12h \
PTY_SCROLLBACK_KIB=1024 \
PTY_FILTER_TERMINAL_RESPONSES=true \
# Empty means no seeding, which is what every deployment did before this
# existed. A deployment opts in by pointing this at a directory another
# container has filled with *.tar.gz; this image fetches nothing itself.
PTY_SEED_DIR="" \
# Reverse-attached tools plane, off by default. Set to a loopback address
# (e.g. 127.0.0.1:8091) to let a Mac lend its OpenAB Computer tools to a session
# through GET /tools/attach/{session}; the CLI then finds them at the URL in
# OPENAB_TOOLS_MCP_URL. Off means: no listener, and /tools/attach refuses.
PTY_TOOLS_LISTEN="" \
PTY_TOOLS_ATTACH_TTL=24h
ENTRYPOINT ["/usr/local/bin/openab-pty-entrypoint"]