How to determine if a Jenkins build is triggered by a Pull Request merged to Master

Question

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?

Answer 1

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

1. GITHUB_PR_STATE can be OPEN, CLOSE
2. GITHUB_PR_SOURCE_BRANCH for the source branch (e.g., hotfix/foo)
3. GITHUB_PR_TARGET_BRANCH or master

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" }
  } 
}

Answer 2

I've solved this!

I can't find the stackoverflow question that helped me, but they gave me the idea.

git log --format=format:%s -1

Specifically, I have a bash file that does the following as part of my jenkins pipeline.

echo "COMMIT MESSAGE" `git log --format=format:%s -1`;

In my PR build, it prints the following:

2021-10-07 12:56:43 COMMIT MESSAGE prints

In the master build, it prints the following:

2021-10-07 12:58:11 COMMIT MESSAGE more print statements (#1948)

And then you can use some bash kung fu to do what you need to do from there!

I noticed this when manually scanning the JSON payload that GitHub sends to Jenkins and noticed that GitHub was adding the PR # at the tail end of the git commit message (but only for master for some reason).

Answer 3

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.

Answer 4

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

when {
  branch 'master'
  expression {
    isMergeCommit(env.GIT_COMMIT)
  }
}
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.

Answer 5

Wow, this has garnered a ton of views. For what it's worth, I've ended up building a much simpler solution since I posted this.

Ultimately, we've stopped using PRs for much of anything pipeline-related other than build success. It's just too complicated to get data out of them reliably, and there's too much hand-waving and magic happening for the average developer who's not inside this stuff all day to really get it. In fact, I am able to identify PR branches at a basic level by checking for env.CHANGE_ID != null, and just skip wholesale or hardcode a lot of stuff that's not important to us for PRs, like versioning and archiving. I can always come back to it later if we decide we want to actually use the PR builds for anything.

What we have currently is a process implementing basic Semantic Versioning, where we only tag on develop builds, develop being our de-facto mainline. We don't do a great job of merging to master after releases, but we are pretty solid on always only deploying from develop. (Why keep main around, then? We ask ourselves that often. It comes down to priorities of process changes; it's not really hurting anything to have it, so we focus on other stuff.)

I recently integrated gitversion into the pipe, and have it configured to automatically bump the PATCH version on any commit-build to develop. If a bump of MINOR or MAJOR is required, the commit-message phrases can be used.

Gitversion is nice because it removes the need for a file in the repo to be updated manually; it's based entirely on git tags and commits. It even updates the assembly*.cs etc files in the repo automatically. The downside is it took me quite a while to feel like I understood it well enough to use it; its configurability makes it complicated to grok at first. There are other tools out there that do the same thing, this is the one that was suggested to me and the docs made me comfortable enough to jump into it.