The previous deploy (staff-tags 1.0.5) failed CI at this exact step with a
raw "Failed to parse JSON" error, even though the deploy itself had
succeeded seconds earlier (confirmed live) - Cloudflare's edge needs a
moment to propagate a fresh deploy, and the script had no res.ok check to
turn a transient non-OK response into a clear message, let alone retry it.
- Commit bun.lock (removes bun.lock/bun.lockb/package-lock.json/deno.lock
from .gitignore) so CI reads a pinned revision of the git-dependency
@revenge-mod/plugin-cli, which build.gradle.kts already declared as a
buildJs input but never had a committed file to read.
- Pin wrangler as a devDependency (4.120.0, matching the version already
live) so `bunx wrangler deploy` resolves the local pinned install instead
of "latest" at every run; verified empirically that bunx follows the
local pin, not the cache/latest version.
- Pin bun-version in oven-sh/setup-bun@v2 to 1.3.14, the version already in
use, so CI's toolchain isn't a moving target either.
- Add a post-deploy CI step (.github/scripts/verify-deploy.mjs) that fetches
the live index.json, and downloads and sha256-verifies one artifact against
the hash the index claims for it, failing the workflow on any mismatch.
This promotes the manual verification done during implementation into a
permanent regression check.
- Add concurrency (cancel superseded deploys on rapid pushes),
workflow_dispatch (manual redeploy without an empty commit), and an
explicit permissions: contents: read block to deploy.yml.
- Document in README.md that next.jarviscli.dev auto-deploys on every push
to main, and that a plugin change without a manifest.json version bump
silently republishes the same version pointer with different bytes,
so already-installed clients never see the update.
