In Jenkins config, we have Goals and options, against which we add the path of .xml file which we have to execute. Like:
clean test -DpathToMySuiteFile_1=sanity.xml
In above line, what is the work of -D?
It is connected with Maven (and Maven plugin), not Jenkins itself.
-D option is used to define system properties for Maven via command-line, e.g.:
mvn clean test -Dproperty1=propertyValue2 -Dproperty2=propertyValue2
So, in your case, -D just sets sanity.xml value to DpathToMySuiteFile_1 variable.
This option is usually used to customize the behavior of Maven plugins. See details here.
Update: as #snukone already mentioned, here is the detailed answer.
Related
I am new to SCM tool like Jenkins so I may not actually ask the right question.
I find out there is a specific Gradle executed task failed when check the logs of Jenkins.
However, I cannot find out where the Gradle executed task is defined and what is the content of it.
I look up the [CONFIGURE] of Jenkins and then in the [BUILD] section, there is a section called [Invoked Gradle script] and I could see the name (lets call it X here) of executed Gradle task I am looking for.
But I cannot find where X is really defined and what command it actually run, Does anyone has any suggestion? Thanks.
You can try using gradle in verbose mode
gradle -S build
-S, --full-stacktrace
Print out the full (very verbose) stacktrace for any exceptions. See also logging options.
or try using debug mode
-d, --debug
Log in debug mode (includes normal stacktrace).
https://docs.gradle.org/current/userguide/command_line_interface.html
Gradle provides a Domain Specific Language (DSL), for describing builds. This uses the Groovy language to make it easier to describe a build. Each build script of Gradle is encoded using UTF-8, saved offline and named as build.gradle.
By default, Gradle command will invoke Gradle script from build.gradle file.
You can run a Gradle build using the Gradle command. This command looks for a file called build.gradle.
More details here.
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 want to pass a dynamic parameter in Jenkins in a scheduled job (this build runs every day at 3:00 am)
This works if I executed it in my linux command line:
mvn package -DintegrationTag=$(date +%d-%m-%y)
or
mvn package -DintegrationTag="$(date +%d-%m-%y)"
or
mvn package -DintegrationTag="$(date +"%d-%m-%y")"
with these 3 options this is what is executed, for example (this is what I want to do in Jenkins):
mvn package -DintegrationTag=16-09-2013
but any of these sentences, do not work in my Jenkins goals and options (because the dynamic parameter).
Is there any way to do it?
The solution:
Content of the file which constains the script:
echo "NOW=`date +%d-%m-%y`"> env.properties
Path of the properties file:
env.properties
In project, goals and options:
clean test package -DintegrationTag=$NOW
Inject environment variables to the build process = true
In a Build "execute shell" section add this
NOW=`date +%d-%m-%y`
mvn package -DintegrationTag=$NOW
Another option can be to execute a top level maven target in jenkins.
The first two steps of injecting the required variable value into the build environment remains same as the answer given by #Iker below.
In the third step, give goal as
clean test packageand then in Properties section within the 'Advanced' tab, giveintegrationTag=$<your variable name>
Note that this solution is useful when one creates a free style project in jenkins. For maven 2/3 projects,solution by #Iker is good:)
I'm interested is it possible using Jenkins+Performance plugin to run more than one .jmx (jMeter) files.
I'm using SVN repository where I keep my jMeter scripts. But problem is I can add only one jmx file to repo. I want add more than one, but Jenkins runs only first one.
I think you can use Ant to do this in Jenkins.
Note the "testplans" element in the following build.xml snippet:
<jmeter>
jmeterhome="c:\jakarta-jmeter-1.8.1"
resultlog="${basedir}/loadtests/JMeterResults.jtl">
<testplans dir="${basedir}/loadtests" includes="*.jmx"/>
</jmeter>
More info here: http://www.programmerplanet.org/projects/jmeter-ant-task/