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:
- Enforce inclusion of specific templates:
include:
- local: .gitlab-ci.yml
- template: SAST.gitlab-ci.yml
- Lock version of outside-repo CI config
include:
- file: .gitlab-ci.yml
project: mygroup/another-project
ref: v1.0.0
- 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 saveRoot 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
- We should deprecate first and then remove
CI config path
from project settings - Lint the
Root CI config
when changes happen