Features

This Jenkins plugin parses XML reports produced by running lint, analyses them and displays the results for each build. Information shown includes a build summary, trend graphs, display of warnings in context, and dashboard portlets.

Configuration

Job configuration

Freestyle job configuration

By default, the plugin will parse any files matching the pattern "lint-results*.xml", anywhere in your build's workspace. This behaviour can be overridden by entering a filename or pattern, relative to the root of your build's workspace.

Pipeline job configuration

You can generate the required Pipeline syntax via the Snippet Generator by choosing the "androidLint: Publish Android Lint results" step, but some quick examples follow.

The most basic configuration is this, which will analyse any files in the workspace matching the default pattern **/lint-results*.xml:

androidLint()

To specify the filenames or pattern to search for, use the pattern parameter:

androidLint pattern: 'foo/bar/my-app_lint-results.xml'

To mark the build as unstable if there are more than 10 Lint warnings, and to mark the build as failed if there are more than 30 Lint warnings:

androidLint unstableTotalAll: '10', failedTotalAll: '30'

To mark the build as failed if any high-priority warnings were introduced since the last build:

androidLint failedNewHigh: '0'

Deprecated Pipeline syntax…

The syntax in this section is only required if you're using version 2.9 or older of the Pipeline Groovy Plugin, which was superseded in July 2016.

The most basic configuration is this, which will analyse any files in the workspace matching the default pattern **/lint-results*.xml:

step([$class: 'LintPublisher'])

To specify the filenames or pattern to search for, use the pattern parameter:

To mark the build as failed if any high-priority warnings were introduced since the last build:

step([$class: 'LintPublisher', failedNewHigh: '0'])

Producing Lint output

Note that this plugin does not run Lint for you — you must provide Lint results in XML format, either by running lint during a build, or by copying the file(s) from somewhere else.

Via Gradle

If you're using the Gradle build system for Android, as of version 0.7 of the Android Gradle plugin, Lint integration is built-in.

By default, running the lint Gradle task will generate the Lint XML file required by this plugin. However, you should disable the abortOnError option, to ensure that the Gradle script reports success, even if Lint finds issues with your project that it regards fatal.

You can do this by adding a lintOptions block at the end of your android block in your build.gradle file:

Running ./gradlew lint will compile your Android project, run Lint, and write the results to build/lint-results.xml. As mentioned in the section above, this plugin will automatically find and parse any files with this name.

If you run ./gradlew lintDebug, the file will be called lint-results-debug.xml — and the same pattern applies for other build variants (i.e. the lintRelease task creates lint-results-release.xml).

Via the command line

If you're not using Gradle or some other build tool which automates the execution of Lint, you will need to add an "Execute shell" build step to your Jenkins job where you run lint.

Note: When running Jenkins on a headless system, or under a user ID which doesn't have access to a graphical environment, you may see some errors while running Lint. To combat this, you can run Java in headless mode, as follows: os_opts="-Djava.awt.headless=true" lint --xml --fullpath lint-results.xml .

Changing build outcome based on Lint results

You can mark builds as unstable or failed, if the number of Lint issues found — or introduced in the latest build — exceeds a certain threshold.

e.g. A build can be automatically flagged as unstable or failed if any Lint issues with "Fatal" or "Error" severity are introduced.

To do this, in the job configuration, click "Advanced" in the "Publish Android Lint results" section. Under "Status thresholds" you can change the build to unstable (yellow ball) or failed (red ball). To mark a build as unstable if there are more than 10 Lint issues in total, but fail the build outright if even a single "Fatal"/"Error" issue exists, then enter "10" under "All priorities" in the yellow row, and "0" under "Priority high" in the red row.

i.e. If there are 12 normal-priority Lint issues found, this exceeds the threshold of 10, causing the build to be marked as unstable. Or, if there is a high-priority issue found, that would exceed the threshold of 0, thereby failing the build.

You should use this to be ruthless about fixing Lint issues as they occur, and remember that you can exclude false positives by setting up a lint.xml file in the root of your app project.

Can you add the Continuous Integration Game as an optional dependency to the Lint plugin? Then we can get a score when people add/remove lint errors.

From the CI Game wiki:

[quote]

Including rules in another plugin

You are a maintainer of a plugin and would like to add rules to the game with data from your plugin. To do this you should declare the game plugin as an optional dependency to your plugin. To create rules implement the interface Rule, and group them together in a RuleSet. To add a RuleSet to the game, add it to the game's RuleBook.hudson.plugins.cigame.PluginImpl.GAME_PUBLISHER_DESCRIPTOR.getRuleBook().addRuleSet(pluginruleset);

If there are already rules for your plugin in the game plugin, let me know so they can be removed from the plugin.

We use some small scripted logic to mark the build/stage as red after the androidLint step has run:

script { // Detect if Android Lint set the build to failed, and throw an error. // That will properly mark the stage as red in the UI to make clear what happened. if (currentBuild.result != 'SUCCESS') { error("Android Lint static checks failed") }}