Conversation
The binary and the landing page ship on different schedules. Deploying a copy fix should not require cutting a vump release, which would tell everyone pinning the binary that something changed when nothing did. vump.toml now declares two projects, told apart by the shape of their tag: `main` tracks Cargo.toml and Cargo.lock and tags `v1.2.3`, `website` tracks website/package.json and tags `website-v1.2.3`. Each shape triggers one workflow, and `vump check` infers the project from the tag, so neither has to name --project. The shapes cannot collide: a website tag does not start with `v`. website/package.json gets its version back. It was dropped when the site had no release line, on the grounds that a number nobody maintains is exactly the kind of lie this repository exists to prevent — but vump now keeps it in step with the tag, which is what makes it true rather than decorative. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The masthead used to fetch the newest release from the GitHub API on every page load. Unauthenticated, that is sixty requests an hour per address, so the version would simply vanish for anyone behind a busy NAT — and a landing page that says different things to different people at different moments is not one anybody can quote. It is a declared input now: src/content/release.json, read at build time. Reading Cargo.toml instead is the obvious move and is wrong. Cargo.toml holds the version most recently bumped, which is not the version most recently published — right now it says 0.8.0-alpha.0 for a tag that was never pushed, while the newest release is 0.7.0. The page would advertise a download with no binaries behind it, which is the defect this tool exists to prevent, pointed at itself. Pre-releases are skipped for the same reason: the button beside the number hands over the newest stable, and stating an alpha next to it would be two answers to one question. `pnpm bump:vump` picks the newest stable from the repository's own tags, so pointing the site at a new release is one offline command rather than a lookup that can be rate-limited. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The deployed page shipped an empty #root: correct in a browser, and nothing at all to a crawler, a link preview, or an agent fetching it. That is a strange thing for a page whose entire job is being read by someone deciding whether to try the tool. `vite build` still produces the client bundle; a second pass builds entry-server.tsx to dist-ssr/, prerender.mjs inlines that HTML into #root, and the intermediate is deleted rather than deployed. main.tsx hydrates when #root already has children and renders normally when it does not, which is what the dev server serves. Three things had to stop depending on the browser for this to render on the server, and none of them are workarounds: The theme now lives on the document element rather than in React state. The pre-paint script in index.html is what keeps the page from flashing the wrong theme, and mirroring that into state would have given the server-rendered HTML a theme it cannot know. Reading the attribute at the moment of the click cannot drift from what is on screen. The theme toggle renders both icons and hides one in CSS. Choosing between them in JavaScript would mean the prerendered HTML picks a theme the visitor may not be using, and hydration would swap it under them. The entrance animations are gated on a `js` class the pre-paint script adds. Without that, content held at opacity zero waiting for an observer would leave a scripting-disabled client staring at a blank page — the prerendered markup would be there, and invisible. The site's own address is settled while we are here: vump.codehacks.io, at the root, so the base-path environment variable and its .env are gone. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
A bug report is a screenshot. The badge is fixed to the corner rather than placed in the footer so it appears in every one of them without the reporter scrolling to the bottom first, and it names the pair that identifies a build: the site's version and the commit it was built from. The version is read straight from package.json, which is the file vump keeps in step with the website-v* tag. A separately computed value could drift from that tag; this cannot. The commit arrives as a build-time variable the deploy workflow sets, and reads as "local" when there is no deploy to name. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
release-website.yml builds website/ and publishes it to Pages, gated on `vump check` agreeing the tag matches website/package.json — the same gate the binary's release has, for the same reason: find out before the work, not after the deploy. It uses the composite action rather than the build in the checkout, which is the opposite of what release.yml does and deliberate. release.yml verifies the binary it is about to publish, where an older vump cannot catch a regression in the very code being released. Here the subject is the website's own version, so there is no such regression to miss, and building vump would drag a Rust toolchain and two minutes into a job that ships static files. Installing is `pnpm install --frozen-lockfile`. The committed lockfile is the deploy's declared input, so nothing is resolved or discovered at deploy time and a rebuild of the same commit produces the same bytes. website.yml runs typecheck, lint, format and build on pull requests that touch the site, so a broken page is caught in review rather than by a failed deploy. It is a separate workflow with a path filter rather than a job in test.yml, which has no path filters and would otherwise run the Rust suite for a copy edit. Also anchors release.yml's tag glob to a digit. `v*` matches `voldemort`; it is the same fix the sibling repository already made, and with a second tag shape in play the trigger should be exact about which one it wants. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The action was given `working-directory`, which it does not accept. With no package.json at the repository root — this is a Rust project with a site in a subdirectory — it had nowhere to read a pnpm version from and stopped before installing anything. `package-json-file` is the input that exists, and it is the whole point of keeping `packageManager` in website/package.json: one declared version for local development and CI both. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Every `uses:` in the repository was checked against its published releases rather than assumed. actions/checkout was a major behind and moves to v7; setup-node, configure-pages, upload-pages-artifact, deploy-pages, attest, upload-artifact, download-artifact and pnpm/setup were already current. dtolnay/rust-toolchain stays on `stable`, which is a moving reference that action documents rather than a pin left behind. release-website.yml also loses its workflow_dispatch trigger. On a manual run `github.ref_name` is a branch, so the version gate — `vump check` against the pushed tag — has nothing to check and the deploy would either fail or, worse, be made to skip the one step it exists for. A deploy is a tagged release here. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The repository moved from okcodes/vump to codehacks-io/vump. GitHub's own redirect covers a git remote or a browser link for now, but it is documented to stop working the moment anyone claims the old owner/repo string again - not a hazard worth leaving ten files depending on. Every hardcoded occurrence of the old owner is updated: the release URL and composite action usage in README.md and DESIGN.md's attestation example, Cargo.toml's repository field, the two GitHub API/download URLs download-vump.sh uses for `vump self update`, the REPOSITORY constant that drives it, and the four website files that link to or clone the repository. release-website.yml's own use of the composite action is the one exception, and it does not get the new owner name - it gets no owner name at all. That line was this repository invoking its own action by a remote owner/repo path, which is the same class of problem one level deeper: a rename works today only because the old name still resolves, and would resolve to a stranger's code the day it does not. Referenced by local path (./.github/actions/check) instead, since the actions/checkout step already has it in the workspace - correct regardless of what this repository is ever named or owned by. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This branch has not been deployed
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.
The repository moved from
okcodes/vumptocodehacks-io/vump. GitHub'sredirect covers a git remote or a browser link today, but it is documented to
stop working the moment anyone claims the old owner/repo string again — not
worth leaving ten files quietly depending on.
What changed
Every hardcoded
okcodes/vumpin the tree, updated tocodehacks-io/vump:Cargo.toml'srepositoryfieldsrc/adapters/github.rs'sREPOSITORYconstant — this is whatvump self update/self status/self listactually query, so it was the one thatmattered most to catch
.github/actions/check/download-vump.shuses to resolve anddownload a release
README.md(the download link, two composite-action usage examples) andDESIGN.md's attestation-verification examplewebsite/files: the repo link in its README, thegit clonesnippetshown on the page,
content/links.ts(which every other link on the site isderived from), and the CI snippet in
content/rules.tsOne occurrence is not updated to the new owner — it is fixed a different
way.
release-website.ymlcalled this repository's own composite action byuses: okcodes/vump/.github/actions/check@main. That is this repositorynaming itself and its default branch to fetch code it already has checked out.
Swapping the owner would only move the same fragility one repository name to
the right: it works only as long as
codehacks-io/vumpis never renamed ortransferred again, and the day it is, this line starts silently pulling
whatever ends up at the old address. Referenced by local path
(
./.github/actions/check) instead — correct regardless of what thisrepository is ever called.
cargo test,cargo clippy -- -D warnings, andpnpm run checkall pass.GitHub-side state (not in this diff, done directly against the repo)
Two things I found by testing rather than assuming, both would have surfaced
as confusing failures on the next real deploy:
git remote set-url origin git@github.com:codehacks-io/vump.giton thismachine's checkout.
github-pagesenvironment only allowed deploys from themainbranch. GitHub auto-created it with that default the moment the earlier
failed deploy attempt ran
configure-pages/deploy-pages— butrelease-website.ymldeploys fromwebsite-v*tags, which abranch-only policy does not cover. Added a
tagpolicy forwebsite-v*viagh api repos/codehacks-io/vump/environments/github-pages/deployment-branch-policies -f name='website-v*' -f type='tag'. Confirmed against the siblingcodehacks-io/virtual-consolerepo, whose already-working Pages deploy hasthe equivalent entry.
Also checked and found fine, no action needed: the
Production-Signingenvironment's required-reviewer rule names
okcodesspecifically — that userstill has admin on
codehacks-io/vump, so it is not a blocker. No repositorysecrets are configured yet (separate from the transfer;
APPLE_CERT_P12andfriends were never added for this repo). Branch protection on
main: noneconfigured, transfer changed nothing there.
Left for you
mainreleases won't get past the
Signjob untilAPPLE_CERT_P12,APPLE_CERT_PASSWORD,KEYCHAIN_PASSWORD,APPLE_ID,APP_SPECIFIC_PASSWORD_VUMP, andAPPLE_TEAM_IDare added as repositorysecrets. Not something I should set from here.
transfer even happened) — Settings → Pages → Source: GitHub Actions, plus
the custom domain and DNS, are still yours to do as previously discussed.
.github/actions/checkpointed atokcodes/vump/...needs to update their own workflow tocodehacks-io/vump— the redirect covers them for now, but on borrowed time.
🤖 Generated with Claude Code