Skip to content

Define minimal CI config in project settings

Follow up from #14376 (closed) where we allowed CI config to be defined outside repo.

We accomplished that by allowing CI config path in the project settings to accept new syntax that is then translated to a minimal CI config under the hood.

# "http://example.com/generate/ci/config.yml" is translated to:
include:
  - remote: http://example.com/generate/ci/config.yml
# "my/path/.my-custom-file.yml@mygroup/another-project" is translated to:
include:
  - file: my/path/.my-custom-file.yml
    project: mygroup/another-project

By default, if the setting is left blank, the following CI config will be evaluated:

include: 
  - local: .gitlab-ci.yml

Problem to solve

We could turn this "implicit" layer of configurations to a more "explicit" layer defined via project configurations.

Project admins can use the full set of syntax to define a project-level CI config that can replace or extend the file-based CI configurations.

Intended users

Personas are described at https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/ -->

Further details

By replacing the existing CI config path with a text area of bounded size we could allow admins to:

  1. Enforce inclusion of specific templates:
include:
  - local: .gitlab-ci.yml
  - template: SAST.gitlab-ci.yml
  1. Lock version of outside-repo CI config
include:
  - file: .gitlab-ci.yml
    project: mygroup/another-project
    ref: v1.0.0
  1. Prevent pipeline from running on specific scenarios
workflow:
  rules:
    - if: $CI_COMMIT_TAG
      when: never

Proposal

We already have a translation layer where we take the CI config path from project settings and depending on its format (simple file path, URL or file@project) we transform to a minimal yaml file to be evaluated.

We would need to change CI config path to a Root CI config text area (limiting its max size). We can dynamically translate existing CI config path values to CI YAML using our existing translation layer by doing the following:

  • if Root CI config exists, evaluate it
  • otherwise use CI config path to generate and save Root CI config, then evaluate it

This way we can migrate all active projects to use this new form.

New projects should have a default value for root_ci_config in the form of:

include:
  - .gitlab-ci.yml

Permissions and Security

Documentation

This requires adding new documentation for Root CI config and deprecate CI config path

Testing

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

Admins should be able to modify Root CI config using any CI syntax.

What is the type of buyer?

Follow-ups

  1. We should deprecate first and then remove CI config path from project settings
  2. Lint the Root CI config when changes happen

Links / references

Edited by Fabio Pitino