mirror of
https://github.com/bytedance/deer-flow.git
synced 2026-07-21 10:15:47 +00:00
f3e4e5f8f09773cd2364c971ddf5034675dd1494
4
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 Zheng FengandGitHub
|
f3e4e5f8f0 |
ci(helm): publish chart to charts/ namespace prefix on GHCR (#4175)
* ci(helm): publish chart to charts/ namespace prefix on GHCR
Push the Helm chart to ghcr.io/<owner>/charts/deer-flow (via a `charts/`
prefix on the `helm push` target) instead of the bare `deer-flow`
package. This namespaces the chart apart from the image packages
(deer-flow-{backend,frontend,provisioner}) without renaming the chart:
Chart.yaml `name` stays `deer-flow`, so dir = chart name = in-cluster
resource/selector names, and no `nameOverride` hack is needed.
The chart is new in 2.1.0 (chart infra landed in #3987, after v2.0.0),
so 2.1.0 is the first chart release. Early nightly builds remain at the
legacy non-prefixed ghcr.io/<owner>/deer-flow.
Also refresh chart release docs:
- Replace the removed scripts/build-and-push.sh in the chart README with
raw `docker build`/`push` commands (contexts/args match container.yaml).
- Point NOTES.txt's empty-registry warning at the README section instead
of the removed script.
- Retarget RELEASING.md version examples from 2.2.0 to 2.1.0.
- Bump the chart README's helm prerequisite to 3+.
* docs(helm): require helm 3.8+ and note legacy chart package cleanup
Address PR #4175 review:
- bump documented minimum to helm 3.8 (OCI registry support stabilized
there; earlier 3.x needs HELM_EXPERIMENTAL_OCI=1)
- add a post-release note to delete/revoke the legacy bare
ghcr.io/<owner>/deer-flow chart package after 2.1.0
|
||
|
Zheng FengandGitHub
|
a9145e426c |
feat(frontend): show real project version on About page (#4126)
* feat(frontend): show real project version on About page The About page heading was hardcoded "About DeerFlow 2.0" while the real version is 2.1.0, kept in lockstep across backend/pyproject.toml, frontend/package.json, and Chart.yaml by scripts/verify_versions.sh. With the nightly workflow shipping unreleased main daily, a hardcoded version drifts further from reality every day. Wire the heading to the real version, nightly-aware: - src/version.ts reads NEXT_PUBLIC_APP_VERSION (nightly override) with a package.json fallback for release/local builds. - about-content.ts interpolates APP_VERSION into the heading; the "DeerFlow 1.0 and 2.0" milestone copy in acknowledgments is left as-is. - Dockerfile adds ARG APP_VERSION / ENV NEXT_PUBLIC_APP_VERSION in the builder stage so nightly CI can stamp the version. - nightly.yaml computes the nightly string once in prepare (<base>-nightly.<date>-<sha>, mirroring the chart scheme) and feeds it to both the frontend image build-arg and the chart publish (refactored to consume the shared output, so the displayed version and chart version can't drift). Release builds (container.yaml) are untouched and fall back to package.json. Tests cover the version branches and the heading interpolation; RELEASING.md notes the About page as a derived version consumer. * test(frontend): assert positive About-page version value Address review feedback on #4126: the unset-env assertion was negative-only (checked the stale "2.0" literal was gone), so it would still pass if APP_VERSION interpolated to "" or undefined. Mirror version.test.ts by asserting the heading carries the real resolved APP_VERSION. * ci(nightly): fail loudly on empty base version Address review feedback on #4126: the prepare step's BASE (parsed from Chart.yaml) had no empty-guard. A malformed/missing version would yield `-nightly.<date>-<sha>` (invalid semver) that now flows into both the chart publish and the frontend About-page version. Add `set -euo pipefail` plus a `test -n "$BASE"` guard mirroring publish-chart. `pipefail` matters - without it the pipeline's exit code is awk's, so `set -e` alone wouldn't catch a grep miss. |
||
|
Zheng FengandGitHub
|
7d1a8fb753 |
ci: add nightly build for images + helm chart (#4050)
* ci: add nightly build workflow for images + helm chart Nightly build of backend/frontend/provisioner images and the helm chart, pushed to GHCR with nightly + nightly-YYYYMMDD tags (latest stays on v* releases). amd64 only. Gated to the upstream repo (bytedance/deer-flow). Documented in RELEASING.md. * ci(nightly): harden chart patch + dedupe config_version check Address PR #4050 review feedback: - Gate the in-workflow chart patches with grep assertions so a drifted Chart.yaml/values.yaml fails loudly instead of silently shipping a chart that pulls the release `latest` images (sed exits 0 on zero matches). - Suffix the nightly chart version with the short SHA (<base>-nightly.<date>-<sha>) so a same-day re-dispatch re-publishes cleanly; OCI chart versions are immutable and otherwise collide. - Note in the image-tags comment that :nightly-<date> is mutable within a day and :sha-<short> is the only truly immutable pin. - Extract the config_version drift check into scripts/check_config_version.sh, shared by chart.yaml and nightly.yaml, so the parsing logic lives in one place. |
||
|
Zheng FengandGitHub
|
bc9ee9645c |
feat(deploy): first-class Helm chart for Kubernetes deployment (#3987)
* feat(helm): add production-ready Helm chart for Kubernetes deployment Adds deploy/helm/deer-flow, a native-Kubernetes translation of the production docker-compose stack, plus CI to publish its images and chart. * ci(release): gate releases on version-source consistency Add a reusable verify-versions workflow invoked by both chart.yaml and container.yaml on v* tags. It runs scripts/verify_versions.sh against the tag and fails the release — skipping all image and chart publishing — when Chart.yaml (version + appVersion), backend/pyproject.toml, or frontend/package.json don't all match the tag. Add scripts/verify_versions.sh (the check, also runnable locally) and scripts/bump_version.sh (bumps all four sources in lockstep, then self-verifies). Document the release flow in RELEASING.md and link it from AGENTS.md. * fix(deploy): address Helm chart review feedback (#3987) Three review items from willem-bd: 1. nginx IPv6 listen strip never matched. The sed pattern required a `;` immediately after `2026`, but the rendered config emits `listen [::]:2026 default_server;` (space + `default_server` before the `;`), so the line was never deleted and nginx crash-looped on pods without IPv6 (`socket() :::2026 failed (97: Address family not supported)`). Drop the trailing `;` from the pattern so it matches. Same latent bug fixed in docker-compose-dev.yaml. 2. Passwords were spliced into DSNs verbatim, so a password containing URL-special chars (@ : / # ? % [ ] space) produced a malformed DSN and a confusing parse error. Add a `deer-flow.urlEscape` helper (replace-based: Sprig lacks urlqueryescape, and regexReplaceAllLiteral treats the replacement as a regex template so `[`/`]`/`?` break it) and apply it to the password in the postgres and redis DSNs. The raw `postgres-password` / `redis-password` keys stay unencoded - they back POSTGRES_PASSWORD / REDIS_PASSWORD, not a URL segment. 3. NODE_HOST defaulted to "gateway", which can never route: the gateway Service is ClusterIP:8001 and knows nothing of a sandbox NodePort, so a user who skips the caveat gets unreachable sandboxes with no error at install time. Default NODE_HOST to the provisioner pod's node IP via the downward API (status.hostIP) - a NodePort is exposed on every node, so <node-IP>:<NodePort> routes from the gateway on most clusters. `provisioner.nodeHost` remains an override for CNIs/policies that block pod->node-IP traffic. Updated NOTES.txt, values.yaml, and the chart README. (#3929 remains the long-term fix - ClusterIP + cluster-DNS URL removes NODE_HOST and the NodePort exposure entirely.) Validated with helm lint, helm template (incl. a special-char password rendering the encoded DSNs), and a sed pattern-match check. * fix(deploy): address round-2 Helm chart review feedback (#3987) Three "Medium" items from willem-bd: 1. No helm lint / helm template gate before publish. A template regression ships as an immutable OCI artifact (GHCR won't overwrite --version), so gate packaging on `helm lint` + `helm template --include-crds` in chart.yaml before `helm package`. (ct lint / helm-unittest deferred.) 2. Action pinning inconsistent + PR body overstates it. SHA-pin actions/checkout (v6.0.3, df4cb1c0) and actions/attest-build-provenance (v2.4.0, e8998f94) across the publishing workflows (chart.yaml, container.yaml, verify-versions.yml), matching the existing docker/* SHA-pin pattern. Resolves the checkout @v4/@v6 mismatch and makes the "SHA-pinned actions" claim accurate. Other pre-existing workflows left untouched (out of scope for this PR). 3. Provisioner RBAC broader than needed. Dropped the unused update/patch verbs and the pods/exec + events rules from the provisioner Role - audited against docker/provisioner/app.py, which only calls get/create/delete on pods and get/list/create/delete on services. Fixed NOTES.txt to accurately describe the grant instead of understating it as "create Pods and Services". The remaining scope concern - verbs apply to all Pods in the namespace, not just sandbox Pods - is still deferred (RBAC can't scope by label; needs a dedicated namespace or admission control), now noted in NOTES.txt and README. Validated with helm lint + helm template (narrowed Role renders with exactly get/list/watch/create/delete). * feat(helm): enable sandbox+web tools out of the box The chart's default config loaded zero agent tools (config.tools empty -> "Total tools loaded: 0"), so a fresh install gave an agent that could do nothing useful. Add tool_groups + tools to the default config block: - web: web_search (ddg), web_fetch (jina), image_search - no API key - file:read: ls, read_file, glob, grep - file:write: write_file, str_replace - bash The file/bash tools run inside the AIO sandbox the chart already configures; the web tools need outbound internet from the gateway pod (swap backends or drop entries for air-gapped clusters - see config.example.yaml). Also bump config_version 15 -> 19 to match config.example.yaml (the chart had drifted behind). NOTES.txt and the README example updated to match. * ci(helm): add chart validation + config_version drift check on PR Extend the chart workflow with a PR-triggered validate-chart job that runs helm lint, helm template --include-crds, and a config_version drift check: it parses config_version from both config.example.yaml and the chart's values.yaml and fails the build (with a ::error:: naming the files to bump) if the chart is behind the example. This catches the kind of drift this PR is fixing - the chart sat at v15 while the example moved to v19 - before it can merge again. verify-versions and publish-chart stay tag-only; publish-chart now needs: [verify-versions, validate-chart]. validate-chart runs on both PRs and tag pushes: the tag arm is required because a job that `needs` a skipped job is itself skipped under the default success() check, so validate-chart must actually run on tag pushes or publish-chart would never fire. * Bump config version to 20 |