mirror of
https://github.com/bytedance/deer-flow.git
synced 2026-08-01 19:06:01 +00:00
1b5220e35e
* ci(lark): publish lark-cli-init/broker images (#4532) Add .github/workflows/lark-cli-images.yaml to build and push the two optional Lark sandbox runtime images (Pattern A init container and Pattern B broker sidecar) to GHCR. These track the upstream larksuite/cli version, not the DeerFlow v* release, so the workflow is decoupled from container.yaml / the verify-versions gate: - Trigger via workflow_dispatch (lark_cli_version input) or a lark-cli-v* tag (version read from after the prefix). - Multi-arch linux/amd64,linux/arm64 (the images stage a real arch-dispatched lark-cli binary), via QEMU + Buildx. - Per-component build context: lark-cli-init builds from its own dir (relative COPY), lark-cli-broker from the repo root (it copies the shared build-runtime.sh + the harness lark_broker.py). - Tagged by lark-cli version; no latest; gated on the upstream repo. Docs: document the independent publishing in RELEASING.md and both image READMEs, replacing the "publishing is a fast-follow" notes. Closes #4532 * fix(ci): scope broker build context past root .dockerignore The repo-root .dockerignore excludes the whole `docker/` tree, but the lark-cli-broker image builds from a repo-root context and must COPY `docker/lark-cli-init/build-runtime.sh` and `docker/lark-cli-broker/entrypoint.sh` (plus the harness lark_broker.py). Under root .dockerignore those COPYs fail (excluded from context). Add docker/lark-cli-broker/Dockerfile.dockerignore: BuildKit uses this per-Dockerfile ignore-file instead of the root one for `-f docker/lark-cli-broker/Dockerfile` builds, keeping `docker/` and `backend/` in context while still dropping .git/venv/frontend/docs noise. lark-cli-init is unaffected (it builds from its own dir context). * fix(ci): harden lark-cli version input against shell injection Address PR #4558 review: pass the workflow_dispatch input through an env var instead of interpolating ${{ inputs.lark_cli_version }} directly into the run: script, so a dispatched value can't be expression-injected into the runner shell if the repo gate ever widens. Also fix the multi-arch comment verb (stage -> ships).
70 lines
3.0 KiB
Markdown
70 lines
3.0 KiB
Markdown
# lark-cli init image (Pattern A)
|
|
|
|
This image provisions the sandbox `lark-cli` runtime binary into a Kubernetes
|
|
sandbox Pod via an **init container + shared `emptyDir`**, instead of the Gateway
|
|
downloading Linux binaries from GitHub at install time and mounting them via
|
|
hostPath/PVC.
|
|
|
|
See the design at
|
|
[`docs/superpowers/specs/2026-07-21-lark-sandbox-init-container-design.md`](../../docs/superpowers/specs/2026-07-21-lark-sandbox-init-container-design.md).
|
|
|
|
## What it does
|
|
|
|
- **Build time** (network available): downloads and SHA-256-verifies the official
|
|
`larksuite/cli` Linux release binaries and stages the runtime layout under
|
|
`/opt/lark-cli`:
|
|
|
|
```
|
|
/opt/lark-cli/bin/lark-cli # arch-dispatch launcher (uname -m)
|
|
/opt/lark-cli/linux-amd64/lark-cli
|
|
/opt/lark-cli/linux-arm64/lark-cli
|
|
/opt/lark-cli/.deerflow-lark-cli-runtime.json # {"version": "vX.Y.Z"}
|
|
```
|
|
|
|
This is byte-identical to what the Gateway writer
|
|
(`_write_lark_cli_sandbox_launcher`) produces and what
|
|
`_validate_lark_cli_sandbox_runtime` enforces, so the sandbox PATH contract
|
|
(`/mnt/integrations/lark-cli/runtime/bin/lark-cli`) is unchanged.
|
|
|
|
- **Run time**: copies `/opt/lark-cli/.` into the emptyDir mounted at
|
|
`${LARK_CLI_RUNTIME_DEST}` (default `/mnt/integrations/lark-cli/runtime`) and
|
|
exits `0`.
|
|
|
|
## Build
|
|
|
|
```bash
|
|
docker build -t deer-flow/lark-cli-init:v1.0.65 \
|
|
--build-arg LARK_CLI_VERSION=v1.0.65 \
|
|
docker/lark-cli-init
|
|
```
|
|
|
|
The tag should encode the lark-cli version so it can be bumped independently of
|
|
the upstream `all-in-one-sandbox` sandbox image.
|
|
|
|
CI publishes multi-arch (`linux/amd64,linux/arm64`) images to
|
|
`ghcr.io/<owner>/deer-flow-lark-cli-init:<lark-cli-version>` via
|
|
`.github/workflows/lark-cli-images.yaml` (run it with a `lark_cli_version` input,
|
|
or push a `lark-cli-v*` tag). This is decoupled from the DeerFlow `v*` release
|
|
because the image tracks the upstream `larksuite/cli` version.
|
|
|
|
## Wiring it into the provisioner
|
|
|
|
The init-container runtime path is **opt-in** and off by default. Enable it by
|
|
publishing this image and pointing the provisioner at it:
|
|
|
|
- Set `LARK_CLI_INIT_IMAGE` on the provisioner service to the published tag
|
|
(e.g. `deer-flow/lark-cli-init:v1.0.65`). Empty ⇒ legacy hostPath / Gateway
|
|
download path (no behavior change).
|
|
- When set, the provisioner adds a `lark-cli-runtime` `emptyDir` volume, an
|
|
`lark-cli-init` init container, and a read-only runtime mount on the sandbox
|
|
container — and ignores any `/mnt/integrations/lark-cli/runtime` hostPath/PVC
|
|
extra mount (the init container supersedes it). The per-user `config` / `data`
|
|
credential mounts are unchanged.
|
|
- The provisioner reports whether it is configured via `GET /api/capabilities`
|
|
(`{"lark_cli_init_image": true|false}`), which the Gateway surfaces as the
|
|
Lark integration sandbox-runtime readiness signal in `/api/integrations/lark/status`.
|
|
|
|
> Opt-in note: the init-container path stays off until `LARK_CLI_INIT_IMAGE` is
|
|
> set on the provisioner, so an unpublished or unconfigured image is a no-op
|
|
> (legacy hostPath / Gateway download path, no behavior change).
|