Enforce rules for tag-only Releases
Problem to solve
When a release
node references $CI_COMMIT_TAG
in the tag_name
, the job must be a tag only job, otherwise the $CI_COMMIT_TAG
will not be present.
Extracted from MR !19298 (merged)
When a Release
is a tag only job, the only: ['tags']
directive is mandatory. Refer !19298 (comment 259980806)
These include:
only:
refs:
- tags
only:
variables:
- $CI_COMMIT_TAG
rules:
- if: '$CI_COMMIT_TAG'
when: always
More information !19298 (comment 259989805)
Intended users
Personas are described at https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/ -->
Further details
During the review process of this MR, the question was raised about the necessity of this. !32528 (comment 353534766)
We currently perform static linting to avoid syntax errors in the gitlab-ci.yaml
, this is done mostly in the ci/config/entry/*.rb
code. The check proposed in this issue would check if a user is semantically correctly using the $CI_COMMIT_TAG
. Without this code the pipeline would just not execute the job if it was not correctly configured.
AFAIK we don't currently perform these types of checks for other variables, and to take this step takes us more into the area of guessing what the user might intend with the pipeline.
Such error could be useful to a user when the cannot work out why a pipeline is not behaving as expected. But at present we are not seeing user demand for this (AFAIK). If there is user demand for specific messages to help them debug pipelines, these could be built, and we should consider a wider framework on how to approach them