gradle / gradle

Adaptable, fast automation for all
https://gradle.org
Apache License 2.0
16.85k stars 4.71k forks source link

simple way to reduce CLI reporting of dependencies when writing locks #30716

Open xenoterracide opened 1 month ago

xenoterracide commented 1 month ago

Expected Behavior

I want the list of dependencies but including the projects, basically the output should be similar to the result of this small shell script I keep in a Makefile

./gradlew dependencies --write-locks --scan | grep -e FAILED -e https
https://gradle.com/s/vj57gufd42bai

probably something like

tasks.withType<Dependencies>().configureEach {
  report { verbosity = FAILURES }
}

I understand that it's currently possible, but the way I was told is so complicated as to not be worth the effort figuring it out or maintaining the code to do so. Only printing failures or perhaps the tree including the failure seems reasonable.

Current Behavior (optional)

No response

Context

As it stands you can easily do --write-locks and not realize anything is failing at all.

yes you can figure this out by looking at a scan, but that is significantly annoying when you don't know that there's anything that needs to be looked at.

ov7a commented 4 weeks ago

This issue needs a decision from the team responsible for that area. They have been informed. Response time may vary.


It seems like the CLI approach is good enough. A plugin can also address that. However, since it looks like a common use case, we can consider documenting the described approaches and/or including the suggested output filtering in the core task.

big-guy commented 1 week ago

Alternatively, --write-locks could change the behavior of dependencies to fail the build or hide output. Or we should have a task similar to dependencies that is specifically made for writing locks that has the better behavior.

We're not planning on changing this in 8.x

xenoterracide commented 1 week ago

Or you could add a command line option to show only failed dependencies.

Side comment it didn't occur to me that this didn't fail the build. I think that writing locks where there are failures should fail to build regardless of whether it's on dependencies. I guess this issue is more about the dependencies report output than it is that. I could open another issue for that?