grain.social/grain

Switch repository

Loading…

What changes

The pasted blocks are now knotless's shared steps. These come from knotless://chadtmiller.com/steps and are pinned in a new .knotless/uses.lock, written by knotless uses update:

• check.yml and test.yml: the packages step, which runs npm ci only when the lockfile hash changes, is now npm-ci. Its default dir, ., installs into ./node_modules, which both workflows already cache.
• publish-lexicons.yml: the plan and the publish are now publish-lexicons, given did and zone: grain.social. The zone matters because lexicons/ also holds copies of app.bsky, dev.hatk and other publishers' lexicons, and only the ones under grain.social are published. The "checks pass" loop is now wait-for-checks@2 with workflows: test check. deploy/publish-lexicons.mjs is deleted. The step's scripts/publish-lexicons.mjs is the same script made general, and nothing else used grain's copy.
• Ref gates are now on. The two [ "$KNOTLESS_RUN_REF" = refs/heads/main ] || exit 0 lines are now on: {refs: [refs/heads/main]} on the wait and publish steps. Asked for on another branch, the workflow still only plans. The two skipped steps show as skipped in the check instead of as passes that did nothing.
• The workflow's paths drops the deleted script. It adds its own file and .knotless/uses.lock, so a bump of the step (and with it the script) publishes again. LEX_DID and LEX_ZONE are no longer in env: they are now the step's inputs.

Left as they were:

• deploy.yml's checks loop. On a failure it also removes the candidate image, grain:build-<sha>, from the host. wait-for-checks only fails, and the steps after a failure don't run, so with the step the candidates would pile up on the host.
• deploy.yml's key step. Its secret is DEPLOY_SSH_KEY, but ssh-key asks for SSH_KEY, and a uses step can pass a secret only under the name the step file asks for. It can move once a step can take a secret under another name, or once the secret is renamed.
• mirror.yml's keys step. It writes two keys, GITHUB_DEPLOY_KEY and TANGLED_SSH_KEY, each with its own host and file, and pins both hosts' keys. ssh-key writes one key from SSH_KEY, so the names don't fit either.
• node isn't used anywhere. Every workflow's image already ships the Node it runs (node:25-slim, node:24.22.1), so no workflow installs Node itself.
• The tools steps in deploy.yml and mirror.yml. They install apk packages and knotless, and no step does that job.

Why

These blocks were copies of knotless's own, and knotless has moved its copies into shared steps. Using the steps keeps grain in step with fixes to them, through a lock bump that shows up as a diff.

How it was checked

• knotless uses update pinned the steps (CLI built from knotless main, 0.5.0 not yet released).
• On this pull, check and test exercise npm-ci on the hosted runner.

Shortcomings

• What this pull's run can't exercise. publish-lexicons runs on ci.knotless.dev only, and only on pushes to main or when asked. Its secrets reach main alone, and steps with on never run in a pull's run. So wait-for-checks and a write by publish-lexicons are first tried on main after this merges. This merge triggers that run, because the workflow's own file and the lock are now in its paths. With nothing changed it should report everything unchanged.

🤖 Generated with Claude Code

This pull moves the packages steps in check and test to the shared npm-ci step. It also moves the lexicon plan, wait and publish steps in publish-lexicons.yml to shared steps, and it deletes deploy/publish-lexicons.mjs.

The publish-lexicons check on this pull has status error: publish-lexicons.yml: steps[1]: unknown field 'on', expected one of name, run, uses, with, secrets, timeout at line 43 column 5. The runner doesn't accept a step-level on. The pull description says the CLI came from knotless main and 0.5.0 isn't released, so the runner may not support on yet. As written, the workflow doesn't load. If it merges, the lexicon publish stops working: the push to main would error instead of running, and the script it used to run is deleted. Don't merge until the runner accepts on, or until the ref gates are expressed in a form it does accept. Either way, run the workflow with rerun and show it loading.

The check and test runs were still queued when I looked, so I can't say whether npm-ci works on the hosted runner.