docs: CI is no longer the only way to compile this module - #48
Conversation
CLAUDE.md said "No local Java on macOS dev machine -- all compilation is via GitHub Actions CI", which made every change here a CI round trip. That is now only half true, and the half that is true is worse than it read: the mini HAS Temurin 17 and the JVM crashes at startup -- SIGBUS (0xa) ... V [libjvm.dylib] CodeHeap::allocate on plain `java -version`, in -Xint, and with a reduced code cache, on a correct arm64 JDK with an intact signature. So it is the JVM, not Gradle or the SDK, and re-installing JDKs there is wasted effort. Recorded so the next person does not repeat it. Linux Docker on the build host works fine, so scripts/remote-gradle.sh runs the same major JDK CI uses against a persistent SDK and Gradle cache: ~26s warm versus a CI round trip. Stated explicitly as a PRE-CHECK, not a replacement: CI also builds the signed release variant and runs lint against the baseline, neither of which this does. A green run here must never be reported as "CI passed".
|
Warning Review limit reached
Next review available in: 46 minutes You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
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 |
1 participant
CLAUDE.mdsaid:That made every change here a CI round trip. It is now only half true, and the true half is worse than it read.
The mini has a JDK, and it is broken
brew install --cask temurin@17succeeds, and then:on plain
java -version. Also in-Xint(no JIT), and with-XX:ReservedCodeCacheSize=64m. The arch is right (arm64 JDK on arm64 host) andcodesignshows an intact signature with the hardened-runtime flag — so it is the JVM itself, not Gradle, the Android SDK, or quarantine.Worth writing down mainly so nobody re-installs JDKs there expecting a different outcome. I did, twice.
What works
Linux Docker on the build host.
scripts/remote-gradle.shrsyncs the module and runs Gradle ineclipse-temurin:17-jdk— the same major versionci.ymluses — against a persistent SDK and Gradle cache:testlintDebugThis turned the Android work in #47 from CI-roulette into a real loop, and caught a compile error (
app.namevsapp.displayName) plus nine mutation controls that would each have cost a CI round trip.Stated as a pre-check, not a replacement
CI additionally builds the signed release variant and runs lint against
app/lint-baseline.xml. Neither happens here, so the doc and the script header both say a green local run must never be reported as "CI passed".The rsync excludes
.beadsdeliberately — these repos are public and one bead holds real wallet addresses.