I maintain the GitLab plugin, but unfortunately in the last few months I have had no time to dedicate to it. I have been hoping that a capable and motivated person would offer to take over maintaining it, but so far that has not happened. I have also lobbied CloudBees a little bit to invest some resources in this specific feature area, but although they have been positive about the idea, nothing has been committed. So I'm glad to hear that you're interested in at least working on this feature area, it is one I have wanted to see added for a long time.
You say that "basically multibranch pipeline support is non-existent," but IMO this is a bit of an exaggeration. The existing multibranch support is admittedly imperfect because all it does is trigger branch indexing and let Jenkins figure out which branches have changes and should be built. This is not ideal because branch indexing is a somewhat expensive operation, and also as you point out none of the environment variables sent by the webhook are accessible in the job. Having said that, this support has been in the plugin for a few years now and people are definitely using it. In my opinion, the path to improving this support is to implement Branch Source support for GitLab. In addition to making Multibranch jobs work better, this would also let Jenkins support the same "org folder" functionality that can already be done with GitHub and Bitbucket. There was someone working on this, but the work has stalled and the person has gone silent. The original plan was that we were going to build this functionality into the existing GitLab plugin, but in recent conversations I have had with other folks, I have come to the conclusion that that would be a bad design, one that goes against the established paradigm of the GitHub and Bitbucket integrations. Both of those have separate trigger, API, and branch source plugins (github, github-api, github-branch-source). https://github.com/jenkinsci/gitlab-plugin/issues/499 discusses this whole proposal, and has links to the incomplete gitlab-branch-source plugin code. I've just seen your comments there (sorry again that I have been unavailable recently), so I'm happy to continue the conversation in that forum. I just wanted to share more widely what the state of the plugin and past proposals for this feature work are. Thanks again for your interest in contributing! On Monday, April 1, 2019 at 5:45:11 PM UTC+11, Parichay Barpanda wrote: > > Hi all, > > I am preparing a proposal to add Multibranch Pipeline support to the > Gitlab plugin. Existing Gitlab plugin does not support Multibranch pipeline > builds in a way that it enables build triggers but cannot configure the > variables (basically multibranch pipeline support is non-existent) - the > API doesn't support it. But there are a lot of existing users that use the > GitLab plugin at the moment and I fear API changes might break binary > compatibility. > > My suggestions is to develop 2 new plugins: a *Gitlab API plugin* and a > *Gitlab > SCM Plugin*. > > 1) *Gitlab API plugin *which, very similar to Github API plugin, wraps > the Gitlab Java API. > > 2) *Gitlab SCM plugin* which will be a major design overhaul version of > existing Gitlab Plugin to accomodate both pipeline and mulitbranch pipeline > jobs along with other type of job configurations. > > I have 2 ways to implement this: > > Method 1: > 1) I am thinking freestyle jobs will be deprecated in the future in favor > of pipeline jobs. Gitlab plugin supports freestyle builds, so as long as > freestyle builds are favoured the existing Gitlab plugin will support it. > 2) Focusing on just pipeline will ease the task of designing API and > handling the complexity due to which all the SCM plugins are divided into > two i.e. <scm> plugin and <scm>-branch-source plugin. > > Method 2: > 1) If freestyle jobs are important and cannot be compromised then modify > the Gitlab plugin to add multibranch pipeline support and find a way to > take out Gitlab API and wrap it in a separate plugin. I haven't been able > to figure out how much security risks and backwards compatibility will be > involved in this method. Need someone with experience tell me about this. > > *Main Objective of this proposal*: Just have one SCM plugin which does > all type of jobs and remove users' confusion of having 2 separate SCM > plugins and code duplication. > > Need your feedbacks so that I can finalise which method to carry forward > and start working on this proposal. > > Thanks. > > Regards, > Parichay (baymac) > -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/1ef3514a-7a2f-44aa-b7ba-86be03a2d061%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
