docs: make the gate ./gradlew build, not clean build - #3314
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
🚧 Files skipped from review as they are similar to previous changes (1)
📝 WalkthroughWalkthroughBuild guidance now uses ChangesGradle verification guidance
Estimated code review effort: 1 (Trivial) | ~3 minutes Possibly related PRs
Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 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 |
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@AGENTS.md`:
- Around line 16-21: The verification wording in AGENTS.md incorrectly presents
clean build as the exact CI command. Update the documentation to distinguish the
CI workflow’s build task from the recommended local ./gradlew clean build
command, while retaining the existing duration and zero-failure expectations.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
7a4aa7e to
f4cdaa5
Compare
AGENTS.md told agents to run 'clean build' and then, to dodge the six minutes that costs, to judge by hand whether a diff could affect anything. Both halves were wrong. CI runs 'build'. Without 'clean', Gradle's up-to-date check already answers the question the paragraph asked a human to answer, and answers it from the real task inputs rather than a hand-written path list -- a docs-only build finishes in one to three seconds here. Dropping 'clean' removes the incentive to skip and the need to classify, so the paragraph goes with it. The list it carried was wrong in both directions anyway: '.github/workflows/' cannot fail a Gradle build, while LICENSE.txt -- which reads as documentation -- is copied into META-INF of every jar. Comments were listed as safe to skip, but autostyleCheck reflows javadoc and .java files ship in the published sources jar. Also corrects what CI runs: the branches: ['*'] filter in test.yml does not match '/', so pushing a slash-named branch triggers no build at all until a pull request exists, and pull requests get an OpenRewrite check and wrapper validation on top of the matrix.
f4cdaa5 to
a8335e4
Compare
Follow-up to #3302 and #3309.
What this started as, and what it became
The first version of this PR added a paragraph telling agents to judge by hand whether a diff could affect the build, so they could skip the six-minute
clean buildon documentation changes. A review pass took it apart.The paragraph was working around a cost I had created myself. CI runs
build, notclean build. Withoutclean, Gradle's up-to-date check already answers the question the paragraph asked a human to answer — and answers it from the real task inputs, which cannot drift. Measured here:buildwith real work to dobuildafter a documentation-only changeSo the gate becomes
./gradlew build, and the paragraph is deleted rather than fixed.cleanstays documented for ruling out stale output.The list it carried was wrong in both directions
.github/workflows/cannot fail a Gradle build. It was listed as something that "does break the build", one sentence after the build was defined asclean build. An agent editing a workflow, running the gate and seeing green would have verified nothing — the exact failure the paragraph existed to prevent.LICENSE.txtdoes. It reads as documentation and is copied intoMETA-INFof every jar bytestng.java-library.gradle.kts.autostyleCheckruns google-java-format, which reflows javadoc, and.javafiles ship in the published sources jar. Both were reproduced as failing builds during review.Also corrected
"CI runs it on every push and pull request"was false. Thebranches: ['*']filter intest.ymldoes not match/, and every branch here has one — so pushingdocs/footriggers no Test run until a pull request exists. Verified against the run history: every push-triggered run is onmaster. Pull requests also get an OpenRewrite check and wrapper validation on top of the matrix, so a green local build is not a green CI.CLAUDE.mdis aligned with the new gate.Verification
Applied the new rule to itself: documentation-only diff, so
./gradlew build— 1s, exit 0, andverifyPublishedPomDependenciesstill green. Staleness checked before committing.Summary by CodeRabbit
./gradlew buildas the CI gate.cleanis appropriate and why local results may not match CI outcomes.buildworkflow and improve pipeline failure visibility.