I think i've scoured every post on this topic but haven't found my specific scenario. (Maybe that means I'm building the wrong thing OR i've built something unique and new? The former is far more likely)

I have a multibranch pipeline in Jenkins being triggered by webhooks from GitHub. I want to automatically tag the repo being built only when a PR from develop|release|hotfix branches are closed and merged to master.

What I want to drill in on is how to identify when a master branch build is triggered by the merge from a PR, and not from anything else. I don't want to tag if master builds due to a non-PR merge. (This would allow updating readmes and code comments without generating a new tag.)

I'm getting the tag string from a file in the repo, and I know how to use the PR builder to identify the source and target of a pull request for when conditions. I know how to get the JSON build information and pull data out, but what I want doesn't seem to be there.

when { changeRequest target: 'master' } only identifies the PR build, not the master build that results when the PR is closed and merged.

when { branch 'master' } obviously identifies a master branch build, but how can I limit it to only build when the build is triggered the merge from a closed PR?


You might try installing the GitHub Integration plugin. Reading their documentation, they provide a number of environment variables you can use for your purpose.

  2. GITHUB_PR_SOURCE_BRANCH for the source branch (e.g., hotfix/foo)

Using the when condition, you can run a job/stage when it's a closed PR merging into the master branch using:

when { 
  allOf { 
    expression { env.GITHUB_PR_STATE == "CLOSE" }
    expression { env.GITHUB_PR_TARGET_BRANCH == "master" }
    expression { env.GITHUB_PR_SOURCE_BRANCH == "hotfix/foo" }
  • Thanks, but this only shows the env vars of a PR 'branch', ie the job that's created when you pull a PR. As I mentioned i know how to find the values of the source/target branch. What i'm looking for is some way to tell if the master build that's happening is a result of a PR merge/closure, or just a regular ol' push to master (which is discouraged, but could happen - in which case I don't want to tag). I've tried to use currentBuild.getBuildCauses() but it only shows "push even to master", which i think applies to any merge to master. I'm only looking for PR merges. – Max Cascone Jun 16 '20 at 15:32
  • Just wanted to clarify something before I provide another possible solution -- checking that the env.GITHUB_PR_STATE is CLOSE is not sufficient to detect that's it's a closed PR? – Argyle Jun 16 '20 at 17:16
  • Can you try including the following line in your pipeline: def build_cause = JSONArray.toList(currentBuild.getBuildCauses()) What is the value of build_cause._class[0] when the job is triggered from GitHub? – Argyle Jun 16 '20 at 17:20
  • i'm sorry i haven't done exactly this yet but i can tell you from the json of the build, that the PR build contains "actions": [ { "_class": "hudson.model.CauseAction", "causes": [ { "_class": "jenkins.branch.BranchEventCause", "shortDescription": "Pull request #27 updated" } ], but the branch build only has "actions": [ { "_class": "hudson.model.CauseAction", "causes": [ { "_class": "jenkins.branch.BranchEventCause", "shortDescription": "Push event to branch PLATDEV-6356-pipe-template-2" } ] }, These are the same as shown at the very top of the build console output. – Max Cascone Jun 27 '20 at 4:17
  • Late to the discussion, have you solved this? What about checking the number of parents of the current commit in git? This assumes any direct push to master contains only commits directly committed to master. Don't know if this is easy to check from a Jenkins pipeline, though. – José González Jan 7 at 11:18

Check if the GIT_COMMIT is a merge commit using git rev-parse:

when {
  branch 'master'
  expression {

def isMergeCommit(String commit) {
  isSimpleCommit = sh(returnStdout: true,
      script: "set +e; git rev-parse --verify -q $commit^2 > /dev/null; echo \$?").trim()
  return isSimpleCommit == "0"

set +e is needed because the script returns a non-zero exit code if the commit is a simple (non-merge) commit.


You are not building the wrong thing this is a topic that is coming up more and more frequently as people create more and more advanced pipelines. You can see people discussing the need for it here.

The reason is doesn't come up a ton is most people can just trigger their tag job on any change to master. Which is much simpler to setup. I often want to tear down something like a environment when a new feature is merged.

Pretty much your best bet is too follow this guide. Basically you use the generic-webhook-trigger plugin. It allows you to extract parts of a JSON payload into environment variables injected into the job. Once you have done that you just follow Argyle's answer.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.