Running the android lint code analysis on your jenkins server
Hot on the heels of yesterdays post about the cool new Jacoco plugin for Jenkins, i wanted to point out another invaluable Jenkins plugin: the Android Lint Plugin.
Android development did become a lot more robust with the introduction of the Lint tools in the Android SDK. Lint is a static code and resources analysis tool, that is similar to findbugs or pmd, in the way that is creates warnings when certain undesired patterns occur. Some of the more prominent Lint checks are:
- Calling api methods from newer Android versions than your currently set minimum Android verision
- Strings that are not internationalized
- Images that are missing in different resolutions
- Layouts that use unnecessary elements
- And many more…
The list is rather comprehensive and i encourage everybody to dig through the list of rules to grasp the power of Lint. There are certain checks that are still missing but it is possible to extend Lint with custom rules if you choose to do so.
Although lint embeds nicely into eclipse (and also into IntelliJ) the truth about your project naturally resides on the build server. Since Lint is basically a command line tool the output can easily be gathered by the Jenkins build server for further analysis.
The Android Lint plugin for Jenkins has been developed by +Christopher Orr and has a great integration with the various Jenkins features like showing graphs, drilling down into the concrete code passages and also showing you the Lint messages of how to resolve the problem.
The only issue i have with the plugin is the inablillty to make a build fail. Even when Lint finds an issue that it marks as an “error” (like using api that is newer than your current minimum api version), the build does not fail. The error is merely recorded.
UPDATE: As Tor Norbye pointed out in the comments you can actually make the lint analysis fail when lint detects an error. Simply add –exitcode to the lint generation. So it would not be the Lint Jenkins plugin but the analysis process that fails your build. To run Lint simply invoke it from your Android SDKs /tools dir.
lint --exitcode --xml lint-results.xml . |
UPDATE2: The rules currently contained in the Jenkins plugin are not the latest rules from the Android SDK (rev 20.0.1 currently). The Jenkins plugin needs to be updated to reflect these latest rules. Shouldn’t it be possible to use the life rules from the Android SDK directly?
None the less. Having build output from the Lint tool provided invaluable for us already and i highly encourage everybody to integrate the plugin into his own Jenkins builds (it also works on hudson btw).
5 Responses to “Running the android lint code analysis on your jenkins server”
You can supply the argument “–exitcode” to lint in your buildjob for it to set a non-zero exit code, which will fail the build. (Lint initially defaulted to doing this, but it was controversial, so I changed it to an optional flag).
– Tor
(Note that should be two dashes, –exitcode; not sure if the blogging software is “cleaning it up” into an emdash or something.)
Hey Tor Thanks for pointing out the –exitcode. I have updated the blog post accordingly.
Also i discovered that the rules used in the plugin are not the latest ones from the Android SDK.
Anyways… Keep up the good work.
As far as I understand, the Jenkins plugin doesn’t run lint on its own; you run lint and create an XML file which the Jenkins plugin will then read & present. So, the actual lint rules run should depend directly on the Android SDK and you should have all the latest checks. However, I believe the plugin bundles the *descriptions* of the issues such that it can present them as tooltips etc as shown in your screenshot. It needs to do this since the XML report doesn’t contain these. I should add them to the report such that the plugin can access them directly without having to track each Lint release
– Tor
@Tor Norbye
You are absolutely correct about the workflow (command line lint and Jenkins plugin scraping the remains). The hard coded texts of the rules from the Jenkins plugin are the problem here. If you can make life easier for the plugin i would be all up for that.