Consider joining forces with gitlab-plugin about gitlab-hook-plugin HOT 5 CLOSED

When I started using a gitlab plugin nearly two years ago, I choosed this one because I get some problems (which I don't remember) with gitlab plugin. Then I started implementing features I needed and eventually become the maintainer of this plugin.
Regarding joining efforts, I see it quite difficult. First of all, one plugin is written on ruby and the other on java. One is a root action (configured at global Jenkins level) and the other one a trigger (configured at the project level). So both in language and approach are completely different.
Said that, I'm not against joining efforts, just saying that it will not be easy, and I do not see a clear path for it.

from gitlab-hook-plugin.

@javiplx thanks for replying :)

When I first started trying to use Jenkins with GitLab, I used this plugin. But I moved away from it because I did not like the fact that it relies (or relied, maybe this has changed) on the git repo as the key to decide which Jenkins job to trigger when a push happens. It would trigger every job which was configured to use the repo, when in most cases I only wanted one job to be triggered.

This is definitely a fundamental difference between the two plugins, and if it is a design that people prefer, I guess they might as well remain separate. Obviously I think it makes more sense to have GitLab explicitly trigger the job (or jobs, you can create more than one hook on the GitLab side), rather than have the plugin make assumptions about it, but that's just my opinion :)

from gitlab-hook-plugin.

Hi people!
I am not active on this plugin any more, but I do have a few cents to share.
Namely, this plugin I use in a dev shop with over 2000 projects on Jenkins, which all use it. But, the code is in Atlassians Stash, so Gitlab is not even in the picture any more.
That being said, the hook works for those projects as well, specifically because it inspects repo details, as opposed to Gitlab (and only Gitlab) triggering explicitely.
Seems OK to keep the idea, but at the same time, provisions can be made to help with the use case you described Owen.
Anyway, just my 5 cents...

from gitlab-hook-plugin.

Exactly what @omehegan dislike (a single endpoint for all gitlab projects) is exactly what I liked from this plugin. Moreover, the first feature I implemented, which was automatically create projects in Jenkins when no one matches the incoming payload, which came easily with the single endpoint. Although the project specific endpoint is also useful, and is actually implemented for the next release.
And as @elvanja says, actually there is very little gitlab specific in the plugin (except for the status notification), and I'm actually planning to implement parsing of github payloads, as I'm actually also using it.

from gitlab-hook-plugin.

It's fair enough. Then the only other thing I would suggest is, if you are moving towards making the plugin more neutral about the source of input data (I.e. not strictly a gitlab plugin), maybe you would consider renaming it to something that reflects that. This would help it attract more new users. We can close this issue :)

from gitlab-hook-plugin.