Repository navigation
ci(fork): every release typechecks first, Claude fixes what breaks - #15
Merged
Merged
Conversation
A file git merges without a conflict can still break: upstream's new code called resolveVersionMismatch, whose import the fork had replaced, and the typecheck job stopped the release. resolve-conflicts.sh now installs and typechecks the resolved merge (same apps as that job) and gives Claude up to two rounds to fix the files the errors name. The lockfile is upstream's, regenerated by the install, instead of hand-merged. vp is set up before the merge, while package.json is still clean. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
22 of the last 23 fork releases failed on type errors: 21 on fork code that reached collin/main unchecked (upstream's CI needs Blacksmith runners, so PR checks never ran here), one on a merge git completed without a conflict. prepare now runs fork/resolve-merge.sh on every build, not only on conflicts: it resolves conflicts, installs, typechecks server, desktop and web, and gives Claude up to two rounds to fix the files the errors name, in the build only. That replaces the separate typecheck job, since prepare checks the exact commit the builds check out. Results are cached per fork/upstream pair. fork-check.yml typechecks pull requests into collin/main and pushes to it on GitHub's runners, so broken code is visible before it lands. Co-Authored-By: Claude Opus 5.5 <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
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.
22 of the last 23 fork releases failed on type errors: 21 on fork code that reached
collin/mainunchecked (upstream's CI needs Blacksmith runners, so PR checks never ran in the fork), one on a merge git completed without a conflict (upstream's new code called a helper whose import the fork had replaced).Every build (
prepareinfork-release.yml, viafork/resolve-merge.sh, renamed fromresolve-conflicts.sh):--no-commit; Claude resolves conflicts as beforepnpm-lock.yamlis upstream's, regenerated byvp install, never hand-mergedpreparechecks the exact commit the builds useVP_GIT_HOOKS=0, so the bot commit does not run the repo's lint hooksPull requests and pushes to
collin/main: newfork-check.yml, frozen install + the same typecheck onubuntu-latest.Lint stays out of both gates on purpose.
Tested locally with the real Claude CLI:
resolveServerConfigVersionMismatch; merge committed with both parentscollin/mainwith an injected type error, nothing to merge: Claude restored the import, build commit on top🤖 Generated with Claude Code