jenkins-gitlab-merge-request-builder-plugin
jenkins-gitlab-merge-request-builder-plugin copied to clipboard
timols
Consider joining forces with gitlab-plugin
I'm one of the maintainers of the Jenkins GitLab plugin (https://wiki.jenkins-ci.org/display/JENKINS/GitLab+Plugin). From what I can tell, that plugin provides the same functionality as this one, plus a few other features. We have a new lead maintainer who is working on a significant redesign of the plugin, including both code cleanup and some new features. At the same time, the core Jenkins community is encouraging people who maintain similar plugins to consider joining forces around a single one, both to reduce user confusion ("Which of these plugins should I use?") and to increase quality of one codebase. This seemed like a good time to suggest that we combine our plugins and work together on supporting GitLab in Jenkins. Thanks!
I'd like that. It confused me and my colleagues a lot having two similar projects. I currently use the merge-request-builder but also used in another project the GitLab-Plugin.
Certainly not opposed to the idea!
Considering I have the java-gitlab-api project as well to maintain, I'm ok with suggesting folks use whichever plugin has an active maintainer.
@timols from reviewing the description of your plugin, my impression is that it only triggers on merge request events, and upon completion just comments on the MR. Are there any other features I missed?
The GitLab plugin I help maintain can also trigger on pushes or tags, can accept merge requests if the build is successful, and can filter branches to only run or not run in specific cases. If I'm understanding correctly that our plugin encompasses the features of yours, plus some additional ones, I would propose that we 'EOL' your plugin and direct people to use the other one.
I say that as a Jenkins community guy, not as a plugin maintainer. I've been part of the Jenkins core group that has been looking for cases where >1 plugin support the same or similar features, and encouraging them to combine efforts so that there is less confusion in the plugin ecosystem.
Let me know what you think about this, and we can coordinate/support a transition if you want to go that way.
@omehegan it will also perform a build using the gitlab web hooks, or any other git conditions that apply, such as a tag etc. In essence, it is very similar to the gitlab-plugin. The documentation is probably out of date with the new features that have been added.
In any case, I'm ok with directing users to use an alternative plugin since I don't actively maintain this plugin, instead relying on community contributions to add new features.
What would you propose as a transition?
@timols https://wiki.jenkins-ci.org/display/JENKINS/Deprecating+a+Plugin has the steps to deprecate a plugin. It would remove it form the Update Center, so people wouldn't be able to install it anymore. That might be more extreme than you want, though, given that the plugin works fine. Some people might prefer it for one reason or another.
Alternatively, you could just put a note at the top of the README, and in the plugin's wiki page, saying that the plugin is no longer maintained and suggesting that people use gitlab-plugin instead.
This plugin has features which are not available in gitlab-plugin. Therefore, I don't think it is appropriate to deprecate it until gitlab-plugin has been able to replicate this functionality, since otherwise it would prevent users of this plugin from using the working functionality which they might depend on, if they do not want to use a deprecated plugin.
@CSchulz, I'm currently using this plugin, but things broke after my recent Jenkins and Plugin upgrade (there are pending issues, e.g. #184). So I was checking out the gitlab-plugin, but it didn't work out for me either.
I have Jenkins in a corporate LAN, but Gitlab on public internet without access to Jenkins, that means I can only poll and can't have any hooks in Gitlab to notify Jenkins. gitlab-plugin doesn't seem to support this scenario, in contrast to this plugin which has a build trigger that uses Jenkins Timers to poll Gitlab. I'm not particularly fond of that approach as it is rather unstable - once a trigger fails for some reason, it won't get reactivated without a Jenkins restart.
It seems like the solution might be the gitlab-hook plugin in combination with the gitlab-plugin, but for some reason, it gets a "client timeout exception" without any details in tomcat log on connection test...
Long story short: As long as I don't have a solution to trigger my build with gitlab-plugin without using post commit hooks, I can't use it and it won't replace this plugin for me...
One feature that this plugin has, and gitlab-plugin does not, is the ability to work across firewalls. Because this plugin can fall back on a poll mechanism, it does not require webhooks. Unfortunately gitlab-plugin requires webhooks and is therefore unsuitable for many corporate situations. It has been stated that gitlab-plugin will not support polling in the future, so this plugin is still useful.
One feature that this plugin lacks but gitlab-plugin has, is updating the Build Status with the build result. This causes the "Build" tab to appear in the Merge Request, with a record of all builds triggered by commits in that MR. This plugin doesn't seem to do that, and it's a useful feature to have.
One more feature gitlab-merge-request-builder has and gitlab-plugin does not, is the ability to clone via http(s) instead of ssh.
As @DavidAntliff stated, it is not common for many corporate environment which permit ssh connection...
@tomgoto I don't understand that comment. The gitlab-plugin does not handle cloning the repo, it only handles triggering the job based on the webhook from GitLab. The regular Git plugin is what actually does the clone, and AFAIK it supports cloning via https.
@tomgoto to be clear, I'm referring to the mechanism that a privately hosted Jenkins might communicate with an external GitLab. Because gitlab-plugin relies on webhooks to do this, and has no support for polling, this setup is not possible (AFAIK) without some sort of additional NAT/firewall traversal, as the web hook from GitLab is unable to be received by Jenkins. Therefore this plugin has an advantage here.
Thank you , @omehegan. I misunderstood plugin's behavior. I thought cloning via http(s) was brought by merge request builder plugin.
Correct me if I'm wrong. But this plugin is polling GitLab for changes, while GitLab plugin is triggered by Jenkins CI Service.
That means this plugin works with the free GitLab Community Edition and GitLab Plugin only works with GitLab Enterprise Edition.
@tomasbjerre that's incorrect. Gitlab-plugin is triggered by GitLab webhooks, and can be used with either CE or EE.