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.

  • Jenkins: remove old builds with command line
  • How to configure a jenkins job to send mail if a SCM commit
  • Running sequentially job tasks on several environments using Jenkins
  • Unable to get Jenkins and Git to play nice
  • Let jenkins build project from mercurial commit
  • How to conditionally skip maven tests on Jenkins for CI
  • 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?

  • Subversion Post-Commit Hooks
  • Jenkins Build Flow Plugin sequentially chain multiple jobs in parallel
  • Reverting to a previous revision using TortoiseSVN
  • The Dual Nature of svn:ignore
  • Can I get Jenkins to build a git tag from a passed in parameter?
  • Can I mass edit jenkins jobs by modifying the config.xml files?
  • 5 Solutions collect form web for “Jenkins – passing updated revision to downstream jobs”

    Thanks to this post and the comments below:

    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
    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_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_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.