ci(release): add Deploy backend workflow - #657
Merged
Merged
Conversation
|
✅ No security or compliance issues detected. Reviewed everything up to 280c239. Security Overview
Detected Code Changes
|
MRmarioruci
changed the title
MRmarioruci
force-pushed
the
release-3-deploy-be
branch
from
September 1, 2026 13:50
ca51ecc to
4b90f96
Compare
Contributor
There was a problem hiding this comment.
Pull request overview
Adds the backend half of the release deployment pipeline by introducing a manually-triggered workflow that deploys released backend WASM artifacts to playground first and (optionally) promotes the same selection to production behind a GitHub Environment approval gate.
Changes:
- Introduces a
Deploy backendworkflow_dispatchworkflow that runs playground then production (gated) deployments. - Adds a
deploy-backendcomposite action that installs required tooling, imports a deployment identity, downloads the latest released WASMs, and deploys via eitherorbit-cli registry publish(station/upgrader) ordfx canister install --mode upgrade(control-panel).
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.
| File | Description |
|---|---|
| .github/workflows/release-deploy-backend.yaml | New workflow to deploy selected backend components to playground and optionally promote to production with environment approval. |
| .github/actions/deploy-backend/action.yaml | New composite action encapsulating backend deployment logic (tooling setup, identity import, release artifact download, and deployment commands). |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
MRmarioruci
force-pushed
the
release-3-deploy-be
branch
from
September 1, 2026 14:49
b8f58fb to
de0f8e4
Compare
MRmarioruci
force-pushed
the
release-3-deploy-be
branch
2 times, most recently
from
September 2, 2026 10:27
ab9cecb to
32dfc90
Compare
aterga
approved these changes
Sep 3, 2026
MRmarioruci
force-pushed
the
release-3-deploy-be
branch
from
September 3, 2026 13:39
32dfc90 to
1f505fb
Compare
MRmarioruci
force-pushed
the
release-3-deploy-be
branch
4 times, most recently
from
September 4, 2026 08:04
69f3ebb to
a49ad45
Compare
Phase 3 (backend) of the release. A workflow_dispatch that publishes station/upgrader to the control-panel registry, or upgrades the control-panel canister in place, on playground then production behind the approval gate. Shared logic lives in a deploy-backend composite action.
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
Pin dfinity/setup-dfx (was @main, a moving branch with no tags) and actions/checkout to immutable commit SHAs, to make the privileged deploy workflow reproducible and reduce supply-chain exposure.
… checksum) Serialize deploy runs with a concurrency group, drop persisted git credentials on the download-only checkouts, and verify each downloaded wasm against its published .sha256 before publishing or upgrading.
… one path The backend deploy logic lived inside the composite action, so it could only ever run in CI. Move it into scripts/deploy-backend, matching scripts/deploy-app's shape (--pem or --op), and have the action call it once per target. Production keys can now stay off CI entirely. Two defects fall out of the move. orbit-cli resolves the identity pem from homedir() and ignores DFX_CONFIG_ROOT, so the isolated dfx root the action set up would have made registry publish fail to find the identity dfx had just imported; the script exports HOME alongside it. And the registry entry's version label comes from cargo metadata rather than the artifact, so a stale checkout would publish the right wasm under the wrong version; the script compares the two and refuses.
Same two fixes as the frontend workflow: the string comparison against a typed boolean input left the production job unreachable, and the signing key is now named per environment rather than shared.
…cated tag Same unanchored version pattern as the frontend script: a pre-release tag matched as its stable prefix and resolved to a tag that does not exist.
MRmarioruci
force-pushed
the
release-3-deploy-be
branch
from
September 4, 2026 09:49
a49ad45 to
280c239
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Phase 3 of 4. Stacked on #656.
Adds the
Deploy backendworkflow_dispatch, adeploy-backendcomposite action, andscripts/deploy-backend.You tick station, upgrader, or control-panel and run it. The workflow's two jobs each call the composite action, which installs the toolchain, materialises the key from the
BACKEND_IDENTITY_PEMenvironment secret, and then callsscripts/deploy-backendonce per target. All of the real work lives in the script, so CI and an operator on a laptop run the same code rather than two copies that drift. The script resolves the newest release tag, downloads the wasm, verifies it against the.sha256published beside it, loads the key into a throwaway dfx home, and dispatches: station and upgrader go throughorbit-cli registry publish, which only makes the version available (each production station still self-upgrades on its own admins' approval, and publishing station also publishes its upgrader dependency); control-panel is a directdfx canister install --mode upgradeof the one canister, so nothing buffers it.The
productionjob is off by default and has no key. Production backends are deployed withscripts/deploy-backend --op, which keeps that credential out of this repo. The job is kept so the wiring exists if that is revisited; with no key it fails fast with a pointer.Two defects surfaced while moving the logic out of the action, both fixed here.
orbit-cliresolves the identity pem fromhomedir()and ignoresDFX_CONFIG_ROOT, so the isolated dfx root the action set up would have leftregistry publishunable to find the identity dfx had just imported; the script exportsHOMEalongside it. And the registry entry's version label comes fromcargo metadatarather than from the artifact, so deploying from a stale checkout would publish the right wasm under the wrong version; the script compares the two and refuses, naming the tag to check out.The backend identity must be both a registry admin and a control-panel controller. Base of this PR is #656; review the stack in order.