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.
Related
I want to deployto WebLogic using groovy code inside Jenkins job pipeline.
Has anyone ever used a groovy code inside Jenkins job pipeline to deploy to WebLogic application? WebLogic version is 10.x.
I know how to do it with freestyle job and it works via plugin, but when I click on pipeline syntax, I don't see nothing from this plugin.
I have googled and googled, and nothing actually works or is not the scope of my needs and too complex to understand so I could addapt (using Java etc).
SOLVED: OK so I found a way and a way to make it work. Basically one can write a python (jython) code which can manage WebLogic with its built-in WLST scripting mechanism.
But to make everything work, one needs to:
generate wlfullclient.jar on your WebLogic machine: https://docs.oracle.com/cd/E12839_01/web.1111/e13717/jarbuilder.htm#SACLT239
Use the following steps to create a wlfullclient.jar file for a JDK 1.6 client application:
Change directories to the server/lib directory.
cd WL_HOME/server/lib
Use the following command to create wlfullclient.jar in the server/lib directory:
java -jar wljarbuilder.jar
You can now copy and bundle the wlfullclient.jar with client applications.
Add the wlfullclient.jar to the client application's classpath.
in order for this to work from other machine, without installing WebLogic to it, one needs additional .jar files, which can be found on WebLogic machine in some Weblogic folder e.g. C:\bea10\wlserver_10.3....
copy dependent .jar files to desired machine, create empty props.txt file and call your python script like this (in the command you will note which .jar files are also needed in classpath -cp). Dweblogic.home is where weblogic.jar is located. Note that if you gonna put those jars in environment classpath variable, you can NOT add a path to folder, since .jar and .zip files need to be targeted directly.
java -cp C:\Users\icami\Desktop\weblogic\wlfullclient.jar;C:\Users\icami\Desktop\weblogic\com.bea.core.xml.xmlbeans_2.2.0.0.jar;C:\Users\icami\Desktop\weblogic\com.oracle.cie.comdev_6.4.0.0.jar;C:\Users\icami\Desktop\weblogic\com.oracle.cie.config-wls-schema_10.3.6.0.jar;C:\Users\icami\Desktop\weblogic\com.oracle.cie.config-wls_7.2.0.0.jar;C:\Users\icami\Desktop\weblogic\com.oracle.cie.config_7.2.0.0.jar;C:\Users\icami\Desktop\weblogic\com.oracle.cie.wizard_6.1.0.0.jar;C:\Users\icami\Desktop\weblogic\com.oracle.core.weblogic.msgcat_1.2.0.0.jar;C:\Users\icami\Desktop\weblogic\jython.jar;C:\Users\icami\Desktop\weblogic\weblogic.jar -Dprod.props.file=C:\Users\icami\Desktop\weblogic\props.txt -Dbea.home= -Dweblogic.home=C:\Users\icami\Desktop\weblogic weblogic.WLST test.py
Example of a safe test.py, it only retreives state, listen address etc, doesn't change anything, feel free to run it:
username = 'weblogic'
password = 'weblogic'
URL='t3://weblogic.domain.com:7001'
connect(username,password,URL)
domainRuntime()
cd('ServerRuntimes')
servers=domainRuntimeService.getServerRuntimes()
for server in servers:
serverName=server.getName();
print '**************************************************\n'
print '############## ', serverName, '###############'
print '**************************************************\n'
print '##### Server State #####', server.getState()
print '##### Server ListenAddress #####', server.getListenAddress()
print '##### Server ListenPort #####', server.getListenPort()
print '##### Server Health State #####', server.getHealthState()
I have a groovy script that runs the command jenkins-cli create-job and uses an xml template to create a new maven job. In the template, I attempt to specify the owner using the jenkins ownership plugin, but this information is ignored. It appears that jenkins uses the default setting and sets the owner to the creator, which in this case is jenkins and thereby deployman. I'd like to somehow get around this and assign the proper own either by passing it on the command line or telling jenkins to ignore that default setting that sets the owner to the creator. Does anyone know how to do this?
Note: I have inspected the xml file passed on the command line and the config xml file of the new project in jenkins and run a diff between them. The only difference the the owner set to the wrong person.
https://wiki.jenkins-ci.org/display/JENKINS/Jenkins+CLI
Read "Working with Credentials" section.
Also you can validate who is logged in with following jenkins cli command.
who-am-i : Reports your credential and permissions
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.
Background
I have the following Jenkins config.
Ubuntu machine
Jenkins installed using apt-get, and is started as a service (service jenkins start).
To this point I have not made any modifications to Jenkins config.
We have several Ant projects for which I want to publish Javadocs using Jenkins.
After configuring the Javadoc plugin, I quickly hit this issue where only the Javadoc frames are displaying, without any content.
Some reading (here and here) told me that I need to configure Jenkins' Content Security Policy, and that this is done by modifying system properties passed to Jenkins.
However, despite digging around I have not found clear docs on how to pass these system properties to the Jenkins service. How do I do that?
Answering my own question.
To set system properties for the Jenkins service:
Steps
Stop Jenkins (service jenkins stop). You will need root privileges.
Edit the /etc/defaults/jenkins file.
Add an additional line for the JAVA_ARGS that you want to pass.
JAVA_ARGS="-Dhudson.model.DirectoryBrowserSupport.CSP=\"your CSP configuration here\""
Start Jenkins (service jenkins start).
Explanation
Look at /etc/init.d/jenkins for a line similar to:
NAME=jenkins
SCRIPTNAME=/etc/init.d/$NAME
[ -r /etc/default/$NAME ] && . /etc/default/$NAME
These tell us that the Jenkins daemon will look for a file named /etc/default/jenkins. If present, it .s that file.
If you set $JAVA_ARGS in /etc/default/jenkins it will be substituted in the line below, located later in the /etc/init.d/jenkins file:
$SU -l $JENKINS_USER --shell=/bin/bash -c "$DAEMON $DAEMON_ARGS -- $JAVA $JAVA_ARGS -jar $JENKINS_WAR $JENKINS_ARGS" || return 2
Notes
Even after you do the above, the Javadoc may not load properly. Try doing a hard refresh (Ctrl-Shift-R on Chrome).
As detailed in (the Jenkins docs)[https://wiki.jenkins-ci.org/display/JENKINS/Configuring+Content+Security+Policy] there is a temporary way to do this as well. Read that page and try to understand the implications well.
Changing the Content Security Policy has serious implications especially if your Jenkins is public. It's worth the effort to understand just what policies you are modifying.
I use a shell script to create/run doxygen doxyfile to document my code base
which works absolutely fine(Schedule runs and recursive scan code base also
works fine).
Now my requirement is to do the same job using Jenkins CI.
I added doxygen plug which generates documentation output and stores the result in Jenkin workspace.
My question, is there any another ways to run script and generate doxyfile in
Jenkins environment and also
How to create url link to display doxygen HTML output.
Have you seen the Jenkins DocLink plugin? This plugin makes it easy to put a link on your project page to documentation generated in a build.