build: commit a Gradle wrapper for the JetBrains plugin - #61
Merged
Conversation
Gradle is not installed on the dev machine and never has been on PATH, but `editors/jetbrains/` had no wrapper, so every release that needed `gradle publishPlugin` had to re-acquire Gradle first. That cost time on 0.4.0 and again on 0.5.0, each time looking like the publish was blocked when it was only the launcher that was missing. The wrapper pins 8.12, the version the project has always built with, and fetches it on first use. RELEASING.md and the plugin README now say `./gradlew`, and RELEASING says why a bare `gradle` is the wrong reach. Also records in the ledger that the JetBrains upload waits on moderation, so the plugins API reporting the previous version is not a failed publish.
A committed `gradlew` with CRLF fails on Linux and macOS with a bad-interpreter error, and the `.bat` wants the reverse. Both are correct in the index today; these rules keep them that way regardless of a contributor's core.autocrlf, and mark the wrapper jar binary so it is never line-ending converted.
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.
Gradle is not installed on the dev machine and is not on PATH in either shell, yet
editors/jetbrains/had no wrapper. Every release that neededgradle publishPlugintherefore had to re-acquire Gradle first. That happened on 0.4.0 and again on 0.5.0, and both times it read as "the JetBrains publish is blocked" when only the launcher was missing.~/.gradle/caches/8.12and~/.gradle/daemon/8.12show Gradle 8.12 has run against this project before, so the wrapper pins that same version. It fetches the distribution on first use — verified here by running./gradlew --versionfrom a clean state and watching it download and report 8.12.0.5.0 is published:
./gradlew publishPluginsucceeded against the Marketplace. The plugins API still lists 0.4.0 as the newest approved version, because uploads wait on JetBrains moderation. That distinction is now written into RELEASING.md and the ledger, since it looks identical to a failed publish.Changes:
editors/jetbrains/gradlew,gradlew.bat,gradle/wrapper/committed (wrapper 8.12;gradlewmode 100755)..gitattributespinsgradlewto LF andgradlew.batto CRLF, and marks the wrapper jar binary. Both blobs are already correct; the rules keep them correct regardless of a contributor'score.autocrlf.RELEASING.mdandeditors/jetbrains/README.mdsay./gradlew, and RELEASING says explicitly not to reach for a baregradle, with the reason.