Hi Owen, I am really glad this thread got your attention. Firstly, I would like to apologise for being critical about the multi-branch pipeline support in Gitlab Plugin. I acknowledge a lot of hard work and time must have been dedicated to develop the Gitlab plugin. I have been spending time with the codebase learning how it could be improved, I find it very well written and readable. Lots of stuffs in there to learn from.
Secondly, I would like to explain my idea for adding the multi-branch support. I understand the convention for SCM plugins is to implement 2 different plugins (<SCM> and <SCM-Branch-Source>), but the community also understands this is an accident of history. From my discussion with one of the project mentors, Joseph Peterson (@casz) we came to a conclusion that the branch source functionality (folder org type multi-branch pipeline support) can be implemented inside the Gitlab Plugin. So, in order to remove confusion from user point of view we want to implement everything in one plugin. My conviction is this wouldn't cause much disruption of existing conventions because we are only making things simpler. And if we can have a proper documentation of the history of the plugin development then there shouldn't be any issue. Just one plugin to solve all your GitLab related continuous integrations. Our aim is also to separate the API from GitLab Plugin and create a new API plugin like GitHub API plugin. Now the question is, if we do it, will it break GitLab plugin's existing support? This area needs a little time for research and discussion. I'll come up with a more concrete proposal containing the possible tradeoffs. I'm working on it currently. Other areas of improvement for GitLab plugin is implementation of new SCM API filters (or traits) rather than having filters inside GitLab plugin. This way other plugins can take the advantage of extending the Gitlab plugin and create their custom filters using the same SCM API. Btw this idea is one of the GSoC ideas. You can find the Mentor's proposal here- https://jenkins.io/projects/gsoc/2019/project-ideas/gitlab-support-for-multibranch-pipeline The progress of my detailed proposal can be found here- https://docs.google.com/document/d/1YpuCC129U8KPXAwiXRXQ_4XWuLursPGl3rzQjz43-CY/edit?usp=sharing Please feel free to drop your comments and suggestions in the Google doc. Thanks. Regards, Parichay (baymac) On Thu 4 Apr, 2019, 12:03 Owen B. Mehegan <omehe...@gmail.com wrote: > 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 jenkinsci-dev+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/jenkinsci-dev/1ef3514a-7a2f-44aa-b7ba-86be03a2d061%40googlegroups.com > <https://groups.google.com/d/msgid/jenkinsci-dev/1ef3514a-7a2f-44aa-b7ba-86be03a2d061%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- 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 jenkinsci-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAD0DWAOCPPL_bxd%3DaRNcr5kC5g6NY9F9Qa6nnmBTa4R8h46MHQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
