GitLab team become a project maintainer for the jenkinsci/gitlab-plugin
Proposal
Customer is requesting that the GitLab team become a project maintainer for https://github.com/jenkinsci/gitlab-plugin.
Problem to solve
Our CI integration with Jenkins was recently crippled by what turned out to be a bug in the jenkinsci/gitlab-plugin that runs in Jenkins that causes the "updateGitlabCommitStatus" command to fail to send the status back to GitLab when certain data is written to the build pipeline's config.xml file. This has been documented in https://github.com/jenkinsci/gitlab-plugin/issues/992 and potentially fixed in a yet to be released patch, https://github.com/jenkinsci/gitlab-plugin/pull/1129.
This jenkinsci/gitlab-plugin is commonly used and referenced by GitLab for Jenkins integration with GitLab. Within the last year, this open-source project has lost its maintainers and is in need of a new one.
This would be a good issue to socialize with your product team as I'm sure this is affecting many other customers who rely on Jenkins for CI. It also highlights the need for GitLab to step up to become a project maintainer for this critical Jenkins integration project.
I understand GitLab wants everyone to use its CI product, but this is not always feasible for many companies, given their extensive investment in their Jenkins CI tooling. Having a working and effective integration with Jenkins is essential to signing on new customers (like us) to migrate to GitLab and ease into that CI ecosystem.
I would like to propose that GitLab take this up for these reasons
Why this matters
We use this for Jenkins integration, and it is outdated and was unmaintained in April and May. This led to the customer's upstream issues not getting resolved.
The plugin is required to use our GitLab integration. The docs say this as well.
It appears that the problem stems from the upstream project GitLab uses for Jenkins integration. Unfortunately, the project linked is hosted on GitHub, developed by a volunteer basis, and is not maintained by GitLab team members or affiliated with GitLab Inc
While GitLab team members and developers can submit a pull request to the GitHub project, it will be up to the upstream project maintainers whether they accept the change or not. This means that GitLab has a limited amount of influence and control over the upstream project's code base. Furthermore, this plugin was no longer maintained for a April and May. The plugin is being maintained again as of 1 month ago: https://github.com/jenkinsci/gitlab-plugin/commit/54335dee56bf11b3a8411921f2dca0b10653da51
The above reasons are why I am suggesting GitLab take a formal stake in becoming a project maintainer for that plugin, as it is in GitLab's own best interest to have a working integration with Jenkins.
Solution
We don't need to be the sole maintainers, but I do think it'd be helpful to have some path by which GitLab team members can contribute to the plugin. Our product's Jenkins integration is completely reliant upon this third-party jenkins-plugin
project, that we have zero control over. https://github.com/jenkinsci/gitlab-plugin. If a bug/regression is merged or security vulnerability is discovered the upstream project, it could impact hundreds of GitLab customers.
I'd say either we take some ownership, we build our own plugin, or we drop Jenkins integration support.
From a risk-management perspective, here are two really ugly situations that I can forsee if we continue to have zero control over this hard dependency for our Jenkins integration:
- breaking change introduced in third-party plugin, many if not all customers using Jenkins integration find that it breaks, solution = ???
- security vulnerability is disclosed and unpatched, or malicious code/backdoor inserted into the jenkins plugin codebase, GitLab customers who want to continue using Jenkins integration have to choose between security and functionality