governance: deploy builds once, rsyncs per surface#473
Merged
Conversation
deploy-surface splits into resolve -> build -> matrix rsync legs and gains surface=all; deploy-staging drops its six-call matrix for one all-surfaces call. A six-surface release now costs one build (and one baseline-gate run on production) instead of six. include-hidden-files on the dist artifact is load-bearing: .well-known/ and .htaccess must survive the artifact hop or the --delete rsync would remove them live. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0176ZYTwoV8V4So9SBTizc5X
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
2 participants
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.
Every
deploy-surfacerun built the entire site (prebuild download packaging + Astro build, plus the full baseline gates on production) and then rsynced a single surface folder out of it. So today's six-surface release ran six complete builds and six full test-suite runs of the identical commit, and every push to main has been building the site six times for staging.Restructure — build once, deploy N:
deploy-surface.yml→ three jobs:resolve(surface input → JSON list, newalloption),build(one install/build —npm testgates on production,DEPLOY_ENV=stagingbuild on staging — uploadingdist/as a 1-day artifact),deploy(per-surface matrix, fail-fast off: download artifact + the exact same target-resolution and two-rsync steps as before, unchanged byte-for-byte in their guards and--delete/no---deletesemantics).deploy-staging.yml→ one call withsurface: allinstead of a six-call matrix. Per-surface independence is preserved inside the matrix legs — a single failed leg re-runs via "re-run failed jobs" without rebuilding, which is new (previously a re-run rebuilt).deploy-production.yml— untouched; its single-surface call works as before, now shaped as one build + one rsync leg.surface=all, so a full release is one click instead of six.Load-bearing detail:
include-hidden-files: trueon the artifact upload.dist/carries.well-known/security.txtand the apex.htaccess; upload-artifact ≥4.4 strips hidden files by default, and losing them in the artifact hop would make the--deletersync remove them from the live document roots.Cost math: a six-surface release drops from 6×(install+build+full gates) to 1×; a staging deploy from 6 builds to 1. Bonus correctness: all surfaces in one deploy now ship from literally the same build, so a registry package publishing mid-release can no longer make surfaces diverge.
Verification: YAML parses; rsync/target logic is unchanged from the proven version. The workflow itself can only prove out on its first real run — the next merge to main exercises the staging path end-to-end. Suggest merging this when you can watch that run.
🤖 Generated with Claude Code
https://claude.ai/code/session_0176ZYTwoV8V4So9SBTizc5X
Generated by Claude Code