Support CI job templates

Problem to solve

Often times central teams which controls GitLab CI would like to create a standard template (e.g unite tests, security test, AWS CLI) to be used by different business units within their organization.

While this is possible today using the include keyword the discoverability of this feature within large organization is challenging:

  • Teams are not aware of the available includes in their organization
  • When looking at GitLab CI with the include keyowrd users are unable to understand what does the include file is doing
  • Updating an include file might break their pipeline

Intended users

  • Sasha (Software Developer)
  • Devon (DevOps Engineer)
  • Simone (Software Engineer in Test)

User experience goal

A central team should be able to:

  • Create and maintain a custom template (or even a job).
  • Update it with description, version, and any additional information in order for it to run.
  • Every team that interacts with pipelines should be able to see and use any of the available custom templates.
  • When a new version of a template is available users would need to opt-in

Proposal

  • While users write their pipelines they should be able to see/browse through a list of available templates
  • When selecting the desired templates we should add it to their pipeline configuration, so in reality, users should be able to use those templates as building blocks for creating their pipelines

Further details

When applying a template should we incorporate the full YAML definition or just reference to the YAML file (e.g. using the includes keyword)? IMO, both approaches are valid, using a reference will make sure templates always keep up to date with the latest and greatest if it been managed by a central team. Using copy paste YAML sections to a pipeline configuration would assure that a pipeline would never change.

Further enhancment

  • This feature can be enhanced by identifying the files/language/variables the user is using and provide smart suggestion to be used (e.g if we can detect the user is using AWS we can provide AWS templates/jobs/scripts to be used)
  • Enforcing specific templates to any running pipeline

Permissions and Security

There should be a permission model where maintainers or owners are able to add custom jobs

  • Add expected impact to members with no access (0)
  • Add expected impact to Guest (10) members
  • Add expected impact to Reporter (20) members
  • Add expected impact to Developer (30) members
  • Add expected impact to Maintainer (40) members
  • Add expected impact to Owner (50) members -->

Documentation

Availability & Testing

What does success look like, and how can we measure that?

What is the type of buyer?

Is this a cross-stage feature?

Links / references

Edited Dec 27, 2020 by Dov Hershkovitch
Assignee Loading
Time tracking Loading