Hi I need some help in overriding the user.home property of ant from Jenkins. I created a simple job on jenkins that runs a build script on a slave machine of the master. One of the tasks of the scripts is to use the user.home property of ant and access certain files. The problem is that when I try to echo this property from the command line of the slave machine, I see C:\Users\Administrator but when I run the exact the same script from the Jenkins server I see C:\ . This difference is causing the build to fail on Jenkins. Can anyone please tell me what is the reason for this difference? Is there any way I can override this?
I tried having a property called user.home in the config file of my job but it doesn't seem to pick it up. Another interesting point is that when I changed the user.home value to some gibberish in the config file and run ant from command line on the slave, it still picks it up as C:\Users\Administrator
I am using ant 1.7.1 and Jenkins 1.598
You likely have jenkins running as a different ID than Administrator. Which is a good thing.
Properties in ant are immutable so you can specify those properties from the ant plugin in jenkins and they'll override any other values. (click advanced under the invoke ant buildstep to see the properties text box).
I'd recommend you not override user.home but rather refactor your ant so there is a config.location property that defaults to user.home but can be overidden to whatever you want from jenkins. It just seems unnatural to ovrride user.home
Related
Documentation for the Groovy Plugin of Jenkins states that
The system groovy script, OTOH, runs inside the Jenkins master's JVM.
Thus it will have access to all the internal objects of Jenkins, so
you can use this to alter the state of Jenkins. It is similar to the
Jenkins Script Console functionality.
Yet I find that I have a groovy script that I can successfully run in Jenkins Script Console but which does NOT run if entered as a "System Groovy Script" on a build configuration. There are compiler errors. Clearly, the Jenkins Script Console is running with a different classpath than the script in my build. But I can't find information on what the default classpath is when running a script for a build or what the classpath is when running from the Script Console, so I might duplicate that for my script.
Also, the plugin offers a classpath entry field for running the script as a file but that option does not exist for entering the script as text.
I can't get my script to work either way.
What am I missing?
I think the answer is that the Script Console auto-imports the whole Jenkins library. That is not the case with the System Groovy Script. So what worked for me was to run the script, and for every compiler error about an unknown class, add an import statement for that class. I learned what packages they were from by looking at Javadocs.
Automating this would be a nice improvement to the plugin.
May be use the grab dependency management to resolve the library to add
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'm trying to make a Jenkins job that only scans the test source files, so everything under /src/test/java (using Maven). I use the SonarQube Jenkins post-action for this.
When we used to configure Sonar in the pom file directly we could do this in a profile:
<sonar.sources>/src/test/java</sonar.sources>
<sonar.tests/>
That worked fine.
But in the Jenkins job I have to specify these as 'Additional properties' and I can't seem to specify an emtpy sonar.tests element. I tried -Dsonar.tests, -Dsonar.tests=,-Dsonar.tests="", nothing works. When this element is not empty Sonar will attempt to scan the test files twice and crash.
The post-build step is specifically and explicitly a Maven operation. Your problem comes from trying to use Maven to do something un-Mavenish; i.e. ignore the convention that files in the tests directory should be treated as tests.
Since you want to scan your tests as code, your best bet is to use the build step (which uses SonarQube Scanner) and set your scanner properties manually. That will make it easy to set your sources directory and to omit the tests directory.
I am invoking a windows batch command from Jenkins, after i get the latest version of my project from SVN. the windows batch command just performs certain file copying, after the all the files are retrieved from SVN and runs an ANT build. In the ANT build process, i am generating a JSP file where i have tried to capture the in the following fashion.
%BUILD_TAG%-%BUILD_NUMBER%-%BUILD_ID%-%SVN_REVISION%
Unfortunately none of this information is understood by the build process and it just writes %BUILD_TAG%-%BUILD_NUMBER%-%BUILD_ID%-%SVN_REVISION% into the file.
Could you please let me know if there is a way to capture these information into a file in the way i am trying to do? if not, could you direct me on how these information could be captured into a JSP file during the process that we are following?
BUILD_TAG, SVN_REVISION, etc are all environment variables that are present during a Jenkins build, and to use them in Ant, you would use them as any other environment variable from Ant
First, add a line:
<property environment="env"/>
Then you can reference any environment variable with this prefix, like:
${env.VAR_NAME}
So in your case, you'd do:
${env.BUILD_TAG}-${env.BUILD_NUMBER}-${env.BUILD_ID}-${env.SVN_REVISION}
Dos it exist a way to propagate java system property from Tomcat to jenkins ant task?
Particularly I would like to propagate catalina.home property to ant task. When trying catalina.home=${catalina.home} I get error Property catalina.home was circularly defined.
so you want catalina.home of the tomcat that's running jenkins passed into your ant build?
hmmm... I'm not sure it's goign to work, but try setting the catalina.home property to the value of the CATALINA_HOME environment variable:
catalina.home=${evn.CATALINA_HOME}
It likely won't work, you'll want to see what you set CATALINA_HOME environment variable is and just pass that into your ant build:
ant -Dcatalina.home="/usr/share/tomcat7
I don't think you have direct access from your job configuration to your system properties. You will need to write your own plugin to read out the system properties.
Check if you have CATALINA_HOME available. If you do, pass it into ant (ant plugin has a field for that) or set it within your ant-script like thekbb suggested. catalina.home=${evn.CATALINA_HOME}