Feature Request: add predefined values for CI/CD Catalog project path, component name, and version
Release notes
Enable CI/CD Catalog component portability by providing pre-defined interpolation values which specify information about the component.
-
$[[ component.path ]]
: path of the component's project -
$[[ component.name ]]
: name of the component -
$[[ component.version ]]
: version of the component
For a component included using the following block, these values would be my-org/my-component-project
, cool-component
, and 1.2.3
, respectively.
include:
- component: $CI_SERVER_FQDN/my-org/my-component-project/cool-component@1.2.3
Problem to solve
If a CI/CD Catalog component needs access to a resource provided by its own project, it needs to know the path to itself and possibly the version that has been included as well. Hard coding these values negatively impacts maintainability and portability.
As a concrete example, I have a component which needs to run within a specific Docker image. That Docker image is versioned along with the component. That's to say that component version 1.2.3
uses Docker image ${CI_REGISTRY}/my-org/my-component-project/cool-component:1.2.3
. Right now, I'm forced to hard-code the version number into templates/cool-component.yml
. It's error-prone and easy to forget that this value needs updated with every release.
Further, this project is currently on a self-hosted instance, but I'm considering open-sourcing it to gitlab.com. But I wouldn't be able to use the same project path on gitlab.com, so I'd have to maintain two slightly different versions on the self-hosted and public instances. That's more cumbersome than it should be and is an impediment to increasing the value of the public CI/CD Catalog.
Proposal
See description in the Release notes section.
Note that the proposed $[[ component.path ]]
and $[[ component.version ]]
roughly translate to $CI_PROJECT_PATH
and $CI_COMMIT_TAG
. But because those $CI_*
variables are relative to the project which includes the component, not the component itself, they can't be used.
I propose interpolation rather than new pre-defined variables because it is my understanding that the pre-defined variables wouldn't have a valid value at the time the component is included. But I'm not really concerned with the how of the technical solution. So long as these three values are made available, I'm probably OK with the approach.
Possibly related/impacted issues:
Intended users
- Allison (Application Ops)
- Rachel (Release Manager)
- Sasha (Software Developer)
- Janell (Enablement Advocate)