How can I apply a new Jenkins configuration as code YAML file from a groovy script, similar to clicking the "Apply new configuration" button in the UI.
I didn't try yet, but this looks as a feasible approach to me:
In the Jenkins home directory (/var/lib/jenkins on my Ubuntu installation) there is a file io.jenkins.plugins.casc.CasCGlobalConfig.xml. Edit that in order to provide a path/URL to your YAML file. On my system that file has the content like below, and I assume that just replacing the value of the <configurationPath> element with your yaml path should be sufficient.
<io.jenkins.plugins.casc.CasCGlobalConfig plugin="configuration-as-code#1569.vb_72405b_80249">
<configurationPath>/PATH/TO/MY/jenkins.casc.yaml</configurationPath>
</io.jenkins.plugins.casc.CasCGlobalConfig>
This configuration seems to be automatically applied each time when Jenkins is restarted.
In order to apply the configuration immediately, there seems to be jenkins-cli api for that. See the http://YOUR_JENKINS/manage/cli page and look for the reload-jcasc-configuration command, which suggests: java -jar jenkins-cli.jar -s http://YOUR_JENKINS/ -webSocket reload-jcasc-configuration
You ask for a "groovy script". With that I can't help, but I guess that modifying a file or running the jenkins-cli should be perfectly doable in a groovy script.
I have a freestyle jenkins job B which will run after the run of job A.
Now I choose:
Promote builds when...
Custom Groovy script
I check Groovy Sandbox and I define a simple groovy script.
When I try to save my job I got this error:
java.net.MalformedURLException: JENKINS-37599: empty classpath entries not allowed
I have to define a class path entry: JAR file path or URL
Definition:
A path or URL to a JAR file. This path should be approved by an
administrator or a user with the RUN_SCRIPT permission, or the script
fails. If the file or files are once approved, they are treated
approved even located in another path.
I really don't know to what file I have to point or what I have to do. Why isn't it just working when I check the sandbox?
This is a jenkins bug. It requires removing that Classpath entry every time before saving the job. I found a workaround, to set the value to any of the existing jars, like https://your-jenkins-host/jnlpJars/slave.jar. This won't affect script execution and won't require you to remember removing that stupid UI block every time you update your jenkins job config.
I had a similar issue and I clicked the red box with the white "X" to close that additional classpath window. I then saved the script.
I upgraded Jenkins today from 1.618 to 2.3. This included installing a whole bunch of plugins that it recommended (Mostly Pipeline plugins and their dependencies).
Since the upgrade, I get a new error (or, at least, a new unwanted behavior) any time a job kicks off another job. Any values passed to the child as "Predefined parameters" are ignored unless the child job already has those keys defined.
Let me illustrate: Let's say that I have a parent job and a child job.
Parent launches child through a "Trigger parameterized build on other projects" Post-build Action. In the definition of that Post-build Action, under the "Predefined parameters", I have FOO=BAR defined.
In Jenkins 1.618, when child was triggered this way, it would have FOO set as a parameter, with a value of BAR.
But in 2.3, FOO is not set on that build of child.
If I modify child so that FOO is always a parameter of that job, it will then pick up the FOO=BAR set from parent. This is an unacceptable work-around because we pass dozens of parameters this way, and defining them on both ends is too fragile and violates the "don't repeat yourself" principle.
I get the same results whether I'm triggering the child job through through the "Trigger parameterized build on other projects" Post-build Action or through a MultiJob Phase of a MultiJob project.
Is this an intended change? Was it broken before, and we were just using it incorrectly? Or is this a bug?
According to Jenkins 2 Security updates, you can bypass it by setting:
hudson.model.ParametersAction.keepUndefinedParameters=true
To validate this workaround, go to Manage Jenkins -> Script Console, and run:
System.setProperty("hudson.model.ParametersAction.keepUndefinedParameters", "true")
To make it permanent, change Jenkins arguments as follow (and restart Jenkins afterwards):
On Windows edit jenkins.xml in Jenkins home directory, for example:
<arguments>
-Xrs -Xmx256m -Dhudson.lifecycle=hudson.lifecycle.WindowsServiceLifecycle
-Dhudson.model.ParametersAction.keepUndefinedParameters=true
-jar "%BASE%\jenkins.war" --httpPort=8080
</arguments>
For most of the Linux distributions, you can modify JENKINS_ARGS inside file:
/etc/default/jenkins (or jenkins-oc)
For CentOS, modify JENKINS_JAVA_OPTIONS inside file:
/etc/sysconfig/jenkins (or jenkins-oc)
Here's a list of reported plugins, that were affected by the issue, and has an open bug already:
https://wiki.jenkins-ci.org/display/JENKINS/Plugins+affected+by+fix+for+SECURITY-170
There are some solutions
commabd line
java -Dhudson.model.ParametersAction.keepUndefinedParameters=true -jar jenkins.war
groovy
import jenkins.model.*;
System.setProperty("hudson.model.ParametersAction.keepUndefinedParameters", "true")
I couldn't find a Start-to-End answer on how to set this for a linux box. After a couple hours of cross-referencing guides, this is what ended up working. There are supposed to be a couple flavors of these Jenkins configurations. I'm using the Ubuntu flavor for this answer.
Get the Groovy scripting plugin
Discern where your $JENKINS_HOME is being set. By default, it's supposed to be at ~/.jenkins, but I didn't set this server up, so I had to go digging through some configuration files. In case you do too, this is what I had to do:
Check the contents of /etc/default/jenkins with vi to grab the value of $JENKINS_HOME -- mine was /var/lib/$NAME and further up the file, $NAME was set to jenkins, so it was /etc/libs/jenkins
Change directories to the $JENKINS_HOME path
Search for a directory called init.groovy.d -- if it doesn't exist, make one and then cd into it. You might have to use sudo if needing to make it
Create a new file in the init.groovy.d directory that ends in .groovy -- I just called mine params.groovy
Enter following script code into the groovy file we just made:
import jenkins.model.*;
System.setProperty("hudson.model.ParametersAction.keepUndefinedParameters", "true")
Save and Close, then reboot your Jenkins server.
That should unblock you, if you ran into the same problem I did. Your mileage may vary :) I ultimately used a start-up script to utilize that functionality in conjunction with this solution proposed by Jenkins.
I create a file in workspace for a specific type of branch during my compilation. If the file exists I want the change the built status to NOT_BUILT and skip the job.
How can I do it through post build groovy script.
The Groovy Postbuild plugin exposes a variable called manager which can be used to access Jenkins objects. See the plugin's wiki page for details.
To set the build result to NOT_BUILT, do this:
manager.build.result = hudson.model.Result.NOT_BUILT
Is it somehow possible so search for a module within all Jenkins jobs?
Let's say there's the module common-messaging. It's built in Job 1 and Job 2.
When I search for the module name I want both jobs to be shown.
Jenkins store the jobs configuration on disk in XML files. So you can grep the file for whatever XML element is created by the plugin.
create a new job that just have that plugin enabled.
get the XML file: /ci/job/name_of_your_job/config.xml
look for an XML element that correspond to common-messaging, lets say common-messaging.plugin
Then if using a UNIX system:
grep common-messaging.plugin /var/lib/jenkins/jobs/*/config.xml
Windows must have a similar command.
If you have admin access to the server, install the Scriptler plugin (which gives you more easy access to the Groovy console), and fetch and run this shared Scriptler snippet: http://scriptlerweb.appspot.com/script/show/486001