Status Update
No update yet.
Comments
uc...@google.com
mc...@ebay.com
We have shared this with our product and engineering team and will update this issue with more information as it becomes available.
mc...@ebay.com
Severity of S3 seems way too low for this case. Failure of lint to see lint checks that are referenced in lint.xml causes lint tp error, failing builds. This happens differently on different machines, leaving us with no choice but to have to disable lint completely.
pa...@etrade.com
P.S. "Russian rou-lint" - this is gold.
tn...@google.com
gh...@google.com
Do you still see this issue with the latest AGP versions? There have been some fixes in this area over the years, but it's tricky to verify because I could not repro originally.
mc...@ebay.com
To work around this issue we restructured our lint checks to be global in nature rather than split across multiple modules. As a result, we're no longer in a position to be able to easily test this.
IIRC, there was a metric ton of lint work that landed after this issue was raised. (Thanks Tor!)
Based on the above, I say close it out. If it is still an issue then we at least owe you an updated repro project. AS 3.6 seems like an eternity ago!
Description
Version of Gradle Plugin: 3.5.3 and 3.6.0-rc03
Version of Gradle: 5.6.4
Version of Java: 1.8.0_212
OS: Mac OS X 10.14.6 x86_64 (and Linux)
lintPublish is not working reliably at all in multi-module builds. This is causing extremely confusing behavior and differences in experience between engineer’s local builds and those under our CI systems. The net result is that builds on our CI nodes are effectively performing a continual game of what I've termed "russian rou-lint", with different lint rules being applied at different times. This is allowing bugs to slip into the codebase which then block unrelated PRs at some point in the future.
I’ve created a sample project which captures the broad set of structural behaviors that we are relying upon in our project:
Project Structure:
```
app
+- androidx:fragment:fragment (Remote AAR)
+- library1 (AAR)
| +- lintChecks1 (Lint Checks JAR)
| +- librarySub1 (AAR)
| +- lintChecksSub1 (Lint Checks JAR)
+- library2 (AAR)
+- lintChecks2 (Lint Checks JAR)
+- librarySub2 (AAR)
+- lintChecksSub2 (Lint Checks JAR)
```
For the app and each library the lint.xml file declares the lint detectors that are expected to be in play.
Expected Behavior:
- app can see lint checks from lintChecks1, lintChecksSub1, lintChecks2, lintChecksSub2, FragmentLiveDataObserve
- library1 can see lint checks from lintChecks1, lintChecksSub1
- librarySub1 can see lint checks from lintCheckSub1
- library2 can see lint checks from lintChecks2, lintChecksSub2
- librarySub2 can see lint checks from lintCheckSub2
Actual Behavior:
- app can see lint checks from lintChecks1, lintChecks2, lintChecksSub2, lintChecksSub2
- library1 can see lint checks from lintChecksSub1
- librarySub1 sees NO lint checks
- library2 can see lint checks from lintChecksSub2
- librarySub2 can see lint checks from lintCheckSub2
Conjecture:
Based upon the behavior differences between CI and local execution, it feels like there is a difference of behavior based upon hashing differences across platforms, perhaps in the class path ordering.