<!--IssueSummary start--> <details> <summary> Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards. </summary> - [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=363687) </details> <!--IssueSummary end--> <!-- This template is a great use for issues that are feature::additions or technical tasks for larger issues.--> ### Proposal Tagging jobs allows teams to select which jobs are executed on specified runners. Today `tags` can be set globally within the root `.gitlab-ci.yml` by using the [default parameter](https://docs.gitlab.com/ee/ci/yaml/#default) ``` stages: - security_scanning default: << # Specifying global runner to use based off `tag` tags: - docker security_scans: stage: security_scanning trigger: include: - local: ".gitlab-ci/security.yml" ``` 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 triggered (child pipeline) jobs and the workaround is to explicitly define the global `tag` within each child pipeline yml file included `.gitlab-ci/security.yml` ``` variables: SECURE_LOG_LEVEL: debug SEARCH_MAX_DEPTH: 10 default: << # Specifying global runner once more as its not inherited from root .gitlab-ci.yml tags: - docker include: - template: SAST.gitlab-ci.yml - template: Dependency-Scanning.gitlab-ci.yml - template: Security/License-Scanning.gitlab-ci.yml - template: Secret-Detection.gitlab-ci.yml ``` <!-- Use this section to explain the feature and how it will work. It can be helpful to add technical details, design proposals, and links to related epics or issues. --> I believe it would be a nice addition to allow default parameter inherency for triggered jobs (child pipelines) especially pipelines that have a large numbers of triggered jobs used. This feature would prevent duplication of effort updating each child yml included and allow for less complexity and greater standardization across included pipeline templates, however you could choose to allow the capability to override the global parameter at the child yml level. <!-- Consider adding related issues and epics to this issue. You can also reference the Feature Proposal Template (https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab/issue_templates/Feature%20proposal%20-%20detailed.md) for additional details to consider adding to this issue. Additionally, as a data oriented organization, when your feature exits planning breakdown, consider adding the `What does success look like, and how can we measure that?` section. --> <!-- Label reminders Use the following resources to find the appropriate labels: - https://gitlab.com/gitlab-org/gitlab/-/labels - https://about.gitlab.com/handbook/product/categories/features/ -->