Will not install with Jenkins ver. 1.520 about jenkins-gitlab-hook-plugin HOT 12 CLOSED

Hi!
Currently the best workaround is to go with Jenkins v1.518.
You can see @ jenkinsci/jenkins.rb#82 (comment) that the ruby runtime still has issues with the latest Jenkins version, so I am afraid that until that is resolved, there will be no help here either. I've detailed the workaround flow here #10 (comment), so maybe that can help. Maybe you can even skip the ruby runtime fix since the release of v0.11 (it is no longer a snapshot).
Let me know how this goes...

from jenkins-gitlab-hook-plugin.

@elvanja is right, ruby-runtime 0.11 has an issue with Jenkins v1.519+. This is not a bug with the Gitlab Hook plugin, but apparently it's a bug with Jenkins. The only workaround is to downgrade to Jenkins v1.518.

from jenkins-gitlab-hook-plugin.

OK. Thanks. I have yum downgrade'ed to version 1.518, and all is good in the world. Thanks for the help.

from jenkins-gitlab-hook-plugin.

You can keep an eye on this and related issues, I'll close them once the ruby runtime problem is solved. Glad to help :-)

from jenkins-gitlab-hook-plugin.

@derekmaciel Hi Derek. What are your thoughts on Gitlab CI? Can it be used in continuous deployment model?

from jenkins-gitlab-hook-plugin.

@colddata I am very new to continuous integration, but I wanted to try incorporating it into my workflow. I really just wanted it to be able to run some tests, move some files, etc. While I could have done this in my git repositories post-update hook, I wanted to be able to easily modify the scripts as well as to see if they failed or not. I tried Jenkins, but it seemed too complex for what I wanted, and I couldn't get the gitlab-hook plugin to work, so I tried Gitlab CI.

While there are tons of documentation on Gitlab itself, there isn't any mention of documentation or a User Guide for Gitlab CI. Thankfully, I was able to figure it out as I went along. Jenkins is much easier to install with a simple sudo apt-get install jenkins but the installation for Gitlab CI was made a lot easier with the extensive installation guide.

If you want a CI solution that integrates very well with Gitlab, then I would suggest giving Gitlab CI a try. You only have to simply make a project in Gitlab CI, enter in the branches you would like to trigger builds, and add the key to your Gitlab repo to allow builds on every git push. However, if you want something more complex, then Gitlab CI is probably not for you. For the people who want fancy code coverage graphs or something, while there are Jenkins plugins for that, there are no plugins for Gitlab CI. However, it works great for me.

he only issue I had is that I wanted to run different scripts depending on which branch was pushed. When I pushed to the staging branch, I wanted it to deploy to staging, and when I pushed to the master branch, I wanted it to deploy to production. However, I found a trick to get it to work easily, so I am happy. Now I have a lot to learn to get a system to allow me to automatically deploy to staging and production, rather than me doing it manually with FTP.

Edit: comment got prematurely posted when I was only a few sentences in. Hope this helps!

from jenkins-gitlab-hook-plugin.

@derekmaciel Thanks a lot for such an extensive write-up! I was also in the process of installing gitlab-hook on jenkins 1.520 when it bombed out on me with the same ruby runtime error. Then I saw your post and decided to give Gitlab CI a try as well. I am not looking for anything fancy - just basic stats for each build, tracking build versions and then being able to deploy approved builds to staging and prod (this can happen as soon as there is a commit to either our master or prod branch that tracks our prod releases). I love the simplicity of Gitlab CI and hopefully I'd be able to script around to fulfill the missing pieces. My biggest concern right now is how to trigger a build upon accepting a merge request. Not sure if this is doable in Gitlab CI yet.

What trick did you end up using for deploying to staging vs. production, if you don't mind?

from jenkins-gitlab-hook-plugin.

@colddata As per a commit to the Gitlab CI core a few months ago, all build "shells" have access to the CI_BUILD_REF environment variable, which will be the name of the branch that triggered the build. Then I just added in a quick if-statement to my ant script -- if CI_BUILD_REF was master, then do something, if it was staging... etc.

As for your issue with triggering builds upon accepting a merge request, I'm not sure why that is not working for you, since it works for me. I created a fake repository, made some commits to it in master and pushed it to Gitlab, which triggered a build. Then I made some commits in a staging branch and pushed it, which again triggered a build. Then I Merge Requested myself to merge staging into master, and once completed, that triggered a third build.

The Merge Request screen, which helpfully tells you the build status of the branch requesting to be merged:

The project in Gitlab CI, showing that the Merge Request has its own build:

from jenkins-gitlab-hook-plugin.

@derekmaciel Nice. Having CI_BUILD_REF will definitely help. Please note, I haven't actually played with Gitlab CI yet as I've just installed it about an hour ago and still finalizing the config. As far as the Merge Requests go, we would prefer to trigger the CI when the "Accept" button is pressed and before the code is committed to master. We want to have commits on the master only if they've passed the CI tests, so not sure if there is a way to hook to the "Accept" button click event or not. I guess a workaround could be just to let the push to master happen on an accepted merge request, kick off CI and then delete this commit from master if the build failed-- making it look like it was never their in the first place. But if there was a way to hook in to the "Accepted" event somehow, that would be rather a preferred solution. Hopefully, this makes sense.

from jenkins-gitlab-hook-plugin.

@colddata You're overthinking it. A merge request merges two branches of the same repo, lets say staging and master. If Gitlab CI is watching both, then when you add a commit to staging, it'll run a test on that. When you later Merge Request that commit into master, you don't need to run the tests again. It already had the tests run when you first committed it into staging. When it is merged into master, that counts as a commit into master and so the tests will run again.

from jenkins-gitlab-hook-plugin.

@derekmaciel Perhaps I am overengineering it. We plan to have developers working on feature branches only and no one is allowed to do a direct commit to master. Commits to master can be requested only via a merge request. This is why I was also thinking of running a second CI when this merge request was being accepted, since I was not sure how soon the person responsible for the merge request gets to it. If this request sits there for some time while there are other merge requests being accepted, I am afraid in this case it may no longer be a fast forward merge on the master. Does this make sense?

P.S. We have two branches: 1) master that tracks the latest development line and contains only production shippable code and 2) prod branch that tracks production builds (since not everything on master can be released by the business to production right away).

from jenkins-gitlab-hook-plugin.

You can also have tags to denote production related state. E.g. with Jenkins there is Release plugin that does just that for Maven projects, but I believe you can find similar ones for other systems too.

As for the master branch rule, perhaps the best place is just have a git hook that will recognize merge commit (perhaps by user) and allow it or refuse it.

from jenkins-gitlab-hook-plugin.