feat: migrate subgraph provider from Ormi to Goldsky - #1037
Merged
Merged
Conversation
Deploy the testing Sepolia and Base Sepolia subgraphs on Goldsky instead of Ormi, and point the SDK at the Goldsky query endpoint for testing-11155111-0. Goldsky tags are mutable pointers keyed by tag name, so moving 'latest' onto a new version is a single idempotent write - no intermediate tag is needed. The new deploy-on-goldsky.ts script runs the whole sequence through the Goldsky CLI: read the version 'latest' currently points to (before deploying, as moving the tag is what makes that unrecoverable), deploy, optionally wait for the new version to be synced, move the tag, then delete the old version. That also makes the logs/ files obsolete, as Goldsky now records which version is deployed. Syncing can take hours, so waiting for it is opt-in via GOLDSKY_WAIT_FOR_SYNC: unset, the tag moves straight after the deployment; set, the tag move and the cleanup only happen once the new version is synced and healthy. The testing workflow deploys only those two networks for now, with the sync gate on, and no longer fails when a run has nothing to commit. Refs #1036 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Contributor
There was a problem hiding this comment.
Pull request overview
This PR introduces the first slice of the Ormi → Goldsky migration for subgraph deployments, scoped to the testing environment (Sepolia + Base Sepolia), including a new Goldsky-based deploy script and workflow wiring.
Changes:
- Add a Goldsky-driven deployment script that deploys, optionally waits for sync/health, moves the
latesttag, and deletes the previously-tagged version. - Update testing deploy workflow(s) to deploy only Sepolia and Base Sepolia via Goldsky and pass through the new Goldsky API key secret.
- Update the testing Sepolia subgraph query endpoint to Goldsky (but Base Sepolia endpoint is not updated in this PR).
Reviewed changes
Copilot reviewed 6 out of 7 changed files in this pull request and generated no comments.
Show a summary per file
| File | Description |
|---|---|
| packages/subgraph/subgraph.template.yaml | Minor manifest template list adjustment. |
| packages/subgraph/scripts/deploy-on-goldsky.ts | New Goldsky deploy/tag-move/cleanup script with optional sync gate. |
| packages/subgraph/package.json | Add Goldsky CLI dependency and new build:subgraph / deploy:goldsky scripts; switch testing sepolia/base deploy scripts to Goldsky path. |
| packages/common/src/inputs/subgraphs.json | Switch testing Sepolia endpoint to Goldsky (Base Sepolia remains on Ormi). |
| package-lock.json | Lockfile updates to include @goldskycom/cli. |
| .github/workflows/publish-alpha.yaml | Pass GOLDSKY_API_KEY_TESTING secret into reusable deploy workflow. |
| .github/workflows/deploy-testing-subgraph.yaml | Add required Goldsky secret, concurrency control, longer timeout, and switch deploy steps to Goldsky. |
Suppressed comments (2)
packages/common/src/inputs/subgraphs.json:16
- The PR description and deploy workflow indicate both Sepolia and Base Sepolia testing subgraphs are migrated to Goldsky, but only
testing-11155111-0was updated here;testing-84532-0still points at the Ormi/0xgraph endpoint. This will cause the app to keep querying Ormi for Base Sepolia even though the deploy job now deploys/tag-moves on Goldsky fortesting_base.
"https://api.goldsky.com/api/public/project_cmsd7juc4rocz01u5566b9h93/subgraphs/boson-testing-sepolia/latest/gn"
],
"testing-84532-0": [
"https://api.0xgraph.xyz/api/public/c56471f5-5b1d-4a62-b1de-450044cb7ebc/subgraphs/boson-testing-base/latest/gn"
],
.github/workflows/deploy-testing-subgraph.yaml:12
workflow_call.secretsstill marks Ormi / Graph Studio secrets asrequired: true, but this workflow no longer uses them after switching both steps to Goldsky. Keeping them required forces every caller to provide secrets that are unused, increasing operational coupling.
required: true
ORMI_0x_GRAPH_API_KEY_TESTING:
required: true
THE_GRAPH_STUDIO_DEPLOY_KEY:
required: true
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #1037 +/- ##
=======================================
Coverage 91.73% 91.73%
=======================================
Files 182 182
Lines 7766 7766
Branches 1514 1514
=======================================
Hits 7124 7124
Misses 642 642
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
This was referenced Aug 26, 2026
levalleux-ludo
added a commit
that referenced
this pull request
Aug 27, 2026
#1039) * ci: deploy each subgraph in its own parallel job Each deploy workflow ran every network sequentially in a single job. With GOLDSKY_WAIT_FOR_SYNC on, a network that indexes slowly ate into the next one's budget, and all of them had to fit inside GitHub's 6h job limit - so the per-network wait was capped at 150 minutes and a network that overran prevented the ones after it from deploying at all. Replace the sequence of deploy steps with a matrix over networks, so each one gets its own runner: they run in parallel, each has the full job budget (GOLDSKY_SYNC_TIMEOUT_MINUTES back up to 300 with timeout-minutes: 350), and fail-fast: false keeps one network's failure from cancelling the others. Carry the changes made for testing in #1037 over to staging and production: deploy:{staging:sepolia,staging:base,production:ethereum,production:base} now build the subgraph and run deploy-on-goldsky.ts, the workflows deploy only those networks, and they authenticate with GOLDSKY_API_KEY_{STAGING, PRODUCTION}. The remaining networks stay on Ormi and are no longer redeployed by CI, matching the migration scope in #1036. The 'Commit & Push' steps are dropped. Goldsky records which version is deployed, subgraph.yaml is gitignored and the logs/ files are no longer written, so these runs have nothing to commit - and parallel jobs pushing to main would race. That also makes the 'Set github bot' steps redundant. The subgraph query URLs in subgraphs.json are deliberately left alone for staging and production: the Goldsky projects for those environments do not exist yet, and the endpoints must only be switched once a version has been deployed and synced there. Refs #1036 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * ci: promote subgraphs from a schedule instead of waiting for the sync Waiting for a freshly deployed version to be indexed inside the deploy job does not hold: boson-testing-base took roughly 6 hours, the job hit its timeout, and the 'latest' tag stayed on the previous version even though the new one ended up indexed and healthy. The wait is now split off from the deployment: - the deploy job watches the new version for 5 minutes, long enough to catch a deployment that cannot index at all, then ends successfully and flags the deployed version in a SUBGRAPH_PENDING_<ENV>_<NETWORK> repository variable - a new 'Promote deployed subgraphs' schedule checks every flagged deployment every 30 minutes and, once it is synced and healthy, moves the 'latest' tag onto it and deletes the version the tag was pointing to Nothing holds a runner for hours any more, and no promotion can hit the 6 hour job limit. A network is flagged, checked and cleared on its own, so a subgraph that fails to index never affects the others. 'promote-on-goldsky.ts' makes a single check and reports 'promoted', 'pending' or 'failed' on its 'outcome' step output, which is what clears the flag. A transient failure - Goldsky unreachable, say - writes no outcome, so the deployment stays flagged and is retried on the next tick. The deploy and promote scripts share 'goldsky.ts', and the workflows share a 'setup-subgraph' composite action. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * ci: deploy the subgraph networks from a matrix again The per-network jobs were only spelled out one by one so that each network's promotion job could depend on its own deployment. The promotion is a schedule now, so nothing needs to name a single network's job any more and the three workflows go back to one matrixed job each. The network's pending-deployment variable rides along in the matrix rather than being derived, so the six names stay greppable against the ones the 'Promote deployed subgraphs' schedule reads. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix: reorder entities in subgraph template to generate a new hash Goldsky keys a deployment on the manifest hash, so a version whose manifest is byte for byte the one already deployed cannot be redeployed. Reordering the 'entities' lists changes the hash without changing what the manifest declares - graph-node does not read anything into their order. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix: address the review findings on the subgraph deploy and promote jobs Three ways the promotion could move or clear the wrong thing: - a 'Synced:' line the CLI prints in any form this does not recognise was read as fully indexed, which moves the 'latest' tag onto a version that is still indexing and deletes the one serving traffic. Only '100%' or an explicit check mark counts now, and anything else means "not synced yet". - clearing the flag deleted whatever the variable held. A deployment that landed while the promotion was running now keeps its flag instead of being dropped silently, never promoted and never reported. - a tag listing that failed passed for 'no previous version', which reported the promotion as done while leaving the old version undeleted. It throws, and the flag survives for the next tick. Nothing bounded a deployment that neither indexed nor failed - a paused indexer, or a missing GOLDSKY_API_KEY_<ENV> failing the script before it can report an outcome - so the schedule picked it up every 30 minutes forever. A deployment now has PROMOTION_DEADLINE_HOURS (24h) to promote, after which the watch is given up on with an error and the flag is cleared. Also: - the production workflow takes the setup action from the ref it is running from: its workspace holds the release being deployed, whose '.github' is whatever that release shipped - the action may not be in it at all - the testing workflow falls back to BSNORG_ACTIONS_SECRET when no GH_TOKEN is passed, and checks it up front rather than deploying a version it then cannot flag, and which nothing would ever promote - the deployed version reaches 'gh variable set' through the environment, and is validated the way the schedule validates it before use - a variable that does not hold a version annotates and skips that subgraph rather than stopping every other network's promotion - the schedule derives the env key and the variable name from the environment and the network instead of carrying them as literal columns - the promotion installs the subgraph workspace and the root, not all nine - the '--env' choices move to 'deploy-envs.ts', shared with the Ormi script - the setup action's 'build' input no longer explains itself with the ./build directory, which is not what it produces Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix: update subgraph URLs for testing, staging, and production environments --------- Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
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.
Part of #1036 — first slice of the Ormi → Goldsky migration, scoped to the testing environment on Sepolia and Base Sepolia. The other three testing networks, plus staging and production, stay on Ormi for now.
What changes
Query endpoint —
testing-11155111-0now points at the Goldsky endpoint insubgraphs.json. The URL is tag-based (.../subgraphs/boson-testing-sepolia/latest/gn), so it stays stable across deployments.Same change applied to
testing-84532-0New deploy script —
packages/subgraph/scripts/deploy-on-goldsky.tsreplaces thegraph deploy+post-deploy-on-ormi.tspair for these two networks. It drives the Goldsky CLI through the whole sequence:latesttag currently points to — before deploying, since moving the tag is what makes that unrecoverablelatesttag onto the new versionGoldsky tags are mutable pointers keyed by tag name, so step 4 is a single idempotent write — creating a tag that already exists just repoints it. No intermediate
new-latesttag is needed.post-deploy-on-ormi.tsis untouched, and thedeploy:cmd:testing:{sepolia,base}entries are left in place for rollback.The sync gate — syncing can take hours, so waiting for it is opt-in via
GOLDSKY_WAIT_FOR_SYNC:If the new version never gets there, the script exits non-zero with
lateststill on the old version and the old version still present.GOLDSKY_SYNC_TIMEOUT_MINUTES(default 300) andGOLDSKY_SYNC_POLL_SECONDS(default 60) tune the wait.Workflow —
deploy-testing-subgraph.yamlnow deploys only these two networks, with the gate on and the per-network timeout capped at 150 min so two sequential deploys fit inside GitHub's 6h job limit. Three supporting changes came with that:concurrencygroup, because a job that pushes to a branch and now runs for hours can otherwise overlap with itself and race on the same subgraph's tagstimeout-minutes: 330on the jobCommit & Pushstep no longer fails when there is nothing to commit.subgraph.yamlis gitignored, so thelogs/*files were the only thing this job ever committed — and Goldsky now records which version is deployed, making them obsoletepublish-alpha.yamlpasses the new secret through to the reusable workflow; arequired: truesecret has to be provided by the caller or the run errors before it starts.Action required before merge
Create a
GOLDSKY_API_KEY_TESTINGrepo/org secret. The workflow will fail withMissing environment variable 'GOLDSKY_API_KEY'without it. The name follows theORMI_0x_GRAPH_API_KEY_TESTINGconvention — rename in both workflow files if you'd prefer something else.Verification
npm run buildandnpm run lint:fixpass1.36.0and the status read returnshealthyfor bothboson-testing-sepoliaandboson-testing-baseprettier --checkclean,@action-validator/clischema-clean,actionlintreports only pre-existing findingsWorth knowing: Goldsky's
syncedflag is unreliable. Both live deployments are healthy and indexed to head but still reportSynced: 100%rather than the check mark, weeks after deployment. A gate keyed on the check mark alone would hang for the full timeout on every run, so the script treats a reported100%as synced (the CLI rounds to 3 significant digits, so that means ≥ 99.95%).Pre-existing, not addressed here
actionlintflagsactions/{checkout,setup-node,cache}@v3in this workflow as too old to run. The rest of the repo is already on v4 — the only three holdouts are the testing/staging/prod subgraph deploy workflows. Happy to bump them in a follow-up.Follow-ups
core-sdkversion once the endpoints are live🤖 Generated with Claude Code