4

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?

2

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" }
  } 
}
5
  • 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. 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. 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. Jan 7 at 11:18
1

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.

1
  • 1
    I wish I could explain how good it feels to hear "you are not building the wrong thing." I have evolved away from this particular use case but it is nice to hear. Sep 21 at 15:56
1

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

0

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.

1
  • This is interesting, but is there a way to figure out which branch it was merged from? I am using the former branch name to create an environment and I need the branch name again to spin it back down upon deletion. Sep 17 at 4:33
0

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.

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.