Closed sebokopter closed 5 months ago
Thank you so much for the PR. The behavior was intentional before, with the major difference being the log to contain the stacktrace vs not.
However, I can see how that might still cause a lot of logs, especially for significantly more complex projects. I'll try to come to review this one as soon as possible.
@mikepenz thanks for your quick reply :smiley:
Regarding the stacktrace: Shouldn't the debug log in this case contain the warning with the stacktrace, and currently the non-debug logs have the additional stacktrace attached.
Two other implementations could be:
@mikepenz Thanks for the approval and merge 🙏
Do you have an estimate when then next release will happen?
I might be able to get out a new build sometimes this week.
We still see a while lot of log spam.... we're talking hundreds of lines of logs in GH Actions and local builds, even after the latest release. Is there a way to turn that off?
Can you please provide more details @androidacy-user
Can you please provide more details @androidacy-user
- which log messages do you see
- what's your log level (logs will show for info and debug log levels)
- how do you run the gradle task
1). Dozens of the same messages as mentioned in the OP
2) We don't set it (so whatever the norm is)
3) Android studio build or GitHub actions via ./gradlew build
@androidacy-user Did you set org.gradle.logging.level
in the gradle.properties
file, either the one in the Gradle project or the one in your Gradle user home directory (e.g. $HOME/.gradle/gradle.properties
)? And if so what is its value?
And can you please post the output of ./gradlew buildEnvironment
?
@androidacy-user Did you set
org.gradle.logging.level
in thegradle.properties
file, either the one in the Gradle project or the one in your Gradle user home directory (e.g.$HOME/.gradle/gradle.properties
)? And if so what is its value?And can you please post the output of
./gradlew buildEnvironment
?
1) No, as I said, I never touched it 2) Can that command run from Studio? I don't happen to have a proper env setup for standalone gradle locally
Here's a "small" sample of what is spamming the logs. Note that i had to remove stacktraces to stay under github's char limit, it was 3000+ lines originally.
Note that the studio build is single variant in general, but we have multiple sub-projects. Actions builds are all variants.
Here's the result of running the buildEnvironment task from android studio:
@androidacy-user you are using an old version (11.1.3) of the AboutLibraries plugin. Please update to the latest version 11.2.1.
11.2.1 is the first version where this pull request is applied.
@androidacy-user you are using an old version (11.1.3) of the AboutLibraries plugin. Please update to the latest version 11.2.1.
11.2.1 is the first version where this pull request is applied.
I'm not though 🤔
@androidacy-user Your builldEnvironment
output indicates that you are using the com.mikepenz.aboutlibraries.plugin:com.mikepenz.aboutlibraries.plugin.gradle.plugin:11.1.3
Android Gradle plugin.
Most likely you are mixing the AboutLibraries Gradle plugin and the AboutLibraries compile classpath depedencies. You might have the later one (the compile classpath dependencies) at version 11.2.1, but the former one (the Android Gradle plugin which you define in plugins
) you probably declared the version 11.1.3.
If you need more help please provide the full build.gradle(.kts)
and settings.gradle.kts
files and/or a minimal reproducible example.
Although this is not a Q&A forum, so please think about the volunteers time you are spending here, before continuing posting further comments.
Follow-up to #955 and #956
Summary
Even after the the latest changes in #956, our code base is still flooded/spammed by the
AmbiguousArtifactVariantsException
logs.We have a quite large amount of flavor dimensions with 4 different flavors. This many flavors probably causes more cluttering logs than in many other code bases. So we are especially affect.
Therefore I'd like to propose to reduce the log noise even more.
Background
AmbiguousArtifactVariantsException
InsightsThe content of the
AmbiguousArtifactVariantsException
message
is the following:So printing "only" the
message
of thisAmbiguousArtifactVariantsException
exception is already adding a lot of noise to the Gradle logs. Themessage
alone can take up to 157 lines when using four Android flavor dimensions. And this exception is thrown multiple times. In the case of four flavor dimensions 30 times (30*157=4710 lines).The current
isDebugEnabled
condition is seemingly invertedPrinting the exception stacktrace for non-debug logs is likely unwanted and "only" the
message
for debug log.The
isDebugEnabled
else condition is currently always printedLOGGER.warn
is always printed (becauseisWarnEnabled
is alwaystrue
). Therefore the (expected)AmbiguousArtifactVariantsException
exception is always logged.Plugin Users Point Of View
AmbiguousArtifactVariantsException
is for the plugin consumers not actionable at the moment. So any details about it is not adding value, but only clutters the users log output.Pull Request Changes
With the insights from above this Change Request disables by default any output of the
AmbiguousArtifactVariantsException
exception. It is not actionable for the plugin users and therefore should not be shown by default.Slightly more information can be requested via the Gradle
--info
CLI parameter (isInfoEnabled
) where only the an hint is printed, that there's an ambiguity in the resolved config, and no further details.Debugging information can be requsted via Gradle
--debug
CLI parameter (isDebugEnabled
) which provides the complete exception with all the details.