Parses output from the Android lint tool and displays the results for analysis.
Android Lint is a tool which scans your Android projects and reports on potential bugs, performance, security and translation issues, plus more.
This Jenkins plugin parses XML reports produced by running lint, analyses them and displays the results for each build.
This plugin builds on the work of the static analysis core plugin; see the Static Code Analysis Plug-ins page for a fuller list of features.
If the Dashboard View plugin is also installed, you will be able to add Lint-specific portlets to your dashboard views.
Enable "Publish Android Lint results" in the "Post-build Actions" of your Jenkins job.
By default, the plugin will parse any files called "lint-results.xml", anywhere in your build's workspace.
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.
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.
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.
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).
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.
For best results, run Lint in your Android application's directory, e.g.:
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.
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.
Skip to end of metadata Go to start of metadata