I have added the GitLab plugin to jenkins and set a webhook so GitLab triggers a Jenkins build. Jenkins pulls the revision and merges it locally with the target branch. Afterwards it builds the merged code. So far everything is fine.
Now I want Sonarqube to analyse the merged code and add comments to the GitLab merge request (using the Sonarqube GitLab plugin). For this I would need the remote commit SHA from Jenkins to be passed into Sonarqube as sonar.gitlab.commit_sha
However in Jenkins in this case the variable $GIT_COMMIT refers to the locally created merge commit - which of course cannot be found in GitLab and therefore no comment can be added.
Is there any solution to this? Am I on the wrong track doing it this way and should I just provide the sonarqube comments for pushes to the feature branches (before the merge request)?
Thanks for any input.
Related
We set up Gitlab with Jenkins integration, by using Jenkins Gitlab plugin and trigerring Jenkins webhooks (regular Pipeline type job) on gitlab Merge Request events (configured in Gitlab->Repo->Integrations) and we are successfully displaying the job build status on the Merge Request page (by using updateGitlabCommitStatus in the pipeline) - it is displayed as a status of some pipeline, which as I understand, is created and associated with the last commit in the source branch.
At some point, I canceled this pipeline from the MR page and after that, closed and reopened the MR, thus re-triggering the build.
Unfortunately, after cancelling the pipeline, the latest build job statuses were not reflected nor in the MR, nor in the pipeline itself. In the pipeline page it wouldn't even display the newest jobs running in jenkins.
I tried deleting this specific pipeline (via curl - we are using gitlab 12.3, which doesn't allow deleting pipelines via GUI) and creating a new Merge Request (same branch, same commit), hoping that a new pipeline would be created in this case, but nothing. It seems that I have no means to display build status again for this specific commit.
Any suggestions how to overcome this?
Thanks in advance!
I have a similar case and the only way to do this is to re-run the pipeline from GitLab... You have to enter to the integrations and there you should look for all request sent to the Jenkins. Once you locate the correct one, you click on resend and it should give you the correct status.
For my observations, the update GitLab status command only work when it is invoked from a webhook.
Im trying to build a Jenkins pipeline which enforces gitflow.
My requirements are that when there is a merge from the release branch (e.g. release/v1.0.0) to master i will use the same docker image that was created during the last commit on the release branch, before the merge commit (in other words, use latest image that was approved in staging).
I'm trying to figure out how to access the GitHub PullRequestEvent event payload in my groovy jenkins pipeline, so i can see if the source branch is a release branch and tag the container with the release version tag. Then I'll use them in my pipeline.
I've started lately to use Jenkins and i need some help with creating a pipeline.
I want to create the following pipeline:
For each merge request from develop to master in Gitlab, Trigger a Jenkins job that run an end-to-end test, And merge the branches in Gitlab only if the test succeeded.
I have found the following article that gives me an explanation for most of the things that i need:
https://vetlugin.wordpress.com/2017/01/31/guide-jenkins-pipeline-merge-requests/
I'm still looking for an answer for one question:
How can Jenkins response to Gitlab with the result of the end-to-end test (Success/Fail), So Gitlab will know whether to merge to branches or not?
Please advise,
Thanks!
You do not tell us how Gitlab and Jenkins are connected, but I'll assume you use the Jenkins Gitlab plugin https://github.com/jenkinsci/gitlab-plugin. If you're not, maybe you should :)
With this plugin, you can 'integrate' more deeply Jenkins and Gitlab, and your Jenkins builds will send back to Gitlab the result of the build. You will see something like this https://raw.githubusercontent.com/teeks99/gitlab-plugin-wiki-images/master/Setup_Example_img/Result_commit.png. Build results are marked near the commit which has been tested.
In this case, for each merge request, you can check the "Merge if build succeed" button (see https://raw.githubusercontent.com/teeks99/gitlab-plugin-wiki-images/master/Setup_Example_img/Merge_progress.png) to auto merge the code when build is successful.
Look at the Jenkins Gitlab plugin README for more information and advanced setup, like test in your build the result of the merge, etc.
So Gitlab will know whether to merge to branches or not?
GitLab itself does not have to be aware of this test result to, on its own decide to merge or not.
Your Jenkins job should, it the test is successful, call the right GitLab API
in order to accept the MR (Merge Request).
I am migrating my old Jenkins free-style job to multi-branch pipeline. I also want to use GitLab hook with them.
My problem is the branch detection. I am doing it manually but I want it to be automatic: when a new branch is pushed to git, GitLab trigger a Jenkins job that trigger the branch detection if the branch parameter from GitLab is not known for Jenkins at the moment. Is this possible to do it or doesn't this exist?
FYI: I tried to launch the multi-branch pipeline job but Jenkins says:
ERROR: No parameterized job named XXX found.
Enable "Build Periodcally" in your multibranch job configuration and the branch indexing will automatically started.
What you really need is a branch source plugin for GitLab with webhook integration, which is tracked as an RFE in JIRA.
Failing that, use a plain Git branch source and configure GitLab to send Jenkins notifications to /git/notifyCommit (IIRC) as documented on the Git plugin wiki. Need specify only a url, no other details. The branch indexing this triggers should both detect new or removed branches, and changes to the head of an existing branch, and schedule builds accordingly.
You can set webhook in GitLab for push events and URL like http://<yourserver>/git/notifyCommit?url=<URL of the Git repository>.
See https://wiki.jenkins-ci.org/display/JENKINS/Git+Plugin#GitPlugin-Pushnotificationfromrepository
GitLab notifies Jenkins on push events which should trigger branch detection also for multibranch pipeline.
I didn't receive the answer I wanted and I ran into this issue today that answered the question :
https://github.com/jenkinsci/gitlab-plugin/issues/298
TLDR: Multi-branch pipeline are not supported yet to be triggered by gitlab commit easily. There is a workaround. Look at the link above.
To give some context the question is about GitLab and Jenkins setup.
I know how to setup a web hook, I know how to setup a job to be triggered by the hook. The problem is that I need to have multiple jobs and only a single entry-point (parent job) trigger for them.
The downstream jobs at the same time need to be git repo aware so I have to set repo url for them. This causes them to be triggered independently by the hook and I don't want that as this means that they are triggered twice.
On the other hand if I don't configure repo url on a downstream job and the parent job triggers it, it fails as it is not able to do a checkout.
I may try to hack around with some 'execute shell' build step, I believe it's not a valid way to go. Has anybody a good tip how to solve that?
For the reference here is the GitLab Jenkins plugin documentation according to which:
Plugin will parse the GitLab payload and extract the branch for which
the commit is being pushed and changes made. It will then scan all Git
projects in Jenkins and start the build for those that:
match url of the GitLab repo
match the configured refspec pattern if any
and match committed GitLab branch
I tried playing around with different settings, without a great result though.
For the project you want to get only local triggers, just enable Don't trigger a built on commit notification in the Additional behaviours of git plugin.
(https://github.com/elvanja/jenkins-gitlab-hook-plugin/issues/11#issuecomment-35385032, as you actually have discovered).
But a better solution could be to make your downstream jobs reference the repository locally cloned by main job (not sure if actually possible), so the plugin will never consider them for schedule a build, as the git url don't match.