Expose project tags to CI/CD jobs
Problem to solve
GitLab CI provides a large number of predefined variables (environment variables) to CI jobs. This includes information like the project name (CI_PROJECT_NAME
) and the project url (CI_PROJECT_URL
).
I would like project tags to also be exposed to CI jobs, perhaps as CI_PROJECT_TAGS
. CI jobs can then use this to customize their execution.
Target audience
Further details
I have standardized sets of GitLab CI jobs that projects mix in using the include feature in .gitlab-ci.yml files. For example, a project might have the following includes.
include:
- 'https://gitlab.transzap.com/devops/ci-cd/pipelines/raw/master/docker/docker-image.yml'
- 'https://gitlab.transzap.com/devops/ci-cd/pipelines/raw/master/docker/docker-compose-stack.yml'
- 'https://gitlab.transzap.com/devops/ci-cd/pipelines/raw/master/docker/aws-asg-hosts.yml'
- 'https://gitlab.transzap.com/devops/ci-cd/pipelines/raw/master/docker/psc-deployments.yml'
- 'https://gitlab.transzap.com/devops/ci-cd/pipelines/raw/master/angular/static-tests.yml'
- 'https://gitlab.transzap.com/devops/ci-cd/pipelines/raw/master/angular/dynamic-tests.yml'
In this list, docker-image.yml
contains jobs for building and testing Docker images, while docker-compose-stack.yml
contains jobs for bundling a Docker Compose based app and deploying it on Docker Swarm as a stack. Additional files are used to control the deployment details (aws-asg-hosts.yml
and psc-deployments.yml
), or add in extra test jobs specific to this type of project (angular/static-tests.yml
and angular/dynamic-tests.yml
).
The pipeline and jobs are structured to follow Auto DevOps, including the use of *_DISABLED
variables to selectively disable jobs.
In a previous version of this setup, the jobs in docker-image.yml
and docker-compose-stack.yml
were together in one file. Projects that only produced Docker images and did not have deployments had to disable non-relevant jobs by specifying variables like REVIEW_DISABLED
, DAST_DISABLED
, and PERFORMANCE_DISABLED
to stop those jobs from running. This became onerous to do, and was also problematic if new jobs were added that the projects now had to also disable. Splitting out the files solved that. But, in some projects this list becoming quite long and unwieldy.
My projects have tags like docker-image
and docker-app
. If these were available to CI jobs, they could be used to include/exclude jobs, similar to how Auto DevOps jobs use the GITLAB_FEATURES
variable to run security products jobs only if the feature is available based on licensing.
While this can potentially be accomplished through a normal CI/CD variable, I feel using project tags is cleaner for this use case. I use tags to describe the qualities of my projects (e.g., whether it's a Docker image or a Terraform configuration), and I want CI jobs to react to these qualities. Tags are also visible to all users, while CI/CD variables are only visible to maintainers or above.
Proposal
Expose project tags to CI jobs, perhaps as a variable named CI_PROJECT_TAGS
. Its value should be a list of tags, similar to how GITLAB_FEATURES
is a list of active features.
And, to be clear, this is about exposing GitLab project tags, not git tags.
What does success look like, and how can we measure that?
CI jobs can access the tags of a project through an environment variable.