CI ran Node 18 (out of support since 2025-04) while ops/host/subquery-deploy
runs subql codegen/build on the host's Node 20. serialize-javascript 7, which
the build now resolves, needs the global crypto that Node 18 does not have:
the build failed in CI and would have passed on the host.
deploy-vps reached subquery1 as root, through appleboy/ssh-action referenced
by tag, with a key whose comment (mamostehp@MamostePC) made it look like a
person's. It now uses plain ssh with SUBQUERY_DEPLOY_KEY, which the host pins
(authorized_keys restrict,command=) to ops/host/subquery-deploy-ssh: the
commit SHA is its only input. subquery-deploy, run through sudo, does what
the workflow's script did, with three changes:
- It deploys exactly the SHA CI was triggered for, and only a commit on main.
- The host's local edits to tracked files (the indexer manifests) are put
back whether the deploy succeeds or fails. Before, a failed build exited
before `stash pop` and left them stashed.
- Only tracked files are stashed. Stashing untracked ones too (.yarn/, which
yarn install recreates) made every pop fail half-way; that is how 13 stash
entries piled up on the host.
test-deploy.sh covers this against a scratch clone (red with the restore
trap removed); CI runs it with shellcheck. subquery1's host key is pinned.
The indexer endpoints themselves are unchanged. Actions pinned to SHAs; the
secret scanner's own AGPL licence is allowed in dependency review.
- Add packageManager field to package.json for corepack
- Add .yarnrc.yml with node-modules linker
- Update all workflows to use corepack enable + yarn --immutable
- Remove yarn cache from actions/setup-node (incompatible with Yarn 4)
dependabot[bot]