MVC: Templates Subdirectory for Partner Managed CI / CD Integrations

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

Proposal

Many GitLab partners are focused on integrating with CI / CD.

Generally this includes gitlab ci yaml that is published on blogs, in documentation and other places.

This gives rise to multiple problems basically due to lack of a single source of truth (SSOT):

  • It is hard to find.
  • It is hard for the community to distinguish best practice efforts at creating GitLab CI integration by a partner from the many search results they may find.
  • It is hard for GitLab and the community to contribute and suggest integration improvements to a partner authored integration.
  • It is hard to identify best practices.
  • Since this code is not considered part of the partner's solution, it is frequently non-working, challenging to implement and unmaintained.
  • It frequently does not follow GitLab CI best practice, especially in regard to compatibility with AutoDevOps and GitLab GitLab report artifacts (like sast or code quality).

If partners are encouraged to manage the code - including fix and enhancing it when the solution changes, the entire community benefits.

This proposal is to create a special directory under https://gitlab.com/gitlab-org/gitlab-foss/-/tree/master/lib/gitlab/ci/templates

For example: "templates/PartnerManaged/Hashicorp" would allow CI Yaml as follows:

include:
  - template: PartnerManaged/Hashicorp/Terraform.yml

There are many collaborative benefits to GitLab, the community and the partner by establishing a SSOT location for managed templates:

  • The existing, partner related template repository code could be more actively managed by the relevant partner. (partner contribution)
  • It immediately makes the code available to the global GitLab ecosystem - including on self-hosted instances. (GitLab Benefit to CI/CD integration partners)
  • It encourages partner integration code to be developed the same way that GitLab develops it's own devops integrations for SAST - using the same stages, disablement parameters, workflow inclusion rules and artifact report formats. This makes the partner code more likely to be compatible with autodevops and GitLab MR assistance can help give suggestions to be more compatible.
  • It signals to the GitLab ecosystem that the code here is more likely to be best practice. The fact that it does this by the pathname alone is a significant advantage in a coding ecosystem.
  • It encourages partners to active management in their integration code.
  • It encourages community contribution to partner managed code due to visibility.
  • It encourages GitLab review for best practice.
  • By using a subdirectory per partner it allows multiple similar examples.
  • Partners and GitLab could be listed as codeowners as appropriate.
  • It opens the door to defined standard practices and requirements around CI CD integration code to ensure quality experiences by all GitLab users.
  • It connotes a shared responsibility model for this code so that GitLab does not appear sole responsible for its operational qualities

The above list can be made more concise via collaboration on this issue.

There may need to be a business process for the initial establishment of a PartnerManaged subdirectory.

We are working on a CI/CD integration that would benefit greatly from this concept.

This MVC is a refinement iteration to add value to the GitLab technology partnership concept here: https://about.gitlab.com/partners/integrate/

Edited by 🤖 GitLab Bot 🤖