How downstream job uses the git commit that is passed by upstream job?

Question

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?

Schoolfellow

Answer 1

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.

Schoolfellow

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? – Headship

@Headship 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. – Schoolfellow

@Schoolfellow Do you have any documentation or proof to suggest this is true? – Scissure

@Scissure you can check the build info of your downstream job. You can find the git commit is same as the upstream. – Schoolfellow

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. – Comet

What Kane said is true, but it makes no sense. Why the plugin chose such an opaque method of doing this is beyond me. – Cotoneaster

This is not the case, at least for multibranch pipelines. build job: does NOT pass down the commit it built at. issues.jenkins.io/browse/JENKINS-61654 – Cavil

In case anyone needs it: after jenkins checks out the specific commit, it is available from the command "git rev-parse HEAD" – Beckman

Answer 2

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.

Chartres

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. – Kaule

Answer 3

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

Volga

Answer 4

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

Pycnometer

Answer 5

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.

Scut