github/deer-flow
1
0
Fork 0
mirror of https://github.com/bytedance/deer-flow.git synced 2026-08-01 19:06:01 +00:00
Code Issues Packages Projects Releases Wiki Activity
deer-flow/docker/lark-cli-init
History
Ryker_Feng 1b5220e35e
ci(lark): publish lark-cli-init/broker images (#4558) 
* 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).
2026-07-29 15:24:17 +08:00
..
build-runtime.sh
feat: add Lark CLI integration (#3971)
2026-07-26 08:09:17 +08:00
Dockerfile
feat: add Lark CLI integration (#3971)
2026-07-26 08:09:17 +08:00
entrypoint.sh
feat: add Lark CLI integration (#3971)
2026-07-26 08:09:17 +08:00
README.md
ci(lark): publish lark-cli-init/broker images (#4558)
2026-07-29 15:24:17 +08:00

README.md

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.

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

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).