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...
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 a Jenkins server (2.249) setup and I have connected my GitHub account and tested the connection and it works fine, but for a normal pipeline job where you enter the GitHub repo url, Jenkins seems to add an extra slash at the end? So I can't get my normal pipeline job to build on a push event, I've checked the logs and it says:
skipped [repo-name] because it doesn't have a matching repository.
So I've starting to think its because Jenkins is adding an extra slash at the end of my repo url? The webhook on the GitHub side works as it gives back a green tick and it works on another multibranch job for push events, just not the normal pipeline jobs.
Don't know if the problem is still on after more than one year but because I've just faced the same issue, here is an answer that help me to understand : https://serverfault.com/a/884717
Just to resume the answer : you have to complete the git part (scm) of your Project Configuration :
For my part: as the project is a private one, in an organisation that I can't update to add a personal token (as I'm not the owner of the resource - organisation), I choose to use the git+ssh url with a ssh key access to this repo. The next trick for github is to add the github's IPs to the jenkins user know_hosts file !
The reason behind the need to add twice the repository url is obscure. But I could only see that in https://github.com/jenkinsci/github-plugin/blob/master/src/main/java/com/cloudbees/jenkins/GitHubRepositoryNameContributor.java#L113 the method parseAssociatedNames will try to get the Jenkins'job associated names from :
com.cloudbees.jenkins.GitHubRepositoryNameContributor$FromSCM
com.cloudbees.jenkins.GitHubTrigger$GitHubRepositoryNameContributorImpl
org.jenkinsci.plugins.github_branch_source.GitHubSCMSourceRepositoryNameContributor
I think the third one is for multibranch pipelines. I don't really know for the second but indeed the first one is fromSCM configuration !
I am switching from the github pull request builder plugin (for security reasons) and am trying to get the same functionality from Pipelines (using different plugin). I think I have just about everything, however I can't seem to find a way to re-trigger a build simply by a trigger phrase like in github pull request builder plugin. Is that possible via pipelines?
By trigger phrase, I mean that a user can make a comment on the PR saying "Jenkins re-test" and it will kick off the build again.
You can put a condition at the top of the build script to check for the message. You can access the changesets using currentBuild.ChangeSets. The last changeset is at the end of the array. Then you need to access the last element of that changeset. Finally you can access the message via message property. You can then search for your keyword.
I am doing the opposite (not triggering the build with a phrase) but never tried for pullrequests though.
Another idea is to use the "ignore builds with specific message" property and setting this message to be a regex with look ahead that accepts everything except the keyword. I don't really recall the syntax though :/
we have jenkins CICD automated pipelines working great. we also trigger it via REST API with build Parameters.
Now, we have JIRA dashboard having custom workflow created where developers moves or changes queue of issues/stories to "ReadyForDeployment" once development is completed.
Now here, once developer moves queue to "ReadyForDeployment" :-
JIRA should prompt for 3 fields (ENV, PACKAGE_NAME_APP and
PACKAGE_NAME_DB) those will be placed in jenkins URL like
blahblahblah/buildWithParameters?ENV=${ENV}& PACKAGE_NAME_APP=${PACKAGE_NAME_APP}&PACKAGE_NAME_DB=${PACKAGE_NAME_DB}
Basically upon queue change,webhook should be triggered whcih
will take input/parameters from JIRA itself.
Please let me know your thoughts on this.
It depends on your requirement whether its correct or not. But it can be possible to trigger jenkins from Jira useing Jira-weebhook and passing the parameters.
https://developer.atlassian.com/jiradev/jira-apis/webhooks
I am using Jenkins in combination with the Git and Gerrit plugins. I would like to trigger a job on Ref Updated. However, I need to understand if the action behind this event is the creation of a new branch. If it is, then I will execute my shell script, otherwise not.
As far as I understood, this info is available in the Gerrit's event json response, but I do not know how to consume this json object via Jenkins in the first place.
Is there a way to achieve this easily via Jenkins (maybe something in the interface I missed)? Or is there another way to monitor the creation of a new branch while still in the Jenkins/Gerrit plugin environment?
So I just recalled there are a bunch of Gerrit environmental variables which are available to use in the building script,
namely these ones. I will just have to check if GERRIT_OLDREV is equal to 0000000000000000000000000000000000000000 and if so, it would mean the branch is newly created (for reference: here). Here is the picture I attached in full size.