CODEWITHSUNDEEP
jenkinsjenkins-job-dsl
Sir Jane
Sir Jane

Reputation: 232

Jenkins JobDSL only builds half the job on Debian - no error thrown

I am migrating Jenkins from Windows to Debian. I have a JobDSL that works well on the Windows machine, but using it on Debian, it only builds some XML modules and fails to interpret most others, i.e. they appear as unconfigured fields/their nodes don't exist in the config.xml. The DSL is called from its own Jenkins job that only checks out the code and then calls the DSL from file. If something would go wrong, i.e. if the DSL would not find a plugin it should configure, the build would fail or become unstable, depending on what the error is.

However, the creating job finishes as 'SUCCESS', even though its DSL is translated into a wrong config.xml. This way, I can't figure out what went wrong.

On both systems, Jenkins is 1.596.2, the DSL Plugin is 1.32(Win)/1.34(Deb). I took care to install all Jenkins plugins the DSL needs.

Edit:I updated Groovy via the backports to 2.2.2, but no change to the DSL effect.

Does anyone know what might cause this?

Upvotes: 1

Views: 161

Answers (2)

Sir Jane
Sir Jane

Reputation: 232

While starting to extract a self-contained code example for my post, I found out that the effect seems to be caused by the archiveXunit module. When I omit it in the publishers section, everything works as expected. Including it causes weird interferences, e.g. to the SCM and Log Rotation modules.

Just as a side note, I upgraded Debian to Jessie in the meantime, because the groovy2 package (versions 2.x.x) was not supported in Wheezy, and installing it required some unnecessary gymnastics. I didn't even need to use the backports on Jessie. (I'm wondering if the combination of quickly-developing Jenkins and conservative Debian was a good choice in the first place, but I guess time will tell.)

So, yeah ... seems like a plugin issue to me. I also wrote to the plugin's mailing list, here. I'll keep investigating this.

Update:

It seems to be a plugin issue, but not from JobDSL, rather from a dependency between the xUnit and the JUnit plugin. I wanted to create a particularly slim setup and deactivated the JUnit plugin, figuring I had no Java builds or tests on my system ... Well: with xUnit activated, but not JUnit, the JobDSL fails in the above way. Activating JUnit makes this problem go away. Here is my description of the little xUnit bug in the Jenkins JIRA.

Upvotes: 1

serv-inc
serv-inc

Reputation: 38177

If your problem is due to an old groovy-version, you might be able to install a newer version via debian backports: (it is also described in this answer)

  1. add deb http://http.debian.net/debian wheezy-backports main (or another distribution like squeeze, you might just look at the other lines) to your /etc/apt/sources.list
  2. apt-get update as root (or via sudo)
  3. apt-get install -t wheezy-backports groovy (once again, replace wheezy if necessary)

The advantages of using apt-get to update are

  • it always keeps the versions up-to-date (when using backports), and
  • it installs system-wide, that is, for all users. As of the GVM homepage, this does not seem to be the case for GVM:

It will then create a .gvm/ folder in your home directory, and neatly install all candidates beneath it.

Upvotes: 1

Related Questions