I'm trying to achieve the following: When someone creates a Merge Request in GitLab, a Jenkins job would be triggered that builds the source branch.
Problem is: It works, but it also builds the branch when the Merge is actually performed.
It should only trigger Jenkins when a MR (Merge Request) is created, not when it's merged. I thought about differentiating between a MR and a Merge with the environment variables but the environment variables for a MR and an actual merge are exactly the same in Jenkins so that doesn't help much.
Configuration:
In GitLab, I've created a webhook for Merge Requests
In Jenkins, I've created a build trigger that says it builds "only if new commits were pushed to the MR".
(I've tried using only "Opened MR events" or only the "only if new commits were pushed to the MR" option but then it doesn't work. [either builds on every action such as a comment or it either doesn't work on a new Merge Request.])
It seems like it's impossible to have Jenkins only trigger a build only when a Merge Request is created. Am I wrong? Is there another way of doing that? Thanks ahead!
Related
In GitLab, I have made it so that when a Merge Request is created, it triggers Jenkins which builds the source branch.
(This is how I did it: In GitLab, I've added a webhook on a Merge Request, and in Jenkins, I've configured it to accept merge requests)
Problem is, if there's an Open Merge Request, and after a while someone assigns a user to that Merge Request, that will trigger the webhook and it will build the Jenkins job again, even though it's not necessary.
Is it possible to not have the Jenkins job triggered when a user is assigned to the GitLab Merge Request? (I couldn't find anything online and in Jenkins, it looks exactly the same in terms of the build and environment variables)
Thanks ahead!
What works for me :
I work on similar task last week but to avoid this behaviour I am executing my jenkins job after making comment on Open merge request
Another solution could be trigger when branch merged [I had diff intentions so not implemented this way]
Additionally I have made cmd result as mandatory parameter
Because once merge request created there might be many commits by diff team-members, diff comments. So keep looping to avoid this is not good solution
Lastly I reported the execution result in same merge request & this serves my concern
For reference you can go through Webhook Trigger plugin
Resolved: https://i.imgur.com/cY9cyci.png
Just check this box with the one above it...
I have configured a Jenkins Pipeline that correctly receives webhooks push notifications from GitHub, on push events.
The authentication is done through a deployment key.
Jenkins configuration seems to rely a lot on the concepts of branches and pull requests.
Given my workflow, which consists mostly of creating branches for any needs, and merge changes back onto master once things would look fine on the CI, I do not really care about seeing my builds categorized by branch or PR.
I would prefer to see builds based on commits' hashes. I do not see the need to tell Jenkins what branch I want it to match.
My current configuration is not selecting the commit revision I desire. I do not understand how it decides which branch or commit to build, once it receives a push notification. In Jenkins I have set the branch to **.
Checking the webhook payload, I noticed that it contains both the list of commits but also something called head_commit, with its id property being the commit's hash I want to see being built.
I would like Jenkins to do the following:
Check what's the head commit in the webhook notification (head_commit.id in the payload)
Build that precise commit, no matter the branch it is part of
Setting a green tick or a red cross beside the commit's hash on Github
Is this possible?
It works like this now,somebody creates a merge request in gitlab which triggers a build in Jenkins through “Trigger builds remotely”,jenkins implements the defined build and does something after the build(Post-build Actions).
There's an option called "Accept gitlab merge request on success" in the "Post-build Actions" in jenkins jobs,but we want to implement "Close/Delete gitlab merge request on failure" after a failed build,is this possible please?
Thank you.
As far as I know it's not possible. I think this is because most people don't want to do it. Just because the build fails doesn't mean that your merge request is invalid. You can keep your merge request open, fix up the code and keep running builds until the build is successful, and your merge request will keep on being updated with the latest checkins. Then once it builds you can accept the merge request instead of churning and constantly creating new ones which is where you would end up.
I have a very peculiar problem on my Jenkins. Gerrit trigger works on first master branch usually. When I create a new branch and push something to it, the build is not triggered at all. Even when I do Query and Gerrit trigger patch it does not work. But, when I open the job configuration, Save and do a manual trigger it works. The next consecutive push work as normal again.
I'm aware that both GitLab and Jenkins have integration points with one another, however for reasons beyond my control I am not able to use either.
It's easy to pass parameters to a job telling it which branch, even which commit to build. However I just can't seem to tweak it to the right configuration where it will build the merge request number I pass in as a parameter.
I need to do this with the out-of-the-box 'git' functionality in Jenkins. (Can't use the GitLab Merge Request plugin because it requires polling of the repo.) This job must be initiated manually, and the merge request number specified via parameter. I will not be triggering it with a webhook from GitLab either. This requirement is a manual and on-demand build of a specific merge request.
Is it possible, and I'm just missing something (not) obvious?
So no one else has to endure figuring this out themselves ... yes... Jenkins can build a GitLab merge request out of the box, with no crazy plugins.
In Jenkins, in the Source Code Management section, click Advanced, and set the Refspec to:
+refs/merge-requests/*/head:refs/remotes/origin/merge-requests/*
then, in the Branch Specifier field, use this:
origin/merge-requests/${MR}
where ${MR} is a parameter passed to the build - the number of the merge request to get.
This is what works for me as of Apr 2022 (Jenkins 2.303.2)
The other answers seem to now be outdated (2016 & 2018) and don't work for me (however pointed me in the right direction).
Using gitlabMergeRequestId gave me some weird huge ID for a merge request that didn't even exist in my repository (I don't know where that comes from) & MR seems to be an old placeholder back in 2016(?).
Here's what works for me:
1. Checkout of the commit
Set Pipeline > Repositories > Advanced > Refspec to:
+refs/merge-requests/*/head:refs/remotes/origin/merge-requests/*
Set Pipeline > Branches to build > Branch Specifier to:
origin/merge-requests/${gitlabMergeRequestIid}
N.B. gitlabMergeRequestIid is not a typo & differs from gitlabMergeRequestId
2. Specifying branch in Pipeline script
With the above, checkout is successful but you still need to specify what branch your pipeline script will use.
Use the gitlabSourceBranch environment variable, which works in your script for the Git plugin (didn't work for me whatsoever for the branch specifier 🤷♂️).
branch: '${gitlabSourceBranch}'
...
End result (excluding script):
P.S. in case the placeholders change again or this doesn't work, check https://github.com/jenkinsci/gitlab-plugin#defined-variables
In Jenkins, in the Source Code Management section, click Advanced, and set the Refspec to:
+refs/merge-requests/*/head:refs/remotes/origin/merge-requests/*
then, in the Branch Specifier field, use this:
Here are the variables that you can occupy https://github.com/jenkinsci/gitlab-plugin#defined-variables, but for this case you should occupy.
origin/merge-requests/${gitlabMergeRequestId}
where ${gitlabMergeRequestId} is a parameter passed to the build - the number of the merge request to get.
I have implemented GitLab webhook and it worked correctly