Files
zeekay d440fda72a release: platform-native build+publish via hanzo.yml (retire GHA)
ONE declarative flow for both lux release artifacts, on platform.hanzo.ai +
self-hosted arcd — NO GitHub Actions:

- hanzo.yml: node image build (matrix linux/{amd64,arm64}, native long-poll
  dispatch onto lux-build-* pools, tag-pattern {{git.branch}} -> :vX.Y.Z).
  Validated against the platform parsePlatformConfig.
- scripts/publish_plugin_set.sh: extracts the 12 baked VM plugins from the
  node image + SHA256SUMS, uploads to s3://lux-plugins-<env>/<pluginset>/
  (operator pluginSource), round-trip sha-verified. DRY — no second compile.
- RELEASE.md: the ONE canonical build+publish runbook; lists the .github
  workflows to retire (docker.yml, release.yml, build*.yml, ci.yml, ...).
- LLM.md: points at RELEASE.md as the canonical release path.

Proof (no GitHub): node:v1.30.40 provenance == 44b67b99a0 (reused, not
rebuilt); evm@v1.99.37 + dexvm@v1.5.15 rebuilt natively on the spark fleet
(go1.26.4, CGO=0) and the full 12-plugin set published to
s3://lux-plugins-staging/ (round-trip verified). neo's lux-plugins-devnet
prefix untouched.
2026-06-23 09:01:48 -07:00

40 lines
1.9 KiB
YAML

# Platform-native CI/CD — luxfi/node (the GitHub-Actions escape)
#
# Build is owned by platform.hanzo.ai (NOT GitHub Actions). On a tag push,
# platform reads this file, schedules ONE build job per matrix entry onto the
# self-hosted arcd long-poll fabric, and an arcd runner on the `lux-build-*`
# pool builds + pushes the image to GHCR. There is NO GitHub-Actions build hop:
# the legacy .github/workflows/docker.yml is retired (see RELEASE.md §retire).
#
# This ONE Dockerfile build produces BOTH lux release artifacts:
# 1. the node image -> ghcr.io/luxfi/node:<tag> (luxd + all 12 VM plugins
# baked at /luxd/build/plugins/)
# 2. the plugin SET -> s3://lux-plugins-<env>/<pluginset>/ (published in a
# second, decoupled step from the image's baked plugins — see
# scripts/publish_plugin_set.sh; consumed by the operator plugin-fetch
# init container via the LuxNetwork CR pluginSource).
#
# Schema reference: ~/work/hanzo/platform/docs/PLATFORM_CI.md.
# Release runbook (the ONE canonical way): ./RELEASE.md.
#
# Pool resolution: <org>-build-<os>-<arch>. org=luxfi -> brand=lux, so this
# repo's pools are `lux-build-linux-amd64` and `lux-build-linux-arm64`. These
# MUST match the live arcd scale-set names exactly.
#
# Tagging: a release is a `v*` git-tag push. The webhook decoder maps the tag
# ref to `branch=<tagname>`, so `tag-pattern: "{{git.branch}}"` yields the
# image tag `vX.Y.Z` (immutable, semver-only — no :latest, no floating tags).
build:
matrix:
- { os: linux, arch: amd64 }
- { os: linux, arch: arm64 }
dockerfile: ./Dockerfile
context: .
image: ghcr.io/luxfi/node
tag-pattern: "{{git.branch}}"
push: true
dispatch: native
# No `deploy:` block. luxd rollout is owned by the lux operator (LuxNetwork CR,
# ~/work/lux/operator) which the hanzo operator Service-CR rollout does not
# model. Deploy is a separate, operator-driven step (RELEASE.md §deploy).