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:)
Related
I have 3 Jenkins jobs to be run in serial.
Run a Ant File
Run another ANT File
Run a command line
All the above jobs use a file path which is set in a properties file.
Ex Job 1 , Executes ANT file placed in file path location
Job 2 , Executes another file placed in same file path location
Job 3 , Executes command line to do SVN update in same file path location
I need to parameterize the file path in all three builds from properties file.
Can anyone help me with possible approach?
Thanks In Advance
This answer could be a little high level. You can use Jenkins Pipeline as a code for this approach instead of using 3 freestyle jobs.
You can create 3 stages which performs these 3 steps. Pipeline as a code supports reading of properties from different file types (json, yaml etc.)
Look for the "EnvInject" plugin. This lets you inject properties into your build as environment variables; these assignments survive build step boundaries.
If the property file is checked in, you can load it in the Build Environment section before the build steps start executing. If the property file is generated during the build sequence, you can add a build step between where the property file is created and where it is used.
Once set, if the property file contains "FOO=/path/to/folder" then in configuring Jenkins things you would refer to $FOO or ${FOO} (for example, an Ant build step might specify "${FOO}/build.xml"; in Windows batch script execution FOO shows up as an environment variable and is referenced by %FOO% (i.e., "#echo Some_Useful_Piece_Of_Data > %FOO%\data.txt"
More information can be found here: https://wiki.jenkins.io/display/JENKINS/EnvInject+Plugin
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 have a Maven module that utilizes the NAR plugin to build some JNI libraries, and in Jenkins I have configured a Maven project to build this module. In order for these libs to be built, the Visual Studio bat file that sets up the path and other environment variables must be run. I have tried several different ways to get this bat file to execute before the Maven commands are called, and none of them have worked correctly. I know that Jenkins isolates all of the build process steps, so it can be difficult to get the environment set up, but I'm hoping someone has solved this particular issue. Here's what I've tried:
calling the bat file as a pre build step.
Using the EnvInject plugin to call the bat file, both as a pre build step and as a pre job step.
Setting the environment variables directly without calling the bat file using EnvInject.
calling the bat file from the mvn.bat file (this failed because it appears Jenkins will call Maven directly, without using the bat file).
As a workaround, I'm using the Freeform project type and setting the build steps to
call the bat file.
Directly call maven with appropriate parameters.
This works, but it's not as nice as using the Maven project type, ex. a failed unit test will fail the entire build instead of just sending a warning. Is there a way to configure this as a Maven project?
I'm trying to create a generic Jenkins job for deploying different projects from different GIT repos and branches to different application servers (in any combination).
I have 2 string build parameters for the repo and for the branch, and a small shell script in a pre-build step which based on the build params creates a deploy.properties file with properties URL and PROFILE.
Another pre-build step is the Inject environment variables which uses the deploy.properties file previously created.
I'm to use the URL property in the Jenkins Deploy Plugin in the following way: Tomcat URL field - $URL.
Also, in the build section, I'm using the PROFILE property: clean install -P$PROFILE .
The problem is that the placeholders or not replaced by the values I've set in the shell script. Not that is I do another post-build action and I'm echoing the same placeholders, the values are replaced and it seems to work. Other check I've done is the Environment Variables section from a given Build and the variable values are there, so the injection works.
Any ideas?
Try the below and make sure you don't have the cmd in single quotes or anything.
clean install -P${PROFILE}
I have a sbt project with 4 modules: module-a, module-b, module-c, module-d.
Each module can be packaged as a WAR. I want to set up a deployment on Jenkins that would build only one of the 4 modules and deploy it to a container.
In detail, I want to have 4 Jenkins jobs - job-a, job-b, job-c, job-d, each building only the defined module (a to d).
For now, I am using clean update test package as the command for the Jenkins sbt build, but this results in packaging all 4 modules that is not necessary.
I already tried project -module-a clean update test package but with no luck.
You may also like to execute project-scoped clean and test tasks as follows:
sbt module-a/clean module-a/test
The solution is slightly shorter and clearer as to what project the following commands apply to.
You don't need to execute update task since it's implicitly executed by test as described in inspect tree test.
There's a way to make it cleaner with an alias. Use the following in the build.sbt:
addCommandAlias("jenkinsJob4ModuleA", "; module-a/clean; module-a/test")
With the alias, execute jenkinsJob4ModuleA to have the same effect as the above solution.
Quote the argument to project, i.e. project module-a, and don't use a dash before the name of the submodule.
The entire command line for the Jenkins job would than be as follows:
./sbt "project module-a" clean update test