Re-take the vp installer checksum, which rotated under an unchanged VP_VERSION - #260
Merged
wormeyman merged 2 commits intoAug 25, 2026
Merged
Conversation
…P_VERSION Every job on every branch has failed at `Set up Vite+` since 2026-08-25 with `sha256sum: WARNING: 1 computed checksum did NOT match`. Nothing in the repo changed. The bootstrap script at https://vite.plus is versioned independently of the toolchain and it rotated on its own, so the pinned hash stopped matching while VP_VERSION stayed at 0.2.9. That is the pin doing its job: it failed the step rather than running a script nobody had read. So the fix is to read the script, then re-take the hash - 58bb052c... -> 3dd88ced..., verified against a fresh fetch. What the new script is: the same 1521-line Vite+ installer. It reaches registry.npmjs.org for the pinned VP_VERSION, and registry-bridge.viteplus.dev only when VP_PR_VERSION is set, which CI never sets. No eval, and nothing fetched is piped into a shell. The comment above the pin only described a version bump moving the hash. It now describes both directions, since the one that just happened leaves a red `Set up Vite+` on branches that did nothing wrong. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_016RKueZ4oW4T9UnnAmdJZsD
2 tasks
vite-plus 0.3.0 moves a default install to XDG paths - measured, with VP_VERSION=0.3.0 and no VP_HOME a sandboxed-HOME install reports `Bin directory: ~/.local/share/vite-plus/bin`. This action hardcodes ~/.vite-plus in two places, the PATH entry and the cache `path:`, so both would be wrong and every job would fail with `vp: command not found`. Three things make that certain rather than a risk. The installer's own compatibility shim only fires for GITHUB_ACTION_REPOSITORY = voidzero-dev/setup-vp, and this is a hand-rolled composite action. What protects us today is only that a 0.2.9 payload cannot answer VP_DUMP_DIRS, so the installer falls back to the legacy layout - a 0.3.0 payload can answer and will not fall back. And the vite-plus cache key carries the version with no restore-keys, so a bump is a guaranteed cache miss with no existing install to reuse. VP_HOME="$HOME/.vite-plus" is a no-op at 0.2.9, since that is already where the installer puts things, and verified to pin the monolithic layout at 0.3.0 with no XDG directories created. It goes in now rather than with the version bump because Renovate has 0.3.0 awaiting schedule and its two customManagers move VP_VERSION and the cache key together, without this line. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_016RKueZ4oW4T9UnnAmdJZsD
wormeyman
added a commit
that referenced
this pull request
Aug 25, 2026
…pins Three corrections, each measured rather than read off the file. The documented local-install command did not set the version at all. It read `VP_VERSION=0.2.8 VP_NODE_MANAGER=yes curl -fsSL https://vite.plus | bash`, and an assignment ahead of a command applies to that command alone - `curl` got the variables and the `bash` on the far side of the pipe read an empty string. Measured against a stub script, which printed `VP_VERSION=[]`. The installer then falls back to `VP_VERSION="${VP_VERSION:-latest}"`, read off the script itself, so anyone following that line installed `latest` rather than the pin. That is the "green, and wrong" split the same file warns about one section down, with a local toolchain silently different from the lockfile's and CI's. The command now downloads the script and runs it with the variables ahead of `bash`, matching setup-vp/action.yml, and sets VP_HOME for the layout reason #260 established. Syntax-checked with `fish -n`, since it is a fish block. The pin is 0.2.9 everywhere in the repo - root, editor and website package.json, the root overrides alias, and VP_VERSION in setup-vp/action.yml - while the file still said 0.2.8 in three places. It also claimed 0.2.8 was `latest` as of 2026-08-11; `npm view vite-plus dist-tags` gives 0.3.0 today. That entry has now gone stale twice, which is its own best argument, so it says so and points at the command to re-measure with. And the installer-checksum note said the hash did not move across 0.2.6 -> 0.2.8, so a bump usually leaves it alone. True when written, and it is the reassurance that made 2026-08-24 expensive: the script rotated with VP_VERSION untouched and every job on every branch failed at `Set up Vite+`. The note now records that a hash can move with no bump at all. Re-fetched today and the current sha256 still matches the pin, so nothing in CI needs changing. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018N3pm7fQQDv6HTVz1TEpmE
wormeyman
added a commit
that referenced
this pull request
Aug 25, 2026
… notes (#263) * Skip the Claude review workflow on pull requests from forks GitHub withholds repository secrets from a `pull_request` event raised by a fork, so `secrets.CLAUDE_CODE_OAUTH_TOKEN` resolves to an empty string and the action fails every time. Measured across the open backlog: `claude-review` failed on all five fork PRs (#227, #242, #243, #258, and #249 before it merged) and passed on both in-repo ones (#257, #260). That is the whole pattern - it is not a misconfiguration the workflow can fix, it is what the event is for. The failure blocks nothing, which is the problem. Every fork PR opens with a red X, and a check that is always red is a check nobody reads - so a real failure in it would be missed. A job-level `if` turns it grey instead. The alternative is `pull_request_target`, which does get fork PRs reviewed but hands base-repo secrets to a fork's code. Every outside contribution here arrives from a fork, so that trade is not available. The comment at the guard says so, since the next person to notice the skipped runs will reach for it. In-repo branches, Renovate's included, still run. Also corrects a stale note in CLAUDE.md: the `ajv` entry still described `ModdedBlueprintError` and `TrainBlueprintError` as declared-but-never-thrown, and #262 deleted both. The point it was making survives - ajv is ~100 kB and nothing branches on its result - so the entry keeps that and records what went. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018N3pm7fQQDv6HTVz1TEpmE * Correct CLAUDE.md's vite-plus entries against what the repo actually pins Three corrections, each measured rather than read off the file. The documented local-install command did not set the version at all. It read `VP_VERSION=0.2.8 VP_NODE_MANAGER=yes curl -fsSL https://vite.plus | bash`, and an assignment ahead of a command applies to that command alone - `curl` got the variables and the `bash` on the far side of the pipe read an empty string. Measured against a stub script, which printed `VP_VERSION=[]`. The installer then falls back to `VP_VERSION="${VP_VERSION:-latest}"`, read off the script itself, so anyone following that line installed `latest` rather than the pin. That is the "green, and wrong" split the same file warns about one section down, with a local toolchain silently different from the lockfile's and CI's. The command now downloads the script and runs it with the variables ahead of `bash`, matching setup-vp/action.yml, and sets VP_HOME for the layout reason #260 established. Syntax-checked with `fish -n`, since it is a fish block. The pin is 0.2.9 everywhere in the repo - root, editor and website package.json, the root overrides alias, and VP_VERSION in setup-vp/action.yml - while the file still said 0.2.8 in three places. It also claimed 0.2.8 was `latest` as of 2026-08-11; `npm view vite-plus dist-tags` gives 0.3.0 today. That entry has now gone stale twice, which is its own best argument, so it says so and points at the command to re-measure with. And the installer-checksum note said the hash did not move across 0.2.6 -> 0.2.8, so a bump usually leaves it alone. True when written, and it is the reassurance that made 2026-08-24 expensive: the script rotated with VP_VERSION untouched and every job on every branch failed at `Set up Vite+`. The note now records that a hash can move with no bump at all. Re-fetched today and the current sha256 still matches the pin, so nothing in CI needs changing. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018N3pm7fQQDv6HTVz1TEpmE --------- Co-authored-by: Claude Opus 5 (1M context) <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
1 participant
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.
What is broken
Every job on every branch has failed at
Set up Vite+since 2026-08-25:Nothing in the repo changed.
.github/actions/setup-vp/action.ymlpins the bootstrap script athttps://vite.plus, and that script is versioned independently of the toolchain. vite-plus 0.3.0 shipped on 2026-08-24 and rewroteinstall.shfor a new directory layout, so the pinned hash stopped matching whileVP_VERSIONstayed at 0.2.9.That is the pin working, not breaking. It failed the step rather than running a script nobody had read.
Two changes
1. Re-take the hash.
58bb052c…->3dd88ced…, from a fresh fetch, verified withshasum -a 256 -c -.I read the script before re-hashing, since that is the whole point of pinning it. It is the same 1521-line Vite+ installer: the only network hosts are
registry.npmjs.org(the pinnedVP_VERSION, immutable on npm) andregistry-bridge.viteplus.dev, which is reachable only whenVP_PR_VERSIONis set - CI never sets it. Noeval, and nothing fetched is piped into a shell.2. Set
VP_HOME="$HOME/.vite-plus". This is a no-op today and a guard against the next bump.0.3.0 moves a default install to XDG paths. Measured, with
VP_VERSION=0.3.0and noVP_HOME, a sandboxed-HOMEinstall reports:This action hardcodes
~/.vite-plustwice - theGITHUB_PATHentry and the cachepath:- so both would be wrong and every job would fail withvp: command not found, which reads as a broken toolchain rather than a wrong path.Three things make that certain rather than a risk:
GITHUB_ACTION_REPOSITORY = voidzero-dev/setup-vp. This is a hand-rolled composite action, so it never fires for us. The release notes' "CI that installs throughsetup-vpkeeps the single-root layout automatically" does not cover this repo.VP_DUMP_DIRS, so the installer falls back to the legacy layout. A 0.3.0 payload can answer, so it will not fall back.restore-keys, so a version bump is a guaranteed cache miss with no existing install to reuse.It goes in now rather than with the version bump because Renovate has 0.3.0 awaiting schedule, and its two
customManagersmoveVP_VERSIONand the cache key together - without this line.Test plan
shasum -a 256 -c -verifies the new hash against a fresh fetchVP_HOMEverified to pin the monolithic layout at 0.3.0, with no XDG directories createdchecks, both Rust jobsvp check(239 files, 0 errors),vp test(180/180) and the full Playwright suite (212 passed) pass locallyVP_HOMEadded, confirming it is a no-op at 0.2.9🤖 Generated with Claude Code
https://claude.ai/code/session_016RKueZ4oW4T9UnnAmdJZsD