ci(chromatic): rebaseline main on lockfile bumps

[nedtwigg]

Adds pnpm-lock.yaml to the Chromatic push trigger only.

The gap

chromatic.yml filters both triggers to lib/** and docs/stories/**, which mirrors the Storybook globs exactly (lib/src/**/*.stories.tsx + docs/stories/**/*.mdx, with .storybook/ config under lib/**). The root pnpm-lock.yaml is outside both.

lib/package.json is covered, so a bump that widens a specifier triggers a build — but Renovate's in-range updates are lockfile-only and slip past on the PR and on main. All six dependency PRs merged today (#589–#594) were exactly that shape, tailwind-variants among them.

The cost isn't the missing run, it's attribution. Chromatic picks a baseline by walking back to the nearest ancestor build, so the next PR touching lib/** diffs against cbb1e9d0 (#582). Any pixel change from tailwind-variants 3.3.1 surfaces inside that unrelated PR, reads as its doing, and gets accepted into the baseline there.

Why push-only

On main, the build re-baselines against the commit that actually moved the dependency, so the change is attributed to that bump in the dashboard instead of polluting the next feature PR.

Adding it to pull_request too would catch it a step earlier but bill a full ~267-story run on every dependency PR marked ready — Chromatic treats a dependency change as global, so TurboSnap can't narrow it. That cuts against the 35 stories deleted for snapshot cost in #579.

Note

workflow-audit.yaml will report this commit on its next nightly run: it's a human-authored workflow change, so it matches neither the Renovate-pin nor the tend-regen classifier. That's the audit working as intended.

🤖 Generated with Claude Code

https://claude.ai/code/session_01GD8aAjqaoKVbWGwYdQ3BYZ

[cloudflare-workers-and-pages]

Deploying mouseterm with    Cloudflare Pages

Latest commit:	aa297b5
Status:	✅  Deploy successful!
Preview URL:	https://577c25b5.mouseterm.pages.dev
Branch Preview URL:	https://ci-chromatic-lockfile-baseli.mouseterm.pages.dev

View logs

[dormouse-bot]

The trigger addition is correct and the push-only scoping holds up — pnpm-lock.yaml at the root is outside both existing globs, and lib/package.json being covered by lib/** is exactly why rangeStrategy: update-lockfile slips through. Two gaps around it, neither a defect in the diff.

Merging this doesn't clear the backlog it describes. The commit that lands changes only .github/workflows/chromatic.yml, which matches none of the three push globs, so no build fires — and chromatic.yml has no workflow_dispatch. The already-merged bumps still have no build of their own: 05e25e07 (tailwind-variants to 3.3.1), 0ae25544, 6a4d3816, 5cb70021 are all lockfile-only on main today. So the next lib/** PR still diffs against cbb1e9d0 and still absorbs any 3.3.1 pixel change as its own — the exact failure the PR is written to prevent happens once more before the fix has anything to bite on. A workflow_dispatch: entry under on: would both close that and give the same escape hatch the next time a rendering input lands outside the globs. Happy to push that if you want it.

Same class of gap, other direction: the Storybook build pulls source from three packages outside both filters. lib/.storybook/main.ts aliases dor → ../../dor/src, remote-lib-common → ../../remote-lib-common/src, and dor-lib-common → ../../dor-lib-common/src, and those are load-bearing for stories, not just types — lib/src/stories/PocketWall.stories.tsx imports toBase64Url/DirectoryEntry from remote-lib-common directly, and lib/src/lib/terminal-lifecycle.ts imports shellCommandKind from dor/commands/shell-quote. A commit in any of those three trees is in the story dependency graph and triggers Chromatic on neither event. Mostly logic modules, so the pixel risk is lower than a rendering dependency — but it's the same "rendering input outside the glob" shape, and worth deciding on deliberately rather than by omission.

Holding the approve on the first point only, since it changes what happens right after merge rather than anything in the diff.

[nedtwigg]

Took both points — thanks, the first one was the important catch.

workflow_dispatch added. Confirmed the gap: this PR's own merge commit touches only .github/workflows/chromatic.yml, which matches no push glob, so without a dispatch the fix couldn't reach the bumps already sitting on main and the next lib/** PR would have absorbed the tailwind-variants 3.3.1 change exactly as described. Worth noting for whoever runs it: a dispatch baselines main's current HEAD, so all six bumps land as one lump attributed to current main rather than to each commit — still much better than it surfacing inside an unrelated PR.

The three aliased packages added to the push trigger. The claim checks out and is a bit broader than the two files cited — lib/src has 20 files importing dor/, 45 importing remote-lib-common, 2 importing dor-lib-common — and it isn't purely logic: terminal-lifecycle.ts feeds shellKind into header derivation, which renders.

Push-only, same reasoning as the lockfile. Marginal cost measured over 60 days of first-parent main history, counting only commits that match neither lib/** nor docs/stories/**:

Push glob	Extra builds / 60d
pnpm-lock.yaml	31
dor + remote-lib-common + dor-lib-common	2

The three trees nearly always move with lib/**, so covering them is close to free. For context on the lockfile line: main already builds ~120 times per 60 days from lib/**, so this is roughly +26%, not a step change.

Also checked whether docs/specs/security-ci.md needs an edit for the new trigger — it doesn't. Its claim is that the bot can reach CHROMATIC_PROJECT_TOKEN because it can author workflows, which workflow_dispatch doesn't change.

[dormouse-bot]

Both points landed as described, and the dispatch clears the gate it needs to: the job's if: opens with github.event_name != 'pull_request', so a workflow_dispatch run passes rather than falling through the draft/fork clauses. Checks are green on aa297b5d.

One operational note for the post-merge rebaseline, not a change request: workflow_dispatch only appears once the trigger is on the default branch, so the run has to come after this merges — which also means the lump is attributed to a main HEAD that includes this workflow commit, matching what you described.

Approving.