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.
@pezkuwi/rpc-provider lists @bizinikiwi/connect as an optional dependency,
so npm installed it, with smoldot, into both images. Both are GPL-3.0, and
the bots never load them: they reach the chains over WsProvider. The images
now install with --omit=optional; with that install both bots load and read
the relay, Asset Hub and People chains.
The lockfiles still list the packages, so Dependency Review, which denies
GPL-3.0, flagged them on the new payout-bot lockfile (the noter's had them
before). It allows exactly those three packages, and the bots job fails if
an image contains @bizinikiwi or smoldot, so the allowance cannot outlive
the reason for it.
Both images ran `npm install` with version ranges and ignored any lockfile,
so what production ran depended on the day the image was built. The live
containers, built on 2026-10-03, run @pezkuwi/wasm-crypto 7.5.17, whose
ed25519, ecdsa and mnemonic generation are stubs that throw. Both bots sign
with sr25519 only, which is why they kept working.
Each bot now has a package.json and package-lock.json (@pezkuwi/api 16.5.37,
keyring, util and util-crypto 14.0.26, wasm-crypto 7.5.20) and its image
installs exactly that with `npm ci`. Node 20 is past its end of life; the
images move to node:24-alpine.
CI gains a `bots` job that builds each image and runs inside it:
scripts/bot-smoke.mjs checks the installed versions against the lockfile and
signs and verifies with sr25519, ed25519 and ecdsa, and the bot itself must
load and stop at the mnemonic it is not given. Against the previous lockfile
the smoke check fails on mnemonic generation, ed25519 and ecdsa.
- 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)
Satoshi Qazi Muhammed