All Projects → heremaps → gradle-jenkins-jobdsl-plugin

heremaps / gradle-jenkins-jobdsl-plugin

Licence: Apache-2.0 License
A plugin for Gradle to manage Jenkins Job DSL projects.

Programming Languages

groovy
2714 projects

Projects that are alternatives of or similar to gradle-jenkins-jobdsl-plugin

Autoarchive
一个基于Jenkins的iOS/Android自动构建系统,它实现了最大程度的自动化,让你的iOS自动打包,Android自动打包流程变得更加高效。此项目包含了各种实现细节的讲解说明,你能够使用它解决大多数跟客户端构建/分发相关的问题,并将这种能力进行开放,提高研发效率。
Stars: ✭ 248 (+416.67%)
Mutual labels:  jenkins, gradle
Nice Knowledge System
📚不积跬步无以至千里,每天进步一点点,Passion,Self-regulation,Love and Share
Stars: ✭ 137 (+185.42%)
Mutual labels:  jenkins, gradle
sphinx-gradle-plugin
Sphinx site generation plugin for Gradle
Stars: ✭ 19 (-60.42%)
Mutual labels:  gradle
gradle-localization-plugin
Gradle plugin for automating the download process of localization files.
Stars: ✭ 19 (-60.42%)
Mutual labels:  gradle
DexHelper
Gradle Plugin to analyze per-dex with Android assemble command.
Stars: ✭ 19 (-60.42%)
Mutual labels:  gradle
MicroServiceExample
针对微服务的各种例子实现
Stars: ✭ 25 (-47.92%)
Mutual labels:  gradle
evo-odas
Code Repository for the EVO-ODAS
Stars: ✭ 30 (-37.5%)
Mutual labels:  jenkins
microframeworks-showcase
A simple grocery list webapplication implemented with the Microframeworks Spark Java, Jodd, Ninja, Javalite, Pippo and Ratpack
Stars: ✭ 29 (-39.58%)
Mutual labels:  gradle
archi cloudnative
Cloud Native Architectural Models using Archi. Contains models for CAAS, Cloud Native Applications, 12/15 Factor Applications with CI/CD/CS, monitoring and log management. Infrastructure components include Red Hat OpenShift, Red Hat Storage, Red Hat Ansible Tower, Red Hat Cloudforms, Red Hat Satellite, Red Hat JBoss Middleware.
Stars: ✭ 55 (+14.58%)
Mutual labels:  jenkins
karibu10-helloworld-application
Karibu-DSL HelloWorld application in Vaadin 14
Stars: ✭ 14 (-70.83%)
Mutual labels:  gradle
gradle-nunit-plugin
A gradle plugin for launching NUnit tests
Stars: ✭ 17 (-64.58%)
Mutual labels:  gradle
Zucker
An easier way to automatically calculate the size of AAR in apk based on APP module
Stars: ✭ 76 (+58.33%)
Mutual labels:  gradle
EmbeddedTools
Additions to the model-based DSL for deploying Java and Native projects to remote targets
Stars: ✭ 14 (-70.83%)
Mutual labels:  gradle
bom
JENKINS-47498: allow plugin dependencies to be specified via BOM
Stars: ✭ 26 (-45.83%)
Mutual labels:  jenkins
jenkinsfile cookbook pipeline
Example Jenkinsfile and Explaination for Chef Cookbook Development
Stars: ✭ 36 (-25%)
Mutual labels:  jenkins
summary1
个人总结 持续更新 欢迎提出各种issues
Stars: ✭ 13 (-72.92%)
Mutual labels:  jenkins
MultiLamp
Android library to showcase/highlight the multiple views on same overlay
Stars: ✭ 235 (+389.58%)
Mutual labels:  gradle
chef-jenkins-hardening
⛔ DEPRECATED: A secure jenkins installation
Stars: ✭ 18 (-62.5%)
Mutual labels:  jenkins
parameterized-trigger-plugin
Jenkins parameterized-trigger plugin
Stars: ✭ 63 (+31.25%)
Mutual labels:  jenkins
gradle-build-info-plugin
Gradle plugin to include build information such as Git commit ID to your JAR. It can be used to show Git commit information with Spring Boot Actuator.
Stars: ✭ 33 (-31.25%)
Mutual labels:  gradle

Gradle Jenkins Job DSL Plugin

Linux Windows
Linux build status Windows build status

This is a plugin to manage Jenkins Job DSL projects in a Gradle project.

Contents

Usage

The plugin can be used to locally generate XML files for the jobs and to upload the generated jobs to a Jenkins instance.

Apply Plugin

To apply the plugin you need to add the necessary Maven repositories to the build script. The minimal build script looks like this:

buildscript {
    ext.jenkinsJobdslPluginVersion = '3.7.0'

    repositories {
        maven {
            url 'https://plugins.gradle.org/m2'
        }

        maven {
            url 'https://repo.jenkins-ci.org/releases/'
        }
    }

    dependencies {
        classpath("com.here.gradle.plugins:gradle-jenkins-jobdsl-plugin:${jenkinsJobdslPluginVersion}") {
            // Exclude unneeded transitive dependencies that can cause dependency resolution issues.
            exclude(module: 'bootstrap')
            exclude(module: 'groovy-all')
            exclude(module: 'org-netbeans-insane')

            // Exclude unneeded transitive dependencies on XML libraries that can break the generation of config files.
            // See: https://issues.jenkins-ci.org/browse/JENKINS-35638
            exclude(module: 'xalan')
            exclude(module: 'xercesImpl')
        }
    }
}

apply plugin: 'com.here.jobdsl'

repositories {
    maven {
        url 'https://plugins.gradle.org/m2'
    }
}

dependencies {
    compile 'org.codehaus.groovy:groovy-all:2.4.15'

    compile("com.here.gradle.plugins:gradle-jenkins-jobdsl-plugin:${jenkinsJobdslPluginVersion}") {
        exclude(module: 'org-netbeans-insane')
        exclude(module: 'xalan')
        exclude(module: 'xercesImpl')
    }
}

How does it work

To come as close as possible to the behaviour of a normal Job DSL seed job the plugin launches a Jenkins instance in the background and executes the Job DSL scripts inside of this Jenkins. This implementation enables support for the generated DSL and Job DSL extensions as described below.

To load plugins in this Jenkins instance they have to be added as dependencies to the jenkinsPlugins configuration:

dependencies {
    // Some Job DSL features only work when plugins are installed, for example cloudbees-folder is required
    // to be able to create folders (https://jenkinsci.github.io/job-dsl-plugin/#path/folder).
    jenkinsPlugins 'org.jenkins-ci.plugins:cloudbees-folder:6.2.1'
}

Known issues with plugins:

  • The org.jenkins-ci.plugins:ws-cleanup plugin has a dependency on an old version of jenkins-core. This adds some XML parser libraries to the classpath which conflict with the XML parser expected by newer Jenkins versions. As jenkins-core is provided anyway it should be excluded:
jenkinsPlugins('org.jenkins-ci.plugins:ws-cleanup:0.34') {
    exclude module: 'jenkins-core'
}

Writing Job DSL Scripts

By default all *.groovy files from src/jobdsl and its subdirectories are evaluated as Job DSL scripts. You can change the location by configuring the source set:

sourceSets {
    jobdsl {
        groovy {
            srcDirs 'myCustomSrcFolder'
        }
    }
}

Helper Classes

You can add Groovy or Java classes to the respective source directories src/main/groovy and src/main/java and use those classes in your Job DSL scripts, because they are automatically added to the classpath.

Job Builders

The recommended way to implement job templates are job builder classes. The plugin provides a basic JobBuilder class that can be extended to create templates. Below you can find an example of how to create a template that automatically enables the timestamp plugin for all jobs that use the template:

import com.here.gradle.plugins.jobdsl.util.JobBuilder
import javaposse.jobdsl.dsl.Job

class CustomJobBuilder extends JobBuilder {

    CustomJobBuilder(DslFactory dslFactory) {
        super(dslFactory)

        addDsl {
            wrappers {
                timestamps()
            }
        }
    }

}

To use the template you have to create an instance of your custom job builder class. You can add additional DSL code by passing it to the addDsl method. The builder will concatenate all closures and execute them in the order they were added when build is called. The JobBuilder provides convenience methods like addFreeStyleDsl or addMatrixdsl for each job type that optimize IDE support compared to using the generic addDsl method. You also have to set the job type by calling any of freestyleJob, matrixJob and so on. These methods optionally take a DSL closure argument for convenience.

def job = new CustomJobBuilder(
        dslFactory: this,
        name: 'MyExampleJob'
).freeStyleJob {

    description 'My example job'

    steps {
        shell('Hello World!')
    }
}

job.build()

Thirdparty Libraries

To use thirdparty libraries in your Job DSL scripts add them to the dependencies closure of the build script. For example the Job DSL plugin itself is added there to be able to use the JobBuilder class. This example shows how to add the Google Guava library:

dependencies {
    compile localGroovy()
    compile "com.here.gradle.plugins:gradle-jenkins-jobdsl-plugin:${jobDslPluginVersion}"
    compile 'com.google.guava:guava:19.0'
}

Generate XML

./gradlew dslGenerateXml

The XML files will be generated in build/jobdsl/.

Upload Jobs to Jenkins

# Upload jobs to a server without authorization
./gradlew dslUpdateJenkins --jenkinsUrl=http://localhost:8080/

# Upload jobs to a server with authorization
./gradlew dslUpdateJenkins --jenkinsUrl=http://localhost:8080/ --jenkinsUser=yourUsername --jenkinsApiToken=yourApiToken

# Do a dry run without changing any jobs
./gradlew dslUpdateJenkins --jenkinsUrl=http://localhost:8080/ --dryRun

Configure Servers

You can configure the different server you use in the build script instead of providing the configuration on the command line:

jobdsl {
    servers {
        localhost {
            jenkinsUrl = 'http://localhost:8080/'
        }

        staging {
            jenkinsUrl = 'http://your.jenkins.url:8080/'
            jenkinsUser = 'yourUsername'
            jenkinsApiToken = 'yourApiToken'
        }
    }
}

To use this configuration you have to select the server on the command line. You can override the configuration on the command line, e.g. when you don't want to put your credentials in the build script:

# Use the localhost configuration
./gradlew dslUpdateJenkins --server=localhost

# Override the user and API token from the configuration
./gradlew dslUpdateJenkins --server=staging --jenkinsUser=yourOtherUsername --jenkinsApiToken=yourOtherApiToken

If you want each team member to use their own credentials the gradle-credentials-plugin provides a nice way to let the team members store their credentials encrypted without having to put them in the build script or on the command line every time.

Seed Job

To create a seed job similar to the Job DSL seed jobs (see Using Job DSL) just create a freestyle job and run the Gradle command in a shell build step. Note that this will still use the REST API instead of the internal Jenkins API to create the jobs.

Since version 1.0.28 you can use the GroovySeedJobBuilder to create a seed job that runs in a System Groovy build step instead of using the REST API. This provides much better performance.

Custom Configuration

There are use cases where you want to change a part of your job configuration on the command line. For example you might want to create all jobs disabled on your localhost, and only enable them by default on your production Jenkins instance. For this the plugin supports a configuration map that is forwarded to the Job DSL scripts. The example below shows how to add a parameter to enable or disable all jobs:

jobdsl {
    configuration = [
        disableJobs: project.properties['disableJobs']?.toBoolean() ?: false
    ]
}

The values from the configuration map can be accessed from the Job DSL scripts by calling DslConfig.get('key'). The adapted build method of the CustomJobBuilder class looks like this:

@Override
Job build(Class<? extends Job> jobClass, @DelegatesTo(Job.class) Closure closure) {
    def job = super.build(jobClass, closure)
    job.with {
        disabled(DslConfig.get('disableJobs'))
    }
    return job
}

The configuration map is forwarded to the DSL scripts by serializing it to JSON, so only put values in it that can properly be serialized and deserialized by the JsonBuilder and JsonSlurper Groovy classes.

Now you can provide a value for the property on the command line to enable or disable your jobs. You can also provide a default value for the property in your gradle.properties file.

./gradlew -PdisableJobs=true dslGenerateXml

You can also have server specific configuration in the build.gradle file which can be accessed by calling DslConfig.get('key'):

jobdsl {
    servers {
        localhost {
            configuration: [ key: 'value' ]
        }
    }
}

Filter Jobs

To update only a part of the configured jobs the filter option can be used. It takes a regular expression as argument and only job names that match this expression are evaluated:

# Generate XML only for job names that contain "build"
./gradlew dslGenerateXml --filter=".*build.*"

# Only upload jobs from the folder "MyFolder"
# Note that /.* is put in brackets and made optional with a question mark, this makes sure that also the folder itself
# is uploaded. You could also use "^MyFolder.*", but in this case any item in the folder "MyFolder2" would also be
# uploaded.
./gradlew dslUpdateJenkins --filter="^MyFolder(/.*)?"

Generated DSL and Job DSL extensions

Job DSL has built-in support for many Jenkins plugins. Additionally there are two mechanisms that add support for plugins which are not directly supported:

  1. Generated DSL: This method uses annotations to discover configuration endpoints of plugins automatically and generates a DSL for them. This works for many plugins when they use the correct annotations.
  2. Job DSL Extensions: Plugins can also define their own DSL which is then available when the plugin is loaded by Jenkins.

Both mechanisms are supported by the gradle-jenkins-jobdsl-plugin. To use them the plugins have to be added to the jenkinsPlugins configuration:

dependencies {
    // This plugin defines a Job DSL extension.
    jenkinsPlugins 'org.jenkins-ci.plugins:jgiven:0.15.1'

    // This plugin is supported by the generated DSL.
    jenkinsPlugins 'org.jenkins-ci.plugins:cvs:2.13'
}

Development

Build the Plugin

To build the plugin execute:

# Only build
./gradlew plugin:assemble

# Publish to local maven repository (version will be 1.0)
./gradlew plugin:publishToMavenLocal

Test the Plugin

To run the tests of the plugin execute:

./gradlew plugin:check

Debugging the DSL tasks

To debug the tasks DslGenerateXml and DslUpdateJenkins using IntelliJ follow these steps:

  1. Uncomment these two lines in AbstractDslTask:
    //'-Xdebug',
    //'-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=5005'
  2. Create a test in GenerateXmlTest.groovy or UpdateJenkinsTest.groovy with the scenario you want to test (e.g. usage of specific plugins).
  3. Set a breakpoint in the run method of AbstractTaskRunner.groovy.
  4. Create a remote debug configuration in IntelliJ: Run -> Edit Configurations... -> + Remote
  5. Run the test on the command line: ./gradlew plugin:functionalTest --tests "com.here.gradle.plugins.jobdsl.tasks.GenerateXmlTest.name of your test"
  6. Start the remote debug configuration in IntelliJ.

Contributing

Contributions to the project are very welcome! Please be aware that you need to sign the HERE CLA if you want to contribute to the project.

Examples

The repository contains an example project that demonstrates most features of the plugin. To run it you have to deploy a build of the plugin to your local Maven repository first, as documented in "Build the Plugin" above.

Hints

Job DSL Plugin is not required

Because the gradle-jenkins-jobdsl-plugin can use the Jenkins REST API to upload jobs to Jenkins the Job DSL Plugin does not have to be installed on the Jenkins instance. This can be useful when you do not have permission to install Jenkins plugins or the plugin cannot be installed for another reason.

JobConfigHistory Plugin and seed jobs

If you use the JobConfigHistory Plugin in combination with a seed job you should configure retention for history entries in "Manage Jenkins" -> "Configure System". Otherwise you can quickly get a huge number of history entries which has a very negative impact on seed job performance and Jenkins performance in general.

Credits

The plugin was inspired by the following two projects, many thanks to their creators!

License

Copyright (c) 2016-2017 HERE Europe B.V.

See the LICENSE file in the root of this project for license details.

Note that the project description data, including the texts, logos, images, and/or trademarks, for each open source project belongs to its rightful owner. If you wish to add or remove any projects, please contact us at [email protected].