Jenkins Gitlab Hook Plugin reorganized

The Jenkins Gitlab Hook Plugin received a major refactoring. The goal was to separate concerns from existing modules and to make the project testable. Github repo now contains Java binaries needed to run the rspec tests, but hopefully you’ll find the new organisation a bit more intent revealing and easier to follow.

I’ve used the use case approach, and extracted related services so now all the domain knowledge is contained within models sub folders:


The remaining models in the root models folder are all directly Jenkins related and left there so Jenkins can load them first and register the plugin and the related web hook correctly.

The entire domain knowledge is now also testable. I chose the rspec to run the tests and have created the related spec helped that loads all the Java dependencies and models from the root folder. To run the specs, you’ll need to setup JRuby so it runs in Ruby 1.9 compatibility mode. Just add the following switches to your JRUBY_OPTS environment variable: –1.9 -Xcext.enabled=true -X+0.

The v1.0.0 release has all the goodies, so feel free to upgrade your Jenkins environments.

Tagged , ,

4 thoughts on “Jenkins Gitlab Hook Plugin reorganized

  1. Hi, will you have in your plugin the escenario of merge_request, it will be great having some with the api consulting of gitlab recover url of the repo ??

    • elvanja says:

      Hi Juan, I’d like to help but I am not sure I understand the question. Can you elaborate please?

      • Alex Kurilo says:

        I’m not sure I got it correctly, but I’ll try.
        It would be nice to have a possibility to build merge requests within a parametrized builds as it happens with gerrit reviews. Gitlab fires its hook on push, plugin finds the branch that contains the latest commit and appropriate merge request and triggers the build with branch specification unless the previous commit in this branch equals to the current one.

      • elvanja says:

        Apologies for a bit late response. In any case, I must say that I no longer use this plugin for Gitlab integration. At my work place we actually use it for integration with Stash. But, if Gitlab offers some data in hook payload that could identify that it is a merge request flow, I guess something like that could be accomplished. Can you provide an example payload for such a case? And if you want to continue this conversation, may I suggest that you open up an issue on project’s Github page?

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: