Skip to content

Jenkins precommit target for gradle

Jenkins does a terrible job at managing job configuration. Sure, there is the JobConfigHistory Plugin, but this is weak and mostly exposes configuration management problems in Jenkins (why does a one line change create 4 versions?).

One easy trick to keep your Jenkins job clean, and make it easy for developers to understand what is being built, is to create a pseudo-target in Gradle. Then your regular source-control (git) can manage changes in case tools are added or changed. Here’s an example:

task jenkinsBuild () {
    group = "Jenkins"
    description = "Runs all targets the main pre-commit Jenkins job needs."

    dependsOn {[

This has tons of advantages: different branches can easily have different requirements, integrating a particular tool can be done easily without Jenkins testing to see if it is configured for old branches, etc.

For simple projects, simply relying on the Gradle check task may be sufficient. However, as the number of variants (build type + product flavor), you may not want the pre-commit Jenkins jobs to build all variants.

This technique applies to a setup where several Jenkins jobs that run different sets of checks in parallel. e.g. jenkinsFunctionalTest, jenkinsStaticAnalysis, jenkinsStressTest, etc.

In conclusion, moving much of the build decision logic into source control and out of Jenkins greatly simplifies traceability and configurability for your project.

Posted in Uncategorized.

Tagged with , , , , , , .

0 Responses

Stay in touch with the conversation, subscribe to the RSS feed for comments on this post.

You must be logged in to post a comment.