gradle-dependencies-sorter icon indicating copy to clipboard operation
gradle-dependencies-sorter copied to clipboard

Feature request: configurable option for whether or not parse errors fail the task

Open jamesonwilliams opened this issue 2 years ago • 2 comments

Related to https://github.com/square/gradle-dependencies-sorter/issues/36, but distinct.

Using Plugin version 0.1

Current Behavior

Today, the Gradle Dependencies Sorter plugin will continue on without error if it encountered a build script that it doesn't know how to parse. Example output:

Metrics:
  Not sorted:     0
  Already sorted: 1
  Parse errors:   1

Check duration: 63 ms.

[main] INFO Sorter - Operation took 191 ms
[main] INFO Sorter - See log file at /var/folders/wb/phv6x1k53hj0j9rkvg5pf0mc0000gp/T/dependencies-sorter/2023-03-07T20:43:24.076223Z.log 

BUILD SUCCESSFUL in 857ms
1 actionable task: 1 executed

Here, the parse failed, the tool wasn't able to verify the sorting order, but it returned successfully never-the-less.

Discussion

Sometimes this is good. Let's say you have a lot of parse errors in a huge monorepo (I am in this situation), and I don't want to manually go and disable the plugin in every location. I do, however, still want to benefit from the check wherever I can. But sometimes, it's bad - I'd rather "fail fast," and be 100% confident that every build script is well-sorted.

Proposed Feature

It could be convenient to have a configurable option, strictValidation or something. It's up for discussion what a good default convention for this option might be (true, or false). However, the option would allow users of the plugin to decide on behavior that best meets the goals of their repository.

jamesonwilliams avatar Mar 07 '23 21:03 jamesonwilliams

Thanks for the issue. I think we could support this via an extension with a Property<Boolean> that was user-configurable. That would then be piped through to the task that does the checking, enabling it to fail under the right circumstances. We don't have time to work on this right now, but PRs are welcome. If necessary, we could provide advice on implementation details.

autonomousapps avatar Jul 17 '23 04:07 autonomousapps

👋 I've tried to implement this new behavior in #67 The new test might not be in the correctly location. Tell me if you want me to move it somewhere else, or if the parsing error is not "explicit" enough (I could not find a better example).

SimonMarquis avatar Jul 22 '23 08:07 SimonMarquis