IMO, this use case really needs to be specifically spelled out on the plugin's webpage/documentation.
Let's say I have a project named U for upstream and D for downstream. When U finishes building, I want D to checkout the same revision that U just built. U will always checkout HEAD.
Here's what I've done:
Now I don't know what I'm supposed to do next, but I get no feedback to indicate this is working. In fact, even this testcase that's committed to the plugin source suggests this is all I should have to do.
But, if I were to guess, I'd think I'm supposed to mark U as a parameterized build and add a parameter to it. This parameter should be named what U sends to D. But, if I've got the right idea, I don't know what I'm supposed to name this parameter. Neither the console log of D nor the console log of U mentions any new parameter.
I took a guess and created a String parameter in U named "SVN_REVISION" and defaulted it to -1, but that had no effect. Every time D triggers a build, SVN_REVISION is defaulted to -1.
This is the output of running export
on the D project:
+ export
export BUILD_ID="2013-03-20_09-48-32"
export BUILD_NUMBER="4522"
export BUILD_TAG="jenkins-D-4522"
export BUILD_URL="http://my.jenkins.server.com:8081/job/D/4522/"
export EXECUTOR_NUMBER="2"
export HUDSON_COOKIE="8ec52f7a-d60d-4640-83a9-dbed7351b32a"
export HUDSON_HOME="/opt/hudson"
export HUDSON_SERVER_COOKIE="633967fcd1d6f7b38a85042ada5c3949"
export HUDSON_URL="http://my.jenkins.server.com:8081/"
export JAVA_HOME="/opt/java"
export JENKINS_HOME="/opt/hudson"
export JENKINS_SERVER_COOKIE="633967fcd1d6f7b38a85042ada5c3949"
export JENKINS_URL="http://my.jenkins.server.com:8081/"
export JOB_NAME="D"
export JOB_URL="http://my.jenkins.server.com:8081/job/D/"
export LANG="en_US.UTF-8"
export LD_LIBRARY_PATH="/opt/jdk1.6.0_30/jre/lib/i386/server:/opt/jdk1.6.0_30/jre/lib/i386:/opt/jdk1.6.0_30/jre/../lib/i386"
export M2="/opt/maven/bin"
export M2_HOME="/opt/maven"
export MAVEN_OPTS="-Xms256m -Xmx512m"
export NHINC_PROPERTIES_DIR="/opt/nhinc/Properties"
export NLSPATH="/usr/dt/lib/nls/msg/%L/%N.cat"
export NODE_LABELS="master"
export NODE_NAME="master"
export OLDPWD
export PATH="/sbin:/usr/sbin:/bin:/usr/bin:/opt/java/bin:/opt/apache-ant-1.8.1/bin:/usr/local/bin:/opt/maven/bin"
export PWD="/opt/hudson/jobs/D/workspace"
export SHLVL="2"
export SVN_REVISION="24186"
export SVN_URL="https://a/url/trunk"
export TERM="xterm"
export WORKSPACE="/opt/hudson/jobs/D/workspace"
export XFILESEARCHPATH="/usr/dt/app-defaults/%L/Dt"
export _="/opt/java/bin/java"
So it looks like it has an SVN_REVISION environment variable. But I don't think that's necessarily coming from the plugin. My evidence comes from the description on the "Repository URL" in jenkins:
During the build, revision number of the module that was checked out is available through the environment variable SVN_REVISION, provided that you are only checking out one module. If you have multiple modules checked out, use the svnversion command. If you have multiple modules checked out, you can use the svnversion command to get the revision information, or you can use the SVN_REVISION_ environment variables, where is a 1-based index matching the locations configured. The URLs are available through similar SVN_URL_ environment variables.
But lets assume this is being set from U instead of D. How do I make D use that or how do I know it's using it when D gets triggered?
Let me ask a question that I'll probably need to ask next. Once I know the name of the parameter I need to use, how do I modify the configuration of D so that it checks out that revision? Do I modify the "Repository URL" to put a @${PARAMETER_NAME}
at the end or something?
This plugin lets you trigger new builds when your build has completed, with various ways of specifying parameters for the new build. These new builds appear as "Subprojects" in the Jenkins UI when you are looking at a project that triggers them.
In your Jenkins job configuration, tick the box named " This build is parameterized ", click the " Add Parameter " button and select the " String Parameter " drop down value. Latest Jenkins docs say that GET is depreciated for security reasons, so POST should be preferred.
Using build parameters, we can pass any data we want: git branch name, secret credentials, hostnames and ports, and so on. Any Jenkins job or pipeline can be parameterized. All we need to do is check the box on the General settings tab, “This project is parameterized”: Then we click the Add Parameter button.
I don't know why "Subversion revision" parameter does not work (see troubleshooting hint below), but try adding the parameter manually under "Trigger parameterized build on other projects" with "Add parameter" dropdown. Simplest might be to add "Current build parameters".
You can also just specify the parameters you want, with the values you want with "Predefined parameters", probably like this:
SVN_REVISION=${SVN_REVISION}
Marking D as parameterized shouldn't be necessary, that just means you can specify parameters with default values, and make Jenkins ask for the parameters when build is triggered manually. But anything that schedules a new build (like Parameterized trigger plugin does) can always add any parameters to that build, no matter how the job is configured.
Troubleshooting hint: add a build step to dump environment variables (which should have all the build parameters too) in the triggered build. Simplest is to add "Execute shell"/"Execute Windows batch command" with command to dump environment (export
with unix shell, set
with Windows).
Then from build console output, see if the parameters are as they should be (exist and have right values).
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With