16

I have two jobs(A and B) that I want to B is triggered by A with the git commit used by A after A is successfully built.

The build trigger plug-in supports trigger the downstream job with the git commit used in the upstream job.

My question is how the downstream job uses the passed in commit to check out. I didn't find which variable is passed by job A, and how to use the pass-in commit value to check out code in B via Git plug-in of Jenkins?

Kane
  • 8,035
  • 7
  • 46
  • 75

5 Answers5

15

Jenkins Git plug-in is an intelligent tool. No specific configuration is needed. In upstream job trigger the downstream job with the Git commit used by the upstream job, downstream will automatically checkout the commit passed in by upstream.

Kane
  • 8,035
  • 7
  • 46
  • 75
  • 1
    Can you explain how does this work with Build pipeline. I want the downstream build to use the GIT_COMMIT variable of the upstream build. Can you please let me know how to configure the same? – leenasn Jan 27 '12 at 16:47
  • 2
    @leenasn I'm using parameter build trigger. The upstream job will trigger the downstream while it's stable with **Pass-through Git Commit that was built**. Downstream doesn't need specific configuration, you only need specify the same git repository for it. The Jenkins core will take responsibility to check out the commit passed in by upstream. – Kane Jan 29 '12 at 02:29
  • 4
    @Kane Do you have any documentation or proof to suggest this is true? – Blowsie Jan 08 '15 at 12:58
  • @Blowsie you can check the build info of your downstream job. You can find the git commit is same as the upstream. – Kane Jan 09 '15 at 07:34
  • I wonder how to setup a downstream job so it either could be triggered by an upstream one with Git Commit Pass-through or manually with branch/tag name as a typed in parameter. Plus not make it very complicated nor confusing. – topr Jun 24 '16 at 12:11
  • 1
    What Kane said is true, but it makes no sense. Why the plugin chose such an opaque method of doing this is beyond me. – cgf Sep 18 '17 at 21:23
  • This is not the case, at least for multibranch pipelines. `build job:` does NOT pass down the commit it built at. https://issues.jenkins.io/browse/JENKINS-61654 – KymikoLoco Aug 18 '21 at 02:41
  • In case anyone needs it: after jenkins checks out the specific commit, it is available from the command "git rev-parse HEAD" – Stephen P. Schaefer May 13 '22 at 22:37
4

I had this same question. The core problem seems to be that Jenkins doesn't carry over build-time variables from the upstream job to the downstream job by default. So the GIT_COMMIT variable will be blank, unless you actually add the repository definition in the downstream job in the Source Code Management section. And from what I can tell, it does fetch the upstream git hash from the repo, so it's not just getting latest.

This was definitely a frustrating point and took me way too long to resolve.

Carbosis
  • 41
  • 1
  • Also, it seems (now) that the called job needs to declare that it receives GIT_COMMIT, but the commit hash value is actually found in GIT_PREVIOUS_COMMIT. – Dave Mar 20 '18 at 14:47
1

It seems that now (Parameterized trigger 2.37, Jenkins 2.204), "trigger parameterized build" has the option to "Pass-through Git Commit that was built". Working even without any special configuration in the downstream job. Similar question

Xyand
  • 4,470
  • 4
  • 36
  • 63
1

I had to combine "Pipeline script from SCM" and "Poll SCM trigger". This can be done by using upstream-downstream jobs.

"Git plugin is intelligent tool and can do this automatically" is no true... I tried the following use cases:

  1. In pipeline script set trigger to upstream job -> not working, master branch is used
  2. In trigger job build downstream job -> not working as well
  3. I had to install "Parameterized Trigger" -> this has an option to "Pass-through Git Commit that was built"

Based on my experiment, use the Parameterized Trigger plugin should be the accepted answer here. If this helps for somebody, cheers...

kiskele
  • 11
  • 1
0

I had this very same problem. You need to make sure that in the "Job Notifications" tab of the downstream project, the option "This project is parameterized" is ticked. If this is not selected, it seems that the downstream job doesn't expect parameters from upstream job, and hence it ignores the parameters.

Lets assume that upstream Job is A, and downstream job is B

In Upstream Job A:

Builds --> trigger/call builds on other projects --> Projects to build --> specify your downstream job(i.e.B)

and then Add parameters --> predefined parameters(choose whatever suits you) in "parameters" specificy the parameters you want to pass to Downstream job B. For example,

GIT_COMMIT=$GIT_COMMIT

GERRIT_BRANCH=$GERRIT_BRANCH

Note that you must put one parameter name/value per line

In Downstream Project B:

Job notifications --> This project is parameterized --> Add parameters --> string Parameters

Insert the name and the default value of the parameters. For example, for the above two parameters you may insert name and default value pairs as

Name: GIT_COMMIT

Default Value: $GIT_COMMIT

Name: GERRIT_BRANCH

Default Value: $GERRIT_BRANCH

This configuration worked perfectly for me.