Ensure Lint behaves the same in Debug and Release

[Guardiola31337]

Lint behaves differently depending on the build type.
We should ensure that behaves the same in both Debug and Release in order to detect potential issues as soon as possible (e.g. #8356).

cc/ @zugaldia

[Guardiola31337]

In order to accomplish this, we could add a lint check on CI. Run lint with Gradle.

At the moment, CI only includes steps that execute assembleDebug or assembleRelease but those tasks don't run the lint task. Which means that we're not executing lint at all.
The lint task is executed when running build task though.

I checked those assumptions analyzing the dependency tree report of each task generated by Gradle Task Tree.

Do we want to include lint errors on CI?
If so, first we should discuss:

• How?
• What lint errors make a build to fail?
• Release/Debug config?
• Please add here or as a comment anything I might have missed.
• ...

If we decide so, a great way to gradually introduce lint is to create a warnings baseline so:

You can take a snapshot of your project's current set of warnings, and then use the snapshot as a baseline for future inspection runs so that only new issues are reported. The baseline snapshot lets you start using lint to fail the build without having to go back and address all existing issues first.

@mapbox/android Thoughts?

[Guardiola31337]

Further useful information:

• List of all lint checks
• LintOptions

[zugaldia]

@Guardiola31337 Thanks for looking into this, I'm all for additional checks that could help us find potential issues earlier.

I like the idea of activating lint using our current baseline as starting point. How does that baseline look like? Is it a XML file that we'd commit to the repo?

[Guardiola31337]

@zugaldia

How does that baseline look like? Is it a XML file that we'd commit to the repo?

Yeah, you only need to add

android {
  lintOptions {
    baseline file("lint-baseline.xml")
  }
}

to build.gradleand execute lint gradle task so then lint-baseline.xml is created including all lint errors. After that, those errors are ignored:

After you create the baseline, if you add any new warnings to the codebase, lint lists only the newly introduced bugs.

Cool thing is that lint warns/reminds you that one or more issues were filtered out because they were already listed in the baseline. Even if you fix issues included in the file it lets you know that it's a good time to recreate the baseline 👍

[zugaldia]

@Guardiola31337 🚀

I'd like to see our current baseline. If the resulting file is easily readable we could manually remove items we don't want to whitelist.

[Guardiola31337]

👀 @zugaldia

• MapboxGLAndroidSDK:

60 errors were filtered out because they were listed in the baseline file, lint-baseline.xml

• MapboxGLAndroidSDKTestApp:

238 errors were filtered out because they were listed in the baseline file, lint-baseline.xml

• MapboxGLAndroidSDKWearTestApp:

8 errors and 70 warnings were filtered out because they were listed in the baseline file, lint-baseline.xml