Repository navigation
fix(test): keep Go's module and build caches when a test redirects HOME - #500
Conversation
Many CLI tests point HOME at a temporary directory to isolate Bomly's own state. Go's module and build caches default to directories under HOME, so a test that then built a plugin got empty caches and downloaded the SDK and its dependencies from the module proxy inside the test. macOS runners timed out on that download three times; the third blocked a release at the prerequisites stage. TestMain now pins GOMODCACHE and GOCACHE to their real locations before any test runs. With GOPROXY=off the plugin tests failed before this change and pass after it. The "Download modules" step added to the portable suite is removed. It warmed the real cache, which these tests were not reading, so it fixed nothing. Co-Authored-By: Claude Fable 5.1 <[email protected]>
|
Navigate logical layers of code changes, visualize relationships, and explore their blast radius. Note Currently processing new changes in this PR. This may take a few minutes, please wait... ⚙️ Run configuration
📒 Files selected for processing (2)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Bomly Diff SummaryCompared Overview
Dependency Changes✅ No dependency changes. Vulnerabilities✅ No vulnerability changes. License Changes✅ No license changes. Project Posture✅ No project posture changes ( Policy Findings✅ No policy differences were identified. |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: a709d1bce1
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
… suite Removing it was wrong for the cache-miss case: with no restored cache the suite would fetch every module inside its single go test attempt. Now that the tests read the real module cache, filling it first is what keeps a slow proxy out of them. Co-Authored-By: Claude Fable 5.1 <[email protected]>
Why
The macOS leg of the release prerequisites stage failed with
TLS handshake timeoutfromproxy.golang.orginsideTestPluginTestNotReadyFails, which blocked a release (run). It is the third failure of this kind on a macOS runner.The cause is in the tests, not the network. Many CLI tests set
HOMEto a temporary directory to isolate Bomly's own state. Go's module cache and build cache default to directories underHOME, so a test that then builds a plugin gets empty caches and downloads the SDK and its dependencies from the module proxy mid-test.What changes
TestMainininternal/clipinsGOMODCACHEandGOCACHEto their real locations before any test runs.Verification
GOPROXY=off,TestPluginTestNotReadyFailsfails onmain("module lookup disabled by GOPROXY=off") and passes with this change.GOPROXY=off,./internal/cli/...,./internal/plugin/...,./test/smoke/...and./test/assurance/...all pass.make testandmake lintpass.internal/clitook 260 to 300 seconds on the macOS runner; it takes 52 seconds locally with the caches kept.🤖 Generated with Claude Code
Summary by CodeRabbit
Tests
User-facing Changes