Make the runToFix message customizable in SpotlessCheck
See original GitHub issueThere’s been some broad discussion in the Lucene project about the sense of having per-project messages in SpotlessCheck:
throw new GradleException(DiffMessageFormatter.builder()
.runToFix("Run '" + calculateGradleCommand() + " " + getTaskPathPrefix() + "spotlessApply' to fix these violations.")
Many people expressed the opinion that this is just confusing for new users (you fix one violation in one module, then you get an exception elsewhere) and the message should just be “global”. I wonder if it’d be possible to add a hook that could customize the returned message (perhaps a hook accepting DiffMessageFormatter.Builder)? Then you could set runToFix to a project-specific message (or task).
This is a suggestion but it is really difficult to work around in any other way. If you think it’d be acceptable, I can provide a patch. Thank you.
Issue Analytics
- State:
- Created a year ago
- Comments:10 (10 by maintainers)
Top Results From Across the Web
spotless/CHANGES.md at main - GitHub
Added a runToFixMessage property to customize the run-to-fix message in spotlessCheck task. (#1175); Added support for enabling ktlint experimental ruleset.
Read more >Stroke width inconsistency - Ionic-Team/Ionicons - IssueHint
Issue Title Created Date Comment Count Updated Date
Entering doc strings via doc attribute fails 2 2020‑04‑02 2022‑08‑01
is_all() vs. from_bits_unchecked() 0 2020‑01‑22 2022‑08‑01
calling netbird...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Published in
plugin-gradle 6.5.0
.I think I know what caused this - I used my own fork to create a PR. When you clone your own fork, origin/main may be out of sync (before the feature branch you’re contributing). This causes ratchetFrom to go haywire. A clean checkout indeed passes tests but this won’t:
That configuration cache test still fails for me (on beefy windows machine) - can’t say whether it’s a race condition somewhere or if it’s the environment itself. On Linux it seems to work fine.