Git – Publish Jenkins Job build status to Gitlab commit with Jenkins Pipeline job

gitgitlabJenkinsjenkins-pipeline

I have integrated my Gitlab CE version 9.3.5 with jenkins version 2.60.1 .

I am able to trigger builds with Gitlab webhook and publish the result back to the commit with a jenkins freestyle job.

I was wondering how can i achieve the same with jenkins pipeline job as every article on the above integration works with jenkins freestyle job.

Best Answer

If I follow the documentation about the Gitlab Jenkins plugin, you should be able to use the gitlabCommitStatus method which will publish the status of the build steps declared after (here is an example from the doc) :

node() {
    stage 'Checkout'
    checkout <your-scm-config>

    gitlabCommitStatus {
       <script that builds, tests, etc. your project>
    }
}

If this is not enough, you also have the possibility to use updateGitlabCommitStatus name: 'build', state: 'pending' to control more precisely which state you're sending to the gitlab instance.

Related Solutions

Git – “theirs” version of “git merge -s ours”

A similar alternative is the --strategy-option (short form -X) option, which accepts theirs`. For example:

git checkout branchA
git merge -X theirs branchB

However, this is more equivalent to -X ours than -s ours. The key difference being that -X performs a regular recursive merge, resolving any conflicts using the chosen side, whereas -s ours changes the merge to just completely ignore the other side.

In some cases, the main problem using -X theirs instead of the hypothetical -s theirs is deleted files. In this case, just run git rm with the name of any files that were deleted:

git rm {DELETED-FILE-NAME}

After that, the -X theirs may work as expected.

Of course, doing the actual removal with the git rm command will prevent the conflict from happening in the first place.

Git – Move the most recent commit(s) to a new branch with Git

Moving to an existing branch

If you want to move your commits to an existing branch, it will look like this:

git checkout existingbranch
git merge master
git checkout master
git reset --hard HEAD~3 # Go back 3 commits. You *will* lose uncommitted work.
git checkout existingbranch

You can store uncommitted edits to your stash before doing this, using git stash. Once complete, you can retrieve the stashed uncommitted edits with git stash pop

Moving to a new branch

WARNING: This method works because you are creating a new branch with the first command: git branch newbranch. If you want to move commits to an existing branch you need to merge your changes into the existing branch before executing git reset --hard HEAD~3 (see Moving to an existing branch above). If you don't merge your changes first, they will be lost.

Unless there are other circumstances involved, this can be easily done by branching and rolling back.

# Note: Any changes not committed will be lost.
git branch newbranch      # Create a new branch, saving the desired commits
git reset --hard HEAD~3   # Move master back by 3 commits (Make sure you know how many commits you need to go back)
git checkout newbranch    # Go to the new branch that still has the desired commits

But do make sure how many commits to go back. Alternatively, you can instead of HEAD~3, simply provide the hash of the commit (or the reference like origin/master) you want to "revert back to" on the master (/current) branch, e.g:

git reset --hard a1b2c3d4

*1 You will only be "losing" commits from the master branch, but don't worry, you'll have those commits in newbranch!

WARNING: With Git version 2.0 and later, if you later git rebase the new branch upon the original (master) branch, you may need an explicit --no-fork-point option during the rebase to avoid losing the carried-over commits. Having branch.autosetuprebase always set makes this more likely. See John Mellor's answer for details.