> A tag created through the GitLab web GUI is directly connected to `git tag` It appears you may be suffering from the same confusion (or perhaps you're not aw

> A tag created through the GitLab web GUI is directly connected to `git tag` It appears you may be suffering from the same confusion (or perhaps you're not aware of the feature), I'm talking specifically about gitlab-ci tags https://docs.gitlab.com/ee/ci/yaml/#tags https://docs.gitlab.com/ee/ci/yaml/#tags That has nothing to do with git tags, but one could be forgiven for believing that's the case when the documentation exacerbates this confusion. From the docs you just linked > only defines the names of branches and tags for which the job will run "tags" in that sentence has nothing to do with git tags but is actually referencing a gitlab-specific job tagging feature. It's very confusing. > I think you should refer to the manual. I have. The tools provided are not sufficient to accomplish the examples I have described. I'm happy to be proven wrong because it'd actually be quite useful to me. Can you direct me to how I might trigger a job only on tagged commits pushed to the master branch? As far as when/except/only etc, they are not able to introspect on variables or conditions within the context of the job runner, they can only react to gitlab-specific signals like the success or failure of other jobs, I can't do something like "build, run unit tests, run eslint, run flow type checker, deploy but only if nothing else failed, except eslint which is only a soft requirement but not a deployment blocker". Any failure in one job is a failure for all jobs unless you make it explicitly the inverse which still doesn't give you intelligent control over the jobs.