Expose a gitlab object to components, as a safer alternative to predefined CI variables

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

• Close this issue

Release notes

Problem to solve

Users can override almost every CI/CD variable, even predefined ones. This presents a problem for:

• component authors, as any predefined variable is implicitly part of their public API. It also limits the audience of components depending on which variables are used in which way (see next concern)
• platform builders, who want to write re-usable software while ensuring the security of their pipelines. For example, being able to override CI_REGISTRY dynamically when running a pipeline is inherently insecure

Proposal

Create a first-party gitlab object that could be used in the same way as inputs, containing most of GitLab's predefined variables:

• Anything project specific or more generic should be possible and considered for inclusion, but e.g. variables specific to the job or pipeline would not be available.
• This inherently rules out most predefined secrets, because they are mostly job specific, but I think for MVC we might want to leave all of them out. E.g. CI_DEPLOY_PASSWORD is project-specific, but should still not be included.

Intended users

Feature Usage Metrics

Does this feature require an audit event?

This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.