ghale / gradle-jenkins-plugin Goto Github PK

Possible solutions:

Upgrade http-builder with configuration option:
Upgrade to recent version of http-builder (0.7.1+) and adding a configuration option to tell the serviceFactory to apply ignoreSSLIssues().

Add configuration option without upgrading http-builder
Easy enough to implement your own method that does what ignoreSSLIssues() method does.

Provide easier way to customise the RESTClient
Iterating all the gradle-jenkins-plugin tasks and using a custom ServiceFactory is a lot of jiggery-pokery to have to do just to customise the HTTP connection.

This is the work-around I'm using in my buildscript at the moment:

buildscript {
  dependencies {
    classpath "com.terrafolio:gradle-jenkins-plugin:1.2.3"
  }

  // force recent version of http-builder so we can call ignoreSSLIssues()
  configurations.classpath.resolutionStrategy {
    eachDependency { details ->
      if( details.requested.name == "http-builder"){
        details.useVersion '0.7.2'
      }
    }
  }
}
....
project.tasks.each { task ->
  if( task instanceof AbstractJenkinsTask ){
    AbstractJenkinsTask jenkinsTask = (AbstractJenkinsTask) task
    jenkinsTask.serviceFactory = new JenkinsRESTServiceFactory() {
      @Override
      JenkinsService getService(String url, String username, String password) {
        def service = new JenkinsRESTServiceImpl(url, username, password)
        // ignoreSSLIssues() ignores problems with self-signed certificate
        // used by Jenkins server
        service.restClient.ignoreSSLIssues()
        return service
      }
    }
  }
}

Happy to provide a proper pull request if you're open to it.

I think it would be useful to add a continuous integration system to this project, if there isn't already one.

For a fast solution, I suggest to use Travis CI (http://docs.travis-ci.com/user/languages/java/#Projects-Using-Gradle) as it works well will Github and pull requests.

Would it be possible to be able to define a series of nested views in the dsl, for example if we wanted to model:

Nested View
| -> List View
| -> Build Pipeline View

Fixed dumpJenkinsJobs to use server filters, but jobs filters still doesn't work.

It'd be really awesome if this plugin offered some ease of Jenkins job testing (manual/integration/whathaveyou).

This plugin might have to add some tasks to:

• integrate with something like the Gradle Vagrant plugin or something with Docker
• install a set of Jenkins plugins on VM/container
• spin up instance of Jenkins from that VM/container
• update all views/jenkins jobs

It might help with integration (or acceptance) tests for this project too, which I noticed you're considering.

What do you think? Useful? Overkill?

you might have a single job deployed to two (or more) servers that needs a slightly different configuration on each server.

Credential prompting currently occurs whenever the first time a server is used. If you have a bunch of jobs that apply to one server and then a bunch of jobs that apply to another, it will prompt for the first server then go apply on all the jobs for that server before prompting for the next server credentials. Would be better if it did all the prompting up front.

I'm imagining something like this:

import com.terrafolio.gradle.plugins.jenkins.UpdateJenkinsJobsTask
...
task updateOnlyBuildJobs(type: UpdateJenkinsJobsTask) {
        jenkins.jobs.findAll { it.name.startsWith("Build") }.each { job ->
                update(job)
        }
}

When I try to use version 1.2.3 of the plugin, I receive:

~/jenkins-jobs (master)$ ./gradlew wrapper -s
Parallel execution is an incubating feature.
:buildSrc:compileJava UP-TO-DATE
:buildSrc:compileGroovy UP-TO-DATE
:buildSrc:processResources UP-TO-DATE
:buildSrc:classes UP-TO-DATE
:buildSrc:jar UP-TO-DATE
:buildSrc:assemble UP-TO-DATE
:buildSrc:compileTestJava UP-TO-DATE
:buildSrc:compileTestGroovy UP-TO-DATE
:buildSrc:processTestResources UP-TO-DATE
:buildSrc:testClasses UP-TO-DATE
:buildSrc:test UP-TO-DATE
:buildSrc:check UP-TO-DATE
:buildSrc:build UP-TO-DATE

FAILURE: Build failed with an exception.

* Where:
Build file '/home/sgoings/jenkins-jobs/build.gradle' line: 9

* What went wrong:
A problem occurred evaluating root project 'jenkins-jobs'.
> java.lang.IncompatibleClassChangeError (no error message)

* Try:
Run with --info or --debug option to get more log output.

* Exception is:
org.gradle.api.GradleScriptException: A problem occurred evaluating root project 'jenkins-jobs'.
    at org.gradle.groovy.scripts.internal.DefaultScriptRunnerFactory$ScriptRunnerImpl.run(DefaultScriptRunnerFactory.java:54)
    at org.gradle.configuration.DefaultScriptPluginFactory$ScriptPluginImpl.apply(DefaultScriptPluginFactory.java:190)
    at org.gradle.configuration.project.BuildScriptProcessor.execute(BuildScriptProcessor.java:39)
    at org.gradle.configuration.project.BuildScriptProcessor.execute(BuildScriptProcessor.java:26)
    at org.gradle.configuration.project.ConfigureActionsProjectEvaluator.evaluate(ConfigureActionsProjectEvaluator.java:34)
    at org.gradle.configuration.project.LifecycleProjectEvaluator.evaluate(LifecycleProjectEvaluator.java:55)
    at org.gradle.api.internal.project.AbstractProject.evaluate(AbstractProject.java:521)
    at org.gradle.api.internal.project.AbstractProject.evaluate(AbstractProject.java:82)
    at org.gradle.configuration.DefaultBuildConfigurer.configure(DefaultBuildConfigurer.java:31)
    at org.gradle.initialization.DefaultGradleLauncher.doBuildStages(DefaultGradleLauncher.java:129)
    at org.gradle.initialization.DefaultGradleLauncher.doBuild(DefaultGradleLauncher.java:106)
    at org.gradle.initialization.DefaultGradleLauncher.run(DefaultGradleLauncher.java:86)
    at org.gradle.launcher.exec.InProcessBuildActionExecuter$DefaultBuildController.run(InProcessBuildActionExecuter.java:80)
    at org.gradle.launcher.cli.ExecuteBuildAction.run(ExecuteBuildAction.java:33)
    at org.gradle.launcher.cli.ExecuteBuildAction.run(ExecuteBuildAction.java:24)
    at org.gradle.launcher.exec.InProcessBuildActionExecuter.execute(InProcessBuildActionExecuter.java:36)
    at org.gradle.launcher.exec.InProcessBuildActionExecuter.execute(InProcessBuildActionExecuter.java:26)
    at org.gradle.launcher.daemon.server.exec.ExecuteBuild.doBuild(ExecuteBuild.java:47)
    at org.gradle.launcher.daemon.server.exec.BuildCommandOnly.execute(BuildCommandOnly.java:34)
    at org.gradle.launcher.daemon.server.exec.DaemonCommandExecution.proceed(DaemonCommandExecution.java:125)
    at org.gradle.launcher.daemon.server.exec.WatchForDisconnection.execute(WatchForDisconnection.java:35)
    at org.gradle.launcher.daemon.server.exec.DaemonCommandExecution.proceed(DaemonCommandExecution.java:125)
    at org.gradle.launcher.daemon.server.exec.ResetDeprecationLogger.execute(ResetDeprecationLogger.java:24)
    at org.gradle.launcher.daemon.server.exec.DaemonCommandExecution.proceed(DaemonCommandExecution.java:125)
    at org.gradle.launcher.daemon.server.exec.StartStopIfBuildAndStop.execute(StartStopIfBuildAndStop.java:33)
    at org.gradle.launcher.daemon.server.exec.DaemonCommandExecution.proceed(DaemonCommandExecution.java:125)
    at org.gradle.launcher.daemon.server.exec.ReturnResult.execute(ReturnResult.java:34)
    at org.gradle.launcher.daemon.server.exec.DaemonCommandExecution.proceed(DaemonCommandExecution.java:125)
    at org.gradle.launcher.daemon.server.exec.ForwardClientInput$2.call(ForwardClientInput.java:71)
    at org.gradle.launcher.daemon.server.exec.ForwardClientInput$2.call(ForwardClientInput.java:69)
    at org.gradle.util.Swapper.swap(Swapper.java:38)
    at org.gradle.launcher.daemon.server.exec.ForwardClientInput.execute(ForwardClientInput.java:69)
    at org.gradle.launcher.daemon.server.exec.DaemonCommandExecution.proceed(DaemonCommandExecution.java:125)
    at org.gradle.launcher.daemon.server.exec.LogToClient.doBuild(LogToClient.java:60)
    at org.gradle.launcher.daemon.server.exec.BuildCommandOnly.execute(BuildCommandOnly.java:34)
    at org.gradle.launcher.daemon.server.exec.DaemonCommandExecution.proceed(DaemonCommandExecution.java:125)
    at org.gradle.launcher.daemon.server.exec.EstablishBuildEnvironment.doBuild(EstablishBuildEnvironment.java:70)
    at org.gradle.launcher.daemon.server.exec.BuildCommandOnly.execute(BuildCommandOnly.java:34)
    at org.gradle.launcher.daemon.server.exec.DaemonCommandExecution.proceed(DaemonCommandExecution.java:125)
    at org.gradle.launcher.daemon.server.exec.StartBuildOrRespondWithBusy$1.run(StartBuildOrRespondWithBusy.java:45)
    at org.gradle.launcher.daemon.server.DaemonStateCoordinator.runCommand(DaemonStateCoordinator.java:258)
    at org.gradle.launcher.daemon.server.exec.StartBuildOrRespondWithBusy.doBuild(StartBuildOrRespondWithBusy.java:49)
    at org.gradle.launcher.daemon.server.exec.BuildCommandOnly.execute(BuildCommandOnly.java:34)
    at org.gradle.launcher.daemon.server.exec.DaemonCommandExecution.proceed(DaemonCommandExecution.java:125)
    at org.gradle.launcher.daemon.server.exec.HandleCancel.execute(HandleCancel.java:36)
    at org.gradle.launcher.daemon.server.exec.DaemonCommandExecution.proceed(DaemonCommandExecution.java:125)
    at org.gradle.launcher.daemon.server.exec.HandleStop.execute(HandleStop.java:30)
    at org.gradle.launcher.daemon.server.exec.DaemonCommandExecution.proceed(DaemonCommandExecution.java:125)
    at org.gradle.launcher.daemon.server.exec.DaemonHygieneAction.execute(DaemonHygieneAction.java:39)
    at org.gradle.launcher.daemon.server.exec.DaemonCommandExecution.proceed(DaemonCommandExecution.java:125)
    at org.gradle.launcher.daemon.server.exec.CatchAndForwardDaemonFailure.execute(CatchAndForwardDaemonFailure.java:32)
    at org.gradle.launcher.daemon.server.exec.DaemonCommandExecution.proceed(DaemonCommandExecution.java:125)
    at org.gradle.launcher.daemon.server.exec.DefaultDaemonCommandExecuter.executeCommand(DefaultDaemonCommandExecuter.java:52)
    at org.gradle.launcher.daemon.server.DefaultIncomingConnectionHandler$ConnectionWorker.handleCommand(DefaultIncomingConnectionHandler.java:154)
    at org.gradle.launcher.daemon.server.DefaultIncomingConnectionHandler$ConnectionWorker.receiveAndHandleCommand(DefaultIncomingConnectionHandler.java:128)
    at org.gradle.launcher.daemon.server.DefaultIncomingConnectionHandler$ConnectionWorker.run(DefaultIncomingConnectionHandler.java:116)
    at org.gradle.internal.concurrent.DefaultExecutorFactory$StoppableExecutorImpl$1.run(DefaultExecutorFactory.java:64)
Caused by: java.lang.IncompatibleClassChangeError
    at com.terrafolio.gradle.plugins.jenkins.jobdsl.MapJobManagement.<init>(MapJobManagement.groovy:21)
    at com.terrafolio.gradle.plugins.jenkins.jobdsl.MapJobManagement.<init>(MapJobManagement.groovy)
    at com.terrafolio.gradle.plugins.jenkins.JenkinsPlugin.applyConventions(JenkinsPlugin.groovy:51)
    at com.terrafolio.gradle.plugins.jenkins.JenkinsPlugin$applyConventions$0.callCurrent(Unknown Source)
    at com.terrafolio.gradle.plugins.jenkins.JenkinsPlugin.apply(JenkinsPlugin.groovy:17)
    at com.terrafolio.gradle.plugins.jenkins.JenkinsPlugin.apply(JenkinsPlugin.groovy)
    at org.gradle.api.internal.plugins.DefaultPluginContainer.providePlugin(DefaultPluginContainer.java:188)
    at org.gradle.api.internal.plugins.DefaultPluginContainer.addPluginInternal(DefaultPluginContainer.java:137)
    at org.gradle.api.internal.plugins.DefaultPluginContainer.apply(DefaultPluginContainer.java:103)
    at org.gradle.api.internal.plugins.DefaultObjectConfigurationAction.applyPlugin(DefaultObjectConfigurationAction.java:115)
    at org.gradle.api.internal.plugins.DefaultObjectConfigurationAction.access$200(DefaultObjectConfigurationAction.java:36)
    at org.gradle.api.internal.plugins.DefaultObjectConfigurationAction$3.run(DefaultObjectConfigurationAction.java:80)
    at org.gradle.api.internal.plugins.DefaultObjectConfigurationAction.execute(DefaultObjectConfigurationAction.java:131)
    at org.gradle.api.internal.project.AbstractPluginAware.apply(AbstractPluginAware.java:37)
    at org.gradle.api.Project$apply$2.call(Unknown Source)
    at org.gradle.api.internal.project.ProjectScript.apply(ProjectScript.groovy:34)
    at org.gradle.api.Script$apply.callCurrent(Unknown Source)
    at build_6t6c8gb2icejq2aiab9e1gjmdk.run(/home/sgoings/jenkins-jobs/build.gradle:9)
    at org.gradle.groovy.scripts.internal.DefaultScriptRunnerFactory$ScriptRunnerImpl.run(DefaultScriptRunnerFactory.java:52)
    ... 56 more

This does not happen on 1.2.2.

As I can't figure out how to contact Gary to just ask a question, I guess I'll file an issue to ask this question. Perhaps this will be a common question.

This Gradle plugin provides the ability to create jobs, and properties of those jobs. The GradleWare presentation demonstrated very simple property settings. In Jenkins, when additional Jenkins plugins are installed, you have the ability to add additional configuration that is specific to the plugin.

Will this Gradle plugin provide any convenience for setting those plugin-specific properties in each job?

I'm going to guess that the Gradle plugin is NOT able to script the installation or removal of Jenkins plugins themselves. I had trouble finding a concise description of the Jenkins REST API, but I didn't find any mention of being able to configure this, and I assume the Gradle plugin is just using that API to do its work.

Server-specific overrides operate on the job definition so they won't handle dsl closures (which operate on the job object). For example, the following won't work:

jobs {
  test_job {
    server test_server, {
      dsl { ... }
    }
  }
}

Does anyone know how to configure the credentials for a Subversion repository using DSL?
We are using the Jenkins Credentials Plugin.

When I run updateJenkinsItems it currently clears the credentials selected, because I don't have them configured in build.gradle.

Assuming that a build script contains something like

views {
        "someName" {
            dsl {
                        }
                }
}

under Gradle 2.4 this will cause an exception similar to below

Caused by: groovy.lang.MissingMethodException: No signature of method: java.util.LinkedHashSet.sort() is applicable for argument types: (java.lang.String$CaseInsensitiveComparator) values: [java.lang.String$CaseInsensitiveComparator@723877dd]
Possible solutions: sort(), sort(groovy.lang.Closure), sort(boolean), sort(groovy.lang.Closure), sort(boolean, groovy.lang.Closure), sort(boolean, java.util.Comparator)
        at javaposse.jobdsl.dsl.views.ListView$_jobs_closure2_closure5.doCall(ListView.groovy:33)
        at javaposse.jobdsl.dsl.views.ListView$_jobs_closure2_closure5.doCall(ListView.groovy)
        at javaposse.jobdsl.dsl.MissingPropertyToStringDelegate.methodMissing(MissingPropertyToStringDelegate.groovy:39)
        at javaposse.jobdsl.dsl.MissingPropertyToStringDelegate.invokeMethod(MissingPropertyToStringDelegate.groovy)
        at javaposse.jobdsl.dsl.views.ListView$_jobs_closure2.doCall(ListView.groovy:31)
        at javaposse.jobdsl.dsl.WithXmlAction$_execute_closure1.doCall(WithXmlAction.groovy:18)
        at javaposse.jobdsl.dsl.WithXmlAction$_execute_closure1.doCall(WithXmlAction.groovy)
        at javaposse.jobdsl.dsl.WithXmlAction.execute(WithXmlAction.groovy:17)
        at javaposse.jobdsl.dsl.WithXmlAction$execute.call(Unknown Source)
        at javaposse.jobdsl.dsl.View$_getNode_closure5.doCall(View.groovy:58)
        at javaposse.jobdsl.dsl.View.getNode(View.groovy:58)
        at javaposse.jobdsl.dsl.View.getProperty(View.groovy)
        at javaposse.jobdsl.dsl.View.getXml(View.groovy:50)
        at javaposse.jobdsl.dsl.View.getProperty(View.groovy)
        at com.terrafolio.gradle.plugins.jenkins.dsl.ViewDSLSupport.evaluateDSL(ViewDSLSupport.groovy:45)
        at com.terrafolio.gradle.plugins.jenkins.dsl.DSLSupport$evaluateDSL$0.call(Unknown Source)
        at com.terrafolio.gradle.plugins.jenkins.dsl.JenkinsView.dsl(JenkinsView.groovy:76)

The exception is thrown from javaposse, but is it posssible that what the plugin is passing down could be different under Gradle 2.4?

Is it possible to create a new release which will use the newest version 1.30 of job-dsl-plugin? Currently 1.25 is used. It is importnat because of this fix jenkinsci/job-dsl-plugin#312

Without it it is not possible for example to create views like this:

"view_name" {
  dsl {
    jobs {
      regex "some regex"
    }
  }
}

In order to do it the version 1.12 of gradle must be used where 2.3 is already there.

I am getting Unsupported major.minor version 51.0 as from 1.1.0 -> 1.2.3. with JDK 1.7.0_51.

I have checked build.gradle and it does have a sourceCompability or targetCompatibility set. It might be useful to set it to 1.7.

Have noticed a problem when you define a server URL like this...
'http://myserver:8080/jenkins'

that the RESTful calls to the server ignore the last part of the URL,
so they are making calls to http://myserver:8080/createItem?name=myJob
instead of http://myserver:8080/jenkins/createItem?name=myJob

Since we support both jobs and views now, it makes sense to refactor the task names from "updateJenkinsJobs" to "updateJenkinsItems", "dumpJenkinsJobs" to "dumpJenkinsItems", etc.

http-builder has a dependency on groovy, which pulls in an older version of asm, which breaks the tests on gradle > 1.1. Just pulling the superfluous groovy dependency out seems to neatly fix the issue:

compile('org.codehaus.groovy.modules.http-builder:http-builder:0.5.2') {
exclude(module: 'groovy')
}

Hi
I would like to use my job dsl files using the jenkins plugin and using the gradle plugin.

Using ${variable} it is possible to access a jenkins environment variable.
This as well is possible using the gradle plugin.

Is there a common way to check for undefined variables. I tried System.getenv(), System.getProperty() and hasProperty(). None of these approaches seems to work in both cases.

because of the way password prompting works, it prompts when running dumpJenkinsJobs, even though that task never touches the server (and so doesn't need passwords)

It is putting in <credentialsId>null</credentialsId> into the config file when I use the dsl credentials('description')

I'm just looking at the code to try and understand, I'm guessing it's because of the local JobManagement class MapJobManagement which has no idea about the server's credentials and just returns null from getCredentialsId. I'm not sure if there is a rest api for the credentials that can be called but I could probably live with just passing in the ID in place of the description if that would work.

In my gradle build I use the

    dsl fileTree('scripts').include('*.dsl')

method to include the dsls of jobs. Now the issue I'm facing is that I cannot reach the properties defined on the project like I would if I inlined the job.

What is the method of passing an environment to the dsl files?

Right now each job evaluates dsl and xml blocks and immediately serializes to xml during the configuration phase. We should look at lazy evaluating the xml sometime after the configuration phase but before the first update occurs. That is, we don't want to uncover a syntax error in the configuration of job 3 after jobs 1 and 2 have already been updated. We also need to be careful about evaluating more than once as some of the jenkins-job-dsl commands will add multiple xml nodes.

see MapJobManagement.

The job-dsl-plugin seems to require a properly set jenkins version in newer versions of the plugin. For example, the archiveArtifacts block requires this to evaluate properly (see https://github.com/jenkinsci/job-dsl-plugin/blob/ac9244d256ed7b856fb3b044ceab169b32662f85/job-dsl-core/src/main/groovy/javaposse/jobdsl/dsl/helpers/publisher/PublisherContext.groovy )

It would be nice to make the Jenkins version number configurable on the Gradle Jenkins Plugin. A new task to check if configured an actual versions match could also be helpful.

For now, I hacked around the issue with...

jobManagement.metaClass.getJenkinsVersion = { new hudson.util.VersionNumber('1.592') }

There is currently support for dumping remote jobs that are defined in the gradle configuration model, but not for remote jobs that are configured in jenkins but not defined in gradle at all. There should be a task (say "dumpAllRemoteJenkinsItems") that dumps all jobs on a remote instance. This would probably involve adding a "listConfigurations" method to the JenkinsService interface and sub-classing DumpRemoteJenkinsItems.

Chance this could be environmental, but when I dump my configuration, the xml files contain line breaks around the element value. When using these files to upload, Jenkins throws a NumberFormatException as a result:

---- Debugging information ----
message             : For input string: "
        0
      "
cause-exception     : java.lang.NumberFormatException
cause-message       : For input string: "
        0
      "
class               : hudson.model.FreeStyleProject
required-type       : java.lang.Integer
path                : /project/properties/hudson.plugins.throttleconcurrents.ThrottleJobProperty/maxConcurrentPerNode
line number         : 13
-------------------------------

I don't know if this is at all possible, but it would be nice to add "dependencies" for certain Jenkins CI plugins.
Then, when updating the jobs, it should check if these plugins are installed and install them if they are not yet present.

We are thinking about using this plugin and Gradle to setup new projects.
This way configuring a new build server would be easier than ever (just run a single Gradle task and you're good to go).

If you define a job definition and then try to configure the definition again later using a closure it will rewrite, rather than update, the definition:

jenkins {
  jobs {
    myjob {
      definition {
        //some defnition
      }
    }
  }
}
...
jenkins.jobs.myjob.definition {
  //some further configuration
}

This results in the definition being overwritten. On the other hand, the following would work:

jenkins.jobs.myjob,definition.xml override {
  // some override
}

Because it doesn't use the closure for the definition.

It would be useful to see the changes that a delete or update command would do against the servers.

So, I have in mind the following new tasks:

• dumpRemoteJenkinsItems: for each defined job and view, dump the relative xml to the folder "$buildDir/remote//<job|view>/.xml"
• diffJenkinsItems (dependsOn: dumpRemoteJenkinsItems, dumpJenkinsJobs): start a configurable external program to see differences in each configuration file.

What do you think about it?

I couldn't find this functionality documented on the wiki. Any plans to make folders a first class citizen as done with the groovy-job-dsl, supporting folders in the name property and folder creation/deletion?

These two jenkins dsl plugins are phenomenal, thanks for the hard work.

I am getting a Bad Request on CloudBees Jenkins. ContinuousDelivery folder exists but the test job I am trying to create does not.

10:50:30.581 [DEBUG] [org.apache.http.impl.conn.DefaultClientConnection] Sending request: >POST /job/ContinuousDelivery/createItem HTTP/1.1
10:50:30.583 [DEBUG] [org.apache.http.headers] >> POST /job/ContinuousDelivery/createItem >HTTP/1.1
10:50:30.584 [DEBUG] [org.apache.http.headers] >> Accept: /
10:50:30.585 [DEBUG] [org.apache.http.headers] >> Content-Length: 588
10:50:30.587 [DEBUG] [org.apache.http.headers] >> Content-Type: application/xml

    def defaultServiceOverrides = { folder, jobName ->
        return {
            create = ["uri": "/job/${folder}/createItem"]
            update = ["uri": "/job/${folder}/job/${jobName}/config.xml"]
            get = ["uri": "/job/${folder}/job/${jobName}/config.xml"]
            delete = ["uri": "/job/${folder}/job/${jobName}/doDelete"]
        }
    }

    jobs {
        build {
            def folder = "ContinuousDelivery"
            server servers.production

            dsl {
                name "Test Job Created From Gradle"
            }
            serviceOverrides defaultServiceOverrides(folder, "Test Job Created From Gradle")
        }
    }

I can create jobs at the root using the gradle plugin

Passing a working config.xml instead of using the dsl builder, throws the same bad request

Using a REST client, I have verified https://XXXX.ci.cloudbees.com/job/ContinuousDelivery/createItem?name=TestJob with the same config.xml in the postbody is working

Provide a way to customize the validation messages. This is mainly so that you can suppress the "no difference" messages if you wanted. We'd pass in the item, the xml diff object and the server object.

I'm thinking something like:

validateJenkinsJobs {
  differenceMessage = { item, xmlDiff, server ->
    "DIFF: ${item.name} is different on ${server.name}!"
  }
  matchMessage = { item, xmlDiff, server ->
    return null
  }
}

The plugin worked fine until today. With Jenkins 1.535, I started getting exception when creating new job:

Caused by: java.lang.NullPointerException: Cannot get property 'success' on null object
at org.codehaus.groovy.runtime.NullObject.getProperty(NullObject.java:56)
at org.codehaus.groovy.runtime.InvokerHelper.getProperty(InvokerHelper.java:156)
at org.codehaus.groovy.runtime.callsite.NullCallSite.getProperty(NullCallSite.java:44)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callGetProperty(AbstractCallSite.java:227)
at com.terrafolio.gradle.plugins.jenkins.JenkinsRESTServiceImpl.createJob(JenkinsRESTServiceImpl.groovy:111)
at com.terrafolio.gradle.plugins.jenkins.JenkinsService$createJob.call(Unknown Source)

Is it Jenkins API change?

There's been a lot of evolution since the tests were first written and later tests have just fallen in line with the original style. They're nasty and should be refactored to use a framework like Spock (for all the good reasons that test frameworks exist).

It is a good feature to create a view from Gradle and put the jobs into the view.

It currently takes about 5 minutes to update Jenkins jobs for me using this plugin (I'm generating about 60 jobs). I'm assuming most of the performance hit comes via the web requests to my Jenkins instance (even though it's on an internal network).

Could a threadpool (or something similar) be added to speed up this process to avoid running through every update in serial?

I am looking to move our jobs into Folders using the Jenkins Enterprise Folders plugin (from CloudBees). This is so we can have role based access control on the jobs (RBAC, another Enterprise Jenkins feature). But this will break our Gradle scripts using gradle-jenkins-plugin to maintain the jobs since the paths to POST to for create / update jobs will be different in this case. With folders, create and update of jobs looks like this:

curl -X POST "http://user:password@jenkins-server/job/FolderName/createItem?name=JobName" --data-binary "@job-new.xml" -H "Content-Type: text/xml"

curl -X POST "http://user:password@jenkins-server/job/FolderName/job/JobName/config.xml" --data-binary "@job-update.xml" -H "Content-Type: text/xml"

Then I need to be looking to create and update the folders, which is done like this:

curl -X POST "http://user:password@jenkins-server/createItem?name=FolderName" --data-binary "@folder-new.xml" -H "Content-Type: text/xml"

curl -X POST "http://user:password@jenkins-server/job/FolderName/config.xml" --data-binary "@folder-update.xml" -H "Content-Type: text/xml"

I was looking in the source code JenkinsRESTServiceImpl.groovy to see if I could fake job create / update up by embedding the folder path in the job name, but it looks like the create & get cases will not support this. I shall probably have to look to doing REST calls directly in our gradle scripts to sort this out, but if gradle-jenkins-plugin could support Folders in the future it would be great!

--Bill

There were some nice commands added (particularly criticalBlock())that I'd like to start using

Hi -

Should the dumpJenkinsJobs task be dumping server specific configs like the updateJenkinsJobs one does? I am comparing DumpJenkinsJobsTask.groovy to UpdateJenkinsJobsTask.groovy and it does not make any use of getServerSpecificDefinition() like the second one does. Maybe I am missing something..

Nice plugin!

--Bill

Can build pipeline views only be define by external dsl files when called like this:

apply plugin: 'com.terrafolio.jenkins'

jenkins {
    servers {
        testing {
            url 'http://localhost:8081'
            secure false
        }
    }

    defaultServer servers.testing // required

    dsl {
        job {
            name "job1"
        }
    }

    def dslFile = project.file('view.dsl')

    views {
        "project-A" {
            dsl dslFile
        }
    }
}

i have been unable to create a build pipeline view directly through the dsl in the build.gradle file.

I'm hoping im just doing something silly :)

When using the https://wiki.jenkins-ci.org/display/JENKINS/JobConfigHistory+Plugin and making changes with manual steps and gradle-jenkins-plugin I get the configuration history showing differences for each line of the file due to the xml nodes order. It makes the job history completely useless.

This problem can be solved by ordering the XML generated by the plugin with the same order that Jenkins use when saving.

At the moment, this issue should have a very low priority, as I don't know how many users are using the JobConfigHistory plugin.

I've been using the latest version of your plugin, 1.1.0.

I recently upgraded my Jenkins install from v1.534 to 1.569. I can create items, delete items, dump items. However since the upgrade, it seems I can no longer update an existing job. For example I can run updateJenkinsItems on a set of non-existing jobs and they are created just fine. However when I run the same script again I get the following error:

[Fatal Error] :-1:-1: Premature end of file.
Error parsing 'text/xml' response
org.codehaus.groovy.runtime.InvokerInvocationException:
org.xml.sax.SAXParseException; Premature end of file.
    at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:97)
    at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:233)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1047)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:914)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:877)
    at groovy.lang.Closure.call(Closure.java:412)
    at groovy.lang.Closure.call(Closure.java:425)
    at groovyx.net.http.HTTPBuilder.parseResponse(HTTPBuilder.java:561)
    at groovyx.net.http.HTTPBuilder.doRequest(HTTPBuilder.java:494)
    at groovyx.net.http.RESTClient.post(RESTClient.java:140)
    at groovyx.net.http.RESTClient$post.call(Unknown Source)
    at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:42)
    at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:108)
    at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:116)
    at com.terrafolio.gradle.plugins.jenkins.service.JenkinsRESTServiceImpl.restServicePOST(JenkinsRESTServiceImpl.groovy:50)

This seems quite consistent, only updating existing jobs fail.

As an alternative to the Job DSL and raw XML configuration options, it might be nice to support defining jobs as YAML and integrating with the YAML Project Plugin developed at Google.

https://wiki.jenkins-ci.org/display/JENKINS/YAML+Project+Plugin

I'm the author of a Jenkins Job DSL + Gradle plugin here:

https://github.com/ReadyTalk/gradle-plugins (jenkins-job-dsl)

The plugin allows you to use the Jenkins Job DSL (https://github.com/jenkinsci/job-dsl-plugin/wiki) to create job configurations (in xml)... but locally. The way it's being used internally at ReadyTalk is to make it easy to create the xml configurations and test both Groovy code and XML. Using Gradle gives us great benefits to pull in other dependencies for compiling parts of the DSL and testing it.

I've posted part of my vision here:
https://groups.google.com/forum/#!topic/job-dsl-plugin/r-RI0ouZXCU

It seems like if we combine efforts... we can get something even fancier for both our (and a bunch of others') needs. I'd be willing to help out. Thoughts?

This is a great plugin. I've just started to explore using it. In the spirit of convention over configuration and keeping build files small I wonder if you could modify the plugin to not require the name field for a JobDefinition. If not supplied, it would default to the the name of the job itself.

Thanks again for this great plugin.

Doug

Jobs on my Jenkins become outdated automatically (for yet unknown reason). Similarly, when I save a freshly deployed job (deployed using 'updateJenkinsItems') manually, the config.xml is extended with a new attribute 'plugin=name@version' for each xml node that is coming from a Jenkins plugin. I think this makes my jobs outdated when I next call updateJenkinsItems. But my problem is that I do not save the jobs manually, they just become re-saved somehow from time to time. And many random jobs (sometimes all of them in just one day) are re-genenerated the next time updateJenkinsItems is executed. This is happening in a continuous delivery pipeline.

It would not be a big problem, but job regeneration triggers another Jenkins bug, namely if a Maven job is running, its test results are sometimes not collected by Jenkins. Showing 'no tests', although the log shows that tests did run correctly. So this is why job re-generation bothers me (and especially the developers).

Is there any way to ignore the 'plugin' attribute when checking whether a job is up-to-date or not?
Thanks!