Status Update
No update yet.
Comments
sp...@google.com
Some LintError issues (e.g., those caused by OOMs) don't belong in the lint baseline and should cause the build to fail instead.
But after looking into this, I think some LintError issues might make sense in the lint baseline (e.g., a RuntimeException from an old dependency's bundled lint check).
Does that sound right, Tor? If so, maybe lint should just rethrow OOMs instead of catching them and reporting LintErrors? WYDT?
FWIW, I have a (failing) AGP integration test for the case of an OOM in lint not causing the build to fail:
sp...@google.com
Discussed this at the lint meeting today.
The consensus at the meeting was that all LintErrors (and maybe LintWarnings) should not be baselined. If so, there needs to be a change at the lint level, not just the AGP level.
Paul, I'm not sure who the right assignee is on the lint side... can you triage/reassign?
maybe lint should just rethrow OOMs instead of catching them and reporting LintErrors?
In the meantime, I think this is the desired behavior when running lint from AGP, and I've updated
bl...@google.com
bl...@google.com
an...@google.com
Thank you for your patience while our engineering team worked to resolve this issue. A fix for this issue is now available in:
- Android Studio Iguana | 2023.2.1 Canary 6
- Android Gradle Plugin 8.3.0-alpha06
We encourage you to try the latest update.
If you notice further issues or have questions, please file a new bug report.
Thank you for taking the time to submit feedback — we really appreciate it!
Description
Currently, if a user runs
gradlew updateLintBaselineand there is aLintErrorissue (i.e.,"Unexpected failure during lint analysis (this is a bug in lint or one of the libraries it depends on)..."), theLintErrorissue gets added to the lint baseline xml.In cases like this, the build should fail, and the lint baseline should not be modified.