fix(scaffold): bump page-money pins to published (app-sdk 0.31.0, blocks-react 0.39.0) - #203
Merged
Merged
Conversation
…cks-react 0.39.0)
`pins-vs-published` is a REQUIRED check and is currently red on `main`
itself, so every open PR is blocked. The pre-1.0 carets lock the minor,
so `^0.30.0` / `^0.38.0` no longer admit the published 0.31.0 / 0.39.0.
Produced by the repo's own bumper rather than by hand, so the three
literal pin sites cannot drift apart:
go run ./internal/scaffold/cmd/bump-pins
Verified beyond the guard, because a pre-1.0 MINOR bump can break the
template's SDK calls: scaffolded a page-money app with the rebuilt
binary, confirmed npm resolved 0.31.0 / 0.39.0, then `npm run build`
(tsc --noEmit + vite build) succeeded and the template's own suite
passed 138 tests across 11 files.
`make ci` green; full suite with CIVITAI_CHECK_PUBLISHED_PINS=1 is
1332 run / 1331 pass / 0 fail, and TestScaffoldPinsSatisfyPublished now
passes with the network guard enabled.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
Claude-Session: https://claude.ai/code/session_01DC9uE5774YN7oquYrzE4Yq
ZacxDev
added a commit
that referenced
this pull request
Aug 5, 2026
…ed for days (#205) `pins-vs-published` is a REQUIRED status check on `main` and it reads npm's published latest, so from the moment a `@civitai/*` minor lands until `bump-scaffold-pins` rewrites the template's pre-1.0 carets, every open PR is blocked regardless of its content. The bot is not broken — it is too slow. Measured off the npm registry `time` field: app-sdk 0.26.0 Jul 17, 0.27.0 Jul 28, 0.28.0 Jul 29, 0.29.0 Aug 3 20:15, 0.30.0 Aug 3 22:13, 0.31.0 Aug 5 03:54 (2026). Six minors in 19 days — a ~3.6-day mean interval against a 7-day sweep, so upstream published faster than the bot swept and a large fraction of each week sat red. It had to be hand-bumped twice in two days (#194, #203); #203 existed only to unblock an unrelated PR. Daily bounds that window at ~24h instead of ~168h. Nothing else changes: the bumper, its in-job validation, and the PR it opens are untouched. A no-op sweep is cheap because `detect changes` gates every downstream step — verified live here, where the bumper printed "all @civitai/* pins are current — nothing to do" and modified no files. This is the (b) lever the app-analytics handoff doc identified and correctly left as ask-first per AGENTS.md; the decision has now been made, so the doc is updated to record it rather than re-raise it. Verification: actionlint clean on the changed workflow, with a positive control (it rejects `77 7 * * *` with "invalid CRON format", so its acceptance of `17 7 * * *` is a real green). YAML re-parsed to assert the schedule literal, with both a positive control (injecting the old weekly value is observed) and a negative control (malformed YAML raises). `make ci` green — 16 packages ok, 0 FAIL, `go mod tidy` no-op, `gofmt -s -l` silent over 206 Go files. Note the cadence narrows the window, it does not close it: a publish minutes after a sweep still blocks PRs until the next day. If that residual still bites, the next levers are a 6-hourly cron or a `repository_dispatch` fired by the SDK release — both larger changes to `.github/`, so neither is taken here. Claude-Session: https://claude.ai/code/session_01LTYNRi1WkNWzaVMerFRFAC Co-authored-by: Claude Opus 5 <[email protected]>
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.
Why
pins-vs-publishedis a required check and is currently red onmainitself — so every open PR in the repo is blocked, not just one. The pre-1.0 carets lock the minor, so^0.30.0/^0.38.0no longer admit the published versions:@civitai/app-sdk^0.30.0@civitai/blocks-react^0.38.0Same shape as #194.
How
Produced by the repo's own bumper rather than by hand, so the three literal pin sites cannot drift apart:
That rewrites
templates/page-money/package.json.tmpl,templates/page-money/README.md.tmplandscaffold_test.go— 3 files, 5 lines.Verification
A pre-1.0 minor bump can break the template's SDK calls, so the guard passing is necessary but not sufficient. I scaffolded a real app with the rebuilt binary and exercised it:
npm installresolved app-sdk 0.31.0 and blocks-react 0.39.0 (confirmed fromnode_modules, not from the pin);npm run build—tsc -p tsconfig.json --noEmit && vite build— succeeded;Repo side:
make cigreen; full suite withCIVITAI_CHECK_PUBLISHED_PINS=1is 1332 run / 1331 pass / 0 fail, andTestScaffoldPinsSatisfyPublishednow passes with the network guard enabled (it fails onmaintoday — that was the discriminating control confirming this is pre-existing and not caused by any open PR).🤖 Generated with Claude Code