Repository navigation
ci(relay): deploy only when the relay or its dependencies change - #652
Merged
Merged
Conversation
Adds the changed-since-last-deploy check that the web and mobile deploys already use, so commits that don't touch the relay, its workspace packages, or the lockfile no longer redeploy both relay stages. A manual run on main redeploys after a variable or secret change.
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.
deploy-relay.ymldeployed both the production and development relay on every push tomain, including commits like #650 that only touch the fork ledger. Each run installs dependencies and runs Alchemy against production with the production secrets, and all runs share one concurrency group, so a backlog of unrelated merges queues behind any slow or stuck deploy.The workflow now starts with the same
changed-since-last-deploycheck thatdeploy-web.ymlandmobile-eas-production.ymluse. Both relay stages deploy only when something changed since the last successful relay deploy under:infra/relaypackages/client-runtime,packages/contracts,packages/sharedpatches, the rootpackage.json,pnpm-lock.yaml,pnpm-workspace.yamlBecause the check compares against the last successful deploy rather than a single push, changes from a failed, cancelled, or replaced run still deploy on the next run.
Before this change, a variable or secret change was picked up by the next unrelated merge. That no longer happens, so the workflow gains
workflow_dispatchto redeploy by hand. Manual runs are limited tomain, as upstream's relay workflow does, so a run from another branch can't deploy that branch to production. The relay README and the two operations docs that said "every push tomain" are updated.Validation
I ran the same
git diff --quietpathspec check the action runs over the last 15 commits onmain. Two would deploy: #647 and #648, which both touchpackages/client-runtime. The other 13 skip, including #650. Comparing the relay's last successful deploy before today (c45862b737) with currentmainreportspackages/client-runtimechanges, which matches the infrastructure changes the deploy for7fa76362f8applied after the stuck run was cancelled.The workflow YAML parses. The new jobs haven't run on GitHub yet; the first push to
mainafter merge will exercise them, since the change to the workflow file itself counts as a relay change.Written by an agent (Claude Code, claude-opus-5-5).