Jenkins – passing updated revision to downstream jobs

We have moved build system from CruiseControl to jenkins for a multi-platform product. This was a single monolithic job:
1. check for changes
2. update product build number in properties file
3. commit file to subversion
4. pass svn revision number to other platforms for local checkout (performance reasons)
5. build (C++, Java)
6. test

In Jenkins, we have split the build and test into 2 jobs, build triggering the tests. All platform builds have to succeed for tests to run. I’d like tests on platform A to run regardless of build failure on platform B, but that’s a different issue.

  • extract pom version in a jenkins pipeline
  • How to put jobs in a category for the Throttle Concurrent Builds plugin for Jenkins
  • Jenkins build Error local repository Windows Server 2016
  • Setup remote tracking in Jenkins / Git
  • Jenkins job notification fails with “No git consumers for URI …”
  • Jenkins seed job that executes only DSL scripts modified since the last run?
  • The problem I’m trying to address now is for the build phase. When Jenkins starts, it knows the SVN_REVISION of the repository at start of job. We increment the build number before the compilation during the job and it is this svn revision we need to pass to downstream jobs. We need to ensure the same revision is checked out on all platforms and that the test job also checks out same revision. The compilation takes 2-3 hours and testing about 7 hours, so it is normal enough for some new commits to happen during the build that will be included in test job. We have also had commits during build phase that get included in one platform but not the others due to different speeds of checkout.

    We have tried Parameterized Trigger plugin which can pass SVN_REVISION – the revision at time job started, but does not pass the revision of modified file with build number. We use Parameterized Trigger in other cases and it does what we need.

    One thing I am thinking of doing to add svn revision number to properties file. I could read the revision from the property file in other jobs, assuming file has not been changed, which could be risky.
    svn uses ‘:’ to separate property, IIRC, other properties use ‘=’ for key=value as we also read properties to be used in shell scripts. There are other dependent projects, so I’ll try this when I get back to office and set up a sandbox (half day’s work).

    Anyone got any recommendations or comments?

  • Run a background process permanently on a node through a script on Jenkins and let Jenkins build successfully
  • Build Unity project with Jenkins failed
  • svn: E155021: This client is too old to work with the working copy at xxx (format '31')
  • how to use mercurial and svn together
  • What is the recommended source control ignore pattern for Seam projects?
  • Best way to link Redmine issue to SVN revision
  • 5 Solutions collect form web for “Jenkins – passing updated revision to downstream jobs”

    Thanks to this post and the comments below:
    https://itisatechiesworld.wordpress.com/jenkins-related-articles/jenkins-configuration/jenkins-passing-a-parameter-from-one-job-to-another/

    Here is the answer that worked for me:

    1. Get the Parameterized Trigger Plugin (How to install: Manage Jenkins->Manage Plugins->Available and check “Parameterized Trigger Plugin” and install, note I also installed “Environment Injector Plugin”, this may be necessary as well)
    2. Goto JOB_1 and add a Post-Build action (Trigger parameterized build on other projects)
    3. Type the project to build JOB_2
    4. Add Parameters (Predefined Parameters)
    5. Type the following in the Parameters box: SVN_REV=${SVN_REVISION}
    6. Apply and Save
    7. MOST IMPORTANT: YOU MUST ADD THIS PARAMETER (SVN_REV) to JOB_2
    8. Goto and check “This build is parameterized” and add a “String Parameter”
    9. Type “SVN_REV” (Must be same name) and put in a default value of 1 or anything
    10. It’s now an environment variable, to access it, all you need is %SVN_REV%
    11. In your build step, you can write echo %SVN_REV% and it will display the SVN_REVISION.

    In short (Parameter must be specified in BOTH jobs)
    JOB_1 => SVN_REV=${SVN_REVISION}

    JOB_2 => Add SVN_REV as a String Parameter, to access type %SVN_REV%

    I think the Clone Workspace Plugin would work well for you. It allows you to clone the workspace so another job can use it. Using this, I would configure my jobs something like this.

    • (1) Master Job: Check out the source, update the build number, make workspace clone
    • (2) Platform 1: use clone from #1, build for Platform 1, make workspace clone for testing Platform 1
    • (3) Platform 2: use clone from #1, build for Platform 2, make workspace clone for testing Platform 2
    • (4) Testing for Platform 1: use clone from #2
    • (5) Testing for Platform 2: use clone from #3

    We ran into similar issue where we want to call jobs on the slave machines and pass the SVN revision which master is using, following is how we solved this problem:

    1) Invoke the child job with predefined parameter say MASTER_SVN_REVISION and assign it value of SVN_REVISION
    enter image description here

    2) Now in the job which you have invoked in step 1, use following mechanism to use value of MASTER_SVN_REVISION

    enter image description here

    One of the source options in the Parameterized Trigger plugin is:

    • properties from a properties file read from the workspace of the triggering build

    If you create this in the original workspace without checking it in, you won’t have any risk of change before the downstream jobs are triggered.

    In your build step, you can write echo %SVN_REV% and it will display
    the SVN_REVISION. In short (Parameter must be specified in BOTH jobs)

    JOB_1 => SVN_REV=${SVN_REVISION}
    JOB_2 => Add SVN_REV as a String Parameter, to access type %SVN_REV%
    

    Use ${SVN_REV } to access. It worked for me.

    Git Baby is a git and github fan, let's start git clone.