ci: typecheck, tests, and bundle-drift check for built userscripts - #5
Merged
Conversation
No workflows existed, so typecheck and test only ever ran locally and a broken commit could reach master unnoticed. Adds .github/workflows/ci.yml, matrixed over the three projects that build a userscript from src/*.ts. Each job runs npm ci, typecheck, test, then rebuilds and requires the committed *.user.js to be byte-identical to the build output. That last check is the one with user impact: @downloadurl serves the committed bundle straight off master, so a stale bundle ships broken code to anyone who auto-updates. Includes gitlab/gitlab-code-search alongside auto-login and jira/jira-ticket-extractor. It has the same shape and the same committed bundle exposure, so omitting it would leave the drift risk half-covered. All three projects pass typecheck, tests, and the drift check as of this commit, so CI lands green. Closes #3 Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01WSt6ZYkUkUyDc28cHgwhDj
Review of the initial workflow surfaced a false negative in the check that is the whole point of this change. git diff only compares tracked files, so a build output that was renamed in build.mjs or never committed is invisible to it: the old bundle is untouched, the new one is untracked, and CI goes green while @downloadurl keeps serving the stale file. Verified by dropping an untracked *.user.js into a project — the old check exited 0. Gate on git status --porcelain instead, which reports untracked and modified alike, and does so without staging anything. Verified it catches both drift modes, stays clean at baseline, and stays scoped to its own project rather than tripping on a sibling. Also from review: - cancel-in-progress no longer applies to master, where cancelling would leave a merged commit with no CI result. - timeout-minutes: 10, so a hung vitest run cannot hold a runner for the 6-hour default. - Error message says 'npm ci && npm run build' — a contributor whose local esbuild floated off the lockfile has already run the build, so the old wording sent them hunting. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01WSt6ZYkUkUyDc28cHgwhDj
This was referenced Jul 20, 2026
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.
Closes #3.
No
.github/workflowsexisted, sotypecheckandtestonly ever ran locally and a broken commit could reachmasterunnoticed.Adds
.github/workflows/ci.ymlonpush(master) andpull_request, matrixed over the three projects that build a userscript fromsrc/*.ts. Each job:npm ci→typecheck→test→ rebuild and require the committed*.user.jsto be byte-identical to the build output.Verified locally before pushing
auto-loginjira/jira-ticket-extractorgitlab/gitlab-code-searchThe issue flagged that jira's suite hadn't been run recently and might need fixing first — it passes as-is. All three bundles already match source, so this lands green rather than red.
Two deviations from the issue
Added
gitlab/gitlab-code-searchto the matrix. The issue lists only two projects, but this one has the identical shape — same scripts, same committed.user.jsserved by@downloadURL. It carries exactly the drift exposure the issue is about, so omitting it would leave the stated risk half-covered.Confirmed the drift check can actually fail. First attempt at testing it was wrong: appending junk to the committed bundle proves nothing, since
npm run buildjust overwrites it. The real scenario is source changed, bundle not rebuilt — forced by bumping the version without rebuilding. The check caught it and exited nonzero.Determinism holds: neither build embeds a timestamp, and
npm cipins esbuild through the lockfile, so the byte-comparison won't flake.Not included
The secret / proprietary-reference scan from the issue. It needs either a third-party action or hand-rolled regexes plus a false-positive baseline for an existing public repo — a noisy red CI you learn to ignore is worse than no scan. Better as its own issue.
🤖 Generated with Claude Code
https://claude.ai/code/session_01WSt6ZYkUkUyDc28cHgwhDj