<!--- Please read this! Before opening a new issue, make sure to search for keywords in the issues filtered by the "regression" or "bug" label: - https://gitlab.com/gitlab-org/gitlab/issues?label_name%5B%5D=regression - https://gitlab.com/gitlab-org/gitlab/issues?label_name%5B%5D=bug and verify the issue you're about to submit isn't a duplicate. ---> ### Summary Tagging jobs allows for granular control over which jobs are executed on which runners. In issue #16043, a suggestion was raised to allow for `tags` to be set globally, or configured as default options (which the resulting MR eventually settled on). When using `tags` as a [default parameter](https://docs.gitlab.com/12.6/ee/ci/yaml/README.html#setting-default-parameters), the value does not inherit to jobs that do not explicitly specify the tag to use. Is this working as intended? If so, the documentation should be updated to clarify that the default `tags` will not be inherited by jobs. The workaround is to explicitly define `tags` for each job, or to use job templates as was [mentioned in the original issue](https://gitlab.com/gitlab-org/gitlab/issues/16043#note_214880062) that lead to the merge request. This functionality was added in !20747. Premium customer facing this problem: [ticket 142554](https://gitlab.zendesk.com/agent/tickets/142554) (internal). ### Steps to reproduce Have a runner configured to only accept tagged jobs with `docker-dind` as the tag. A sample CI: ``` default: tags: ['docker-dind'] job1: tags: ['docker-dind'] script: echo "explicit tags" job2: script: echo "inherit tags" ``` `job1` runs as expected; `job2` holds indefinitely waiting for a runner. It is marked as "stuck" in the UI. ### Example Project I have a quick demo of project on GitLab.com using a specified runner, configured to only accept tagged jobs: https://gitlab.com/kevenhughes/default-tags [specific runner NqziYn6g](https://gitlab.com/kevenhughes/default-tags/runners/1434386), available tags are `cluster` and `kubernetes`. [CI has two jobs](https://gitlab.com/kevenhughes/default-tags/blob/1894e793cbd0edbbeed2931a280ae8aadf588dda/.gitlab-ci.yml), one which explicitly defines a tag, and one which relies on `default` to inherit a tag. The resulting pipeline, wherein job1 succeeds but job2 sits on hold indefinitely due to being untagged. https://gitlab.com/kevenhughes/default-tags/pipelines/106902940/builds ### What is the current *bug* behavior? CI config `default:tags` is not inherit by jobs which don't otherwise specify a list of tags. If this isn't a bug, but is working correctly by design, the [documentation](https://docs.gitlab.com/12.6/ee/ci/yaml/README.html#setting-default-parameters) should be clarified. ### What is the expected *correct* behavior? As a default config, it should be applied to jobs without an explicit definition of tags. ### Possible fixes My original thought was that `tags` is not set to `inherit: true` in [lib/gitlab/ci/config/entry/default.rb](https://gitlab.com/gitlab-org/gitlab/blob/cf39803b81f23cf2eba6eb5a7e653862ed92a63c/lib/gitlab/ci/config/entry/default.rb#L56-58)