Keep those warnings away! — Add Android Lint to your CI pipeline
So… you’ve decided to add a static code analysis tool to your project to identify potential issues before they arrive to production… but where do you start?
At eDreams ODIGEO, our Android team has decided to add Android Lint inspections to our project. The approach is to add the lint checks in our existent Jenkins pipelines, so they will run every time we create or modify a pull request.
Follow me in the steps necessary to achieve it:
Step 1. Add lintOptions to build.gradle file
As a first step, we need to configure the lint options in our app module build.gradle file:
Let’s explain each option one by one:
baseline file("lint-baseline.xml"): This will create a snapshot file containing the current set of warnings within the project.
It allows us to start using lint inspections without breaking the builds on every run by already-present issues.checkDependencies true: If, like us, you have a multi-module project it is encouraged to add this line for performance reasons (to avoid multiple checks on the same files) and to have only one report with all the issues listed.ignoreTestSources true: To save some time in the inspections, we won’t check the code on test files.warningAsErrors true: By adding this option all warnings will be treated as errors (thus, breaking the builds). If we don’t add it, the warnings will still be listed in the report.
(We can always add filters in lint.xml to ignore some issues in case we find it too restrictive as shown later on).warning 'LintBaseline': Important if we used the baseline file and warningsAsErrors options, as the report will always contain a ‘LintBaseline’ warning to remind us that we still have issues unaddressed and, if we don’t override it as a warning, it would break all builds.lintConfig file("lint.xml"): If we want to add filters to ignore certain issues, specific files or entire packages we will need to add this option and create a lint.xml file under app module with our rules.
Notice that the order in which we list the options is important. For example if we want to override the warningAsErrors for specific issue types (like we do with warning 'LintBaseline') we should write them below.
Step 2. Add the lint.xml file
We can add a lint.xml file to change the severity level of the issues or completely ignore them. We can also add a path or regexp attribute to specify which files or folders to take into account.
As we can see, we ignore all the issues in localizables.xml files (we have a CMS in charge of this) and in /.gradle/ folder.
We also ignore the UnusedResources issue type for specific files.
Step 3. Generate the baseline snapshot
After adding all the options and rules that we want to have in our inspections, it’s time to generate the baseline file that will list the current issues.
For that we need to execute lint for the very first time using:./gradlew :app:lint<flavour><variant>.
It’s recommendable to specify a concrete build variant to avoid adding extra time analysing all of them.
This will run the inspections and will create the lint-baseline.xml file. Now we have lint configured in our project and we can start using it!
Step 4. Add lint to pipeline in Jenkins
Lastly, we will add the lint inspection to our existent CI pipelines.
To do so, first we will need to install a plugin capable of reading and format the reports generated by Android Lint. We use Warnings Next Generation.
Once installed (manually or using Jenkins plugin manager) we can add the new stage to any pipeline:
Here is how the complete pipeline looks now in our CI server:
If a new warning is detected in the lint analysis step, the job will be aborted and the issue will be shown in the report.
From now on only warning-free code is allowed in our project!
