Upgrade EdgeZero to the deploy-actions branch - #940
Conversation
Point the edgezero-* dependencies at the feature/edgezero-deploy-actions branch (PR #316) and adapt Trusted Server to its API changes: - Wire the new ts CLI subcommands surfaced by edgezero-cli: active-version, healthcheck, and rollback, plus deploy --stage and a --version flag, with argument-parsing coverage. - Migrate TrustedServerAppConfig to the AppConfigMeta::secret_fields() method that replaces the removed SECRET_FIELDS associated constant.
Status update — P0/P1 trackingHead: `96dd1f72` (main merged in twice since the original commit; edgezero dep unchanged, no conflicts). P0.2 — CI + output-line contract
P1.3 — edgezero library ↔ action lockstep (recorded pair)The `ts` CLI is built from this repo's `Cargo.toml` (edgezero library rev), and the deployer separately pins `stackpop/edgezero/.github/actions/deploy-fastly@` (edgezero action ref). These MUST be the same edgezero commit so library and action can't diverge.
P0.1 — re-pin off the moving branch (blocker, still open)edgezero #316 is not yet merged and no new tag exists. Cannot re-pin until it lands; PR stays draft until then. |
Re-resolve the six edgezero-* deps from 145f1699 to bb441162 (current tip of feature/edgezero-deploy-actions, PR #316). The deploy staging flag was renamed there from --stage to --staging, standardizing on the same verb healthcheck/rollback/config-push already use; update the deploy CLI parse test to match. No production dispatch change is needed — ts passes the edgezero-cli arg structs through, so the renamed flag is picked up automatically.
Re-resolve the six edgezero-* deps from bb441162 to 908e229a (current tip of feature/edgezero-deploy-actions, PR #316), and adapt the ts CLI to its surface changes: - Wire the new `ts config gc` subcommand (reclaims orphaned config-store chunk entries) to edgezero_cli::run_config_gc, with parse coverage for the preview default, destructive --yes/--older-than sweep, and the --dry-run/--yes conflict. - Lock the hardened deploy staging behavior: --stage was renamed to --staging and deploy passthrough is now last=true, so a stray --stage fails closed at parse time instead of routing a staging-intended deploy to production. Add tests for the rejection and for post---- passthrough capture.
…ain sync) with the #940 re-merge
Re-resolve the six edgezero-* deps from 908e229a to 5f3d648c (current tip of feature/edgezero-deploy-actions, PR #316). The upstream change is an internal review-addressing pass (redact config-store errors, fix version parse, log cleanup, docs) confined to the Fastly adapter CLI; no ts CLI surface change, so no run.rs adaptation is needed.
prk-Jr
left a comment
There was a problem hiding this comment.
Summary
Tight, well-tested upgrade: six edgezero deps repointed at the deploy-actions branch, SECRET_FIELDS migrated to secret_fields(), and the new active-version / healthcheck / rollback / config gc subcommands wired through with argument-parsing coverage for each. Dispatch is a clean passthrough and every new command has a doc comment. Two things block: the dependency reference is mutable while upstream #316 is still open, and the operator docs weren't updated for the new (partly destructive) surface.
Blocking
🔧 wrench
-
Mutable
branch =dep on an unmerged upstream PR (Cargo.toml:57-62): upstreamstackpop/edgezero#316is confirmedopen/merged: false, but this PR isisDraft: falseandMERGEABLE. See the inline comment for therevpin suggestion. -
docs/guide/cli.mdnot updated for the new CLI surface: four subcommands ship undocumented —active-version,healthcheck,rollback, andconfig gc.config gcis the one that matters most: with--yesand--older-thanit destructively sweeps config-store entries, and the only place its semantics are written down right now is a one-line clap doc string and three parse tests. The "Lifecycle commands" block (docs/guide/cli.md:79-90) and "Configuration commands" block (:43-77) both enumerate the available commands, so they read as complete and are now silently wrong.The same file also carries a version claim that this PR invalidates (
docs/guide/cli.md:67-70):EdgeZero v0.0.4 only overrides leaves already present in the TOML; add newly introduced fields to existing configs before relying on their overrides.
The dependency is no longer v0.0.4. Either confirm the behavior still holds on the new tree and drop the version qualifier, or update it to whatever gets pinned at merge time.
Non-blocking
🤔 thinking
- Unrelated dependency downgrades in the lock refresh (
Cargo.lock):windows-sys 0.61.2 → 0.48.0anditertools 0.13.0 → 0.10.5. Details and a scopedcargo updateinline.
🌱 seedling
ts --versioncan't identify the embedded edgezero (crates/trusted-server-cli/src/run.rs:16): follow-up, not this PR.
📝 note
secret_fields()port (crates/trusted-server-core/src/config.rs:115): mechanical and correct; the empty-set caveat above it is unchanged.
👍 praise
deploy_rejects_renamed_stage_flag_before_separator(crates/trusted-server-cli/src/run.rs:306): catches a silent staging→production routing hazard created by the upstream flag rename pluslast = truepassthrough.
CI Status
All 19 checks green on fe5767e — reported from GitHub, not re-run locally:
- fmt: PASS
- clippy (fastly / axum / cloudflare native + wasm / spin native + wasm): PASS
- rust tests (core, axum, cloudflare, spin, ts CLI, cross-adapter parity): PASS
- integration + browser integration + Fastly EC lifecycle: PASS
- js tests (vitest) / format-typescript / format-docs: PASS
- CodeQL (actions, javascript-typescript, rust): PASS
| edgezero-adapter-fastly = { git = "https://github.com/stackpop/edgezero", branch = "feature/edgezero-deploy-actions", default-features = false } | ||
| edgezero-adapter-spin = { git = "https://github.com/stackpop/edgezero", branch = "feature/edgezero-deploy-actions", default-features = false } | ||
| edgezero-cli = { git = "https://github.com/stackpop/edgezero", branch = "feature/edgezero-deploy-actions" } | ||
| edgezero-core = { git = "https://github.com/stackpop/edgezero", branch = "feature/edgezero-deploy-actions", default-features = false } |
There was a problem hiding this comment.
🔧 wrench — Six deps now point at a live branch of an unmerged upstream PR, and this PR is no longer a draft.
Verified against the upstream API: stackpop/edgezero#316 is state: open, merged: false. This PR reports isDraft: false and mergeable: MERGEABLE, so nothing mechanically prevents merging a branch = ref into main. Cargo.lock currently pins 5f3d648c, but that pin is only as durable as the lockfile — any cargo update, or a cargo install/fresh resolve that does not pass --locked, silently retargets whatever the branch tip is at that moment. A force-push or branch deletion upstream breaks the fetch outright.
The PR body already flags this, but the PR state doesn't match the caveat.
Fix — either flip back to draft until #316 merges and a tag is cut, or pin immutably in the meantime:
edgezero-core = { git = "https://github.com/stackpop/edgezero", rev = "5f3d648c3c6c38fc6e6b22b5c65c66177363aad8", default-features = false }A rev gives the same code as today's lock while making the reference immutable, so the repin-before-merge step becomes rev → tag rather than "remember not to merge this."
| checksum = "faf9468729b8cbcea668e36183cb69d317348c2e08e994829fb56ebfdfbaac34" | ||
| dependencies = [ | ||
| "windows-sys 0.61.2", | ||
| "windows-sys 0.48.0", |
There was a problem hiding this comment.
🤔 thinking — The lock refresh carries downgrades unrelated to the edgezero repin:
windows-sys0.61.2→0.48.0(2 sites)itertools0.13.0→0.10.5(3prost-*crates)
Neither is edgezero-adjacent. This pattern usually means the lockfile was re-resolved wholesale rather than repinned in place — possibly under a different toolchain or resolver setting. Both crates are host-build-only (Windows shims, protobuf codegen), so there is no wasm32-wasip1 runtime exposure and CI is green, but it widens the diff's blast radius beyond "upgrade EdgeZero" and makes the lock harder to audit.
Fix — scope the update to the intended crates and drop the incidental deltas:
cargo update -p edgezero-core -p edgezero-cli -p edgezero-adapter-fastly \
-p edgezero-adapter-axum -p edgezero-adapter-cloudflare -p edgezero-adapter-spinIf the downgrades turn out to be forced by the new edgezero tree (e.g. via edgezero-macros' move to syn 3), a note in the PR body would settle it.
| // references needs nested/array extraction support and operator migration | ||
| // work tracked separately. | ||
| const SECRET_FIELDS: &'static [edgezero_core::app_config::SecretField] = &[]; | ||
| fn secret_fields() -> Vec<edgezero_core::app_config::SecretField> { |
There was a problem hiding this comment.
📝 note — Straight port of the removed SECRET_FIELDS associated const to the new secret_fields() method; Vec::new() doesn't allocate, so the const → owned-Vec signature change costs nothing here.
Worth restating for anyone reading this later: the comment above still holds — the returned set is empty, so app-level secrets continue to live in plaintext inside the pushed config blob. Nothing in this PR changes that, and the upstream method signature doesn't unblock it either (the nested/array extraction gap is the actual blocker).
|
|
||
| #[derive(Debug, Parser)] | ||
| #[command(name = "ts", about = "Trusted Server CLI")] | ||
| #[command(name = "ts", version, about = "Trusted Server CLI")] |
There was a problem hiding this comment.
🌱 seedling — version here resolves to the workspace CARGO_PKG_VERSION, so ts --version prints ts 0.1.0.
That's a fine default, but now that deploy, rollback, healthcheck, and active-version all delegate to an edgezero pinned at a moving branch ref, the operational question during an incident is "which edgezero is baked into this binary?" — and the version string can't answer it. Not for this PR, but embedding the resolved edgezero rev (build script + long_version) would make rollback triage a lot cheaper.
| } | ||
|
|
||
| #[test] | ||
| fn deploy_rejects_renamed_stage_flag_before_separator() { |
There was a problem hiding this comment.
👍 praise — This test pins exactly the dangerous interaction: --stage was renamed to --staging upstream, and deploy passthrough is last = true, so without a parse-time rejection a stale --stage in someone's shell history or CI job would be swallowed as passthrough, leave staging false, and ship a staging-intended deploy to production.
The inline comment explains the failure mode rather than the mechanics, which is the right thing to leave behind. Same for deploy_captures_adapter_passthrough_after_separator covering the other half of the boundary, and the config gc trio covering the preview default, the destructive sweep, and the --dry-run/--yes conflict.
Summary
Upgrades the six edgezero workspace dependencies from
tag = "v0.0.4"to thefeature/edgezero-deploy-actionsbranch and adapts Trusted Server to its API changes.edgezero-adapter-{axum,cloudflare,fastly,spin},edgezero-cli, andedgezero-coreat the branch; refreshCargo.lock(rev145f1699).tsCLI subcommands surfaced byedgezero-cli—active-version,healthcheck,rollback— plusdeploy --stageand a top-level--versionflag, with argument-parsing coverage.TrustedServerAppConfigto theAppConfigMeta::secret_fields()method that replaces the removedSECRET_FIELDSassociated constant.Verification
All CI gates run locally against the branch and pass:
cargo fmt --all -- --check— cleancargo clippy— fastly, axum, cloudflare native + wasm, spin native + wasm — cleanparity— 13 passstackpop/edgezero#316 is not yet merged. The
branch =dependency ref is a moving target and can't merge as-is; before this lands, re-pin the six deps to a tagged release (orrev) once #316 merges.Out of scope
Adopting the new deploy GitHub Actions (
deploy-fastly/healthcheck-fastly/rollback-fastly) in this repo's workflows is separate, unstarted work.Closes #939