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...
Related
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!
I want to move an issue to the deployed stage (transition) when the gitlab pipeline of a merge request has finished. Is that even possible?
My Idea so far:
The pipeline is related to that specific issue by both the branch name (see 1.) of the merge request and also the message of that merge request like so "Finish PV-1234".
I can parse the issue key from the branch name.
I can call a server to run a script making the Jira api call.
If you directly want to close the issu, look into the gitlab jira integration docs - therefore you have to add a description to your MR, to tell the integration to close the issue, as soon as the MR was merged.
If you want more control, write yourself a simple script, that first gets the ids of the available transition (You can get them via /rest/api/3/issue/{issueIdOrKey}/transitions see here) and after that posts the transition you want (You can do that by posting on the same endpoint, as the get command mentioned before see here).
Sad that the jira integration doesn't provide more issue-movement than jsut closing issues...
Hoping to gather insight from professionals. My end goal is to trigger a jenkins build whenever a bitbucket pull request happens. If anyone could give me an ELI5(explain like I am 5) answer it would be greatly appreciated. Sorry if this is the wrong format, I am new to jenkins and stackoverflow.
What I have done so far:
Created webhook in bitbucket and gave the url to my jenkins job. example: http://jenkinsURL:8080/job/boulevard-dev/generic-webhook-trigger/invoke?token=myPull_Request_Token
Pull request webhook trigger
In Jenkins, under source code management I have: Source Code Management Settings. This is currently fetching a ton of branches, failing, then building the master branch when the job starts?
For build triggers, other stackoverflow articles have pointed me to the "Generic Webhook Trigger". https://github.com/jenkinsci/generic-webhook-trigger-plugin
I am not entirely sure how this generic webhook trigger should effectively be setup? Hoping someone has experience using it and could explain what is needed.
This is what have seen referenced in other articles.Build Triggers settings Build triggers settings 2
Questions:
What does a correct setup / example of the generic webhook trigger look like?
Currently, my job triggers when a change is made to master or merged to master, how can I specify to my job that I want the bitbucket pull request branch to be built?
Also, I found this, not sure if its related to my issue or not? https://jira.atlassian.com/browse/BCLOUD-5814
As per your requirement, you can trigger a Jenkins build whenever a bitbucket pull request happens by following the below steps, in my case, it's working fine.
Step(1) - Configure Jenkins
(i) Add your bitBucket repo and branch to source code management
(ii) On build Triggers setup Poll SCM to * * * * * for run every minute to check pull request from bitBucket.
Step(2) - configure Bit Bucket Hook
(i) Go to settings and add a new hook, now setup pull request trigger as per your requirement.
Step(3) - Make a pull request and see the new job automatically triggered on Jenkins.
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'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