## Decision The rejection is being removed instead of rolled out. It breaks existing pipelines, including some that pass today. - Removal: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/255832 - Verified behavior and the correction to the original plan: https://gitlab.com/gitlab-org/gitlab/-/issues/607053 - Discussion: https://gitlab.com/gitlab-org/gitlab/-/work_items/607488#note_3837454051 Remaining work: delete the flag from the non-production environments once the removal merges. ``` /chatops gitlab run feature delete ci_reject_yaml_tags_in_inputs --dev --pre --staging --staging-ref ``` The sections below are the rollout plan that was followed. They are kept for history and are no longer active. ## Summary Roll out [rejecting YAML tags in CI/CD input values](https://gitlab.com/gitlab-org/gitlab/-/issues/607053), currently behind the `ci_reject_yaml_tags_in_inputs` feature flag. A value such as `!reference [.my-list]` passed to `include: inputs:` is rejected with `` `<input>` input: provided value cannot contain a !reference tag ``. - DRI: oyakovenko-ext - Team Slack channel: `#g_pipeline-authoring` - Feature flag type: `gitlab_com_derisk` - Introduced by: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/249492 > [!note] > Process and guidance live in the docs, this issue is just the commands and a place to track the rollout. > [Feature flag controls](https://docs.gitlab.com/development/feature_flags/controls/) · [Feature flag lifecycle](https://handbook.gitlab.com/handbook/product-development/how-we-work/product-development-flow/feature-flag-lifecycle/#feature-flag-lifecycle) ## What could go wrong? Pipeline creation starts failing for any project that passes a YAML tag in an input value. Most of those configurations are already broken and only gain a clear error. Some work today, so this is a behavior change: when an array input holds a `!reference` and the template substitutes the input as a whole value, the tag resolves correctly, and the flag rejects it anyway. Projects with no tags in input values are unaffected, because the flag is only checked when a tag is present. Disabling the flag restores the previous behavior immediately. No data loss. `Security::CiConfiguration::BaseCreateService` loads CI YAML without setting a flag actor, so during a targeted rollout it uses the global flag state and tracks a `NoActorError` to error tracking. Both stop once the flag is enabled globally. ## Rollout Run all production `/chatops` in [`#production`](https://gitlab.slack.com/archives/C101F3796) and cross-post the results to `#g_pipeline-authoring`. Background: [incremental rollout process](https://docs.gitlab.com/development/feature_flags/controls/#process), [feature actors](https://docs.gitlab.com/development/feature_flags/#feature-actors). **Non-production** ``` /chatops gitlab run feature set ci_reject_yaml_tags_in_inputs 50 --actors --dev --pre --staging --staging-ref /chatops gitlab run feature set ci_reject_yaml_tags_in_inputs true --dev --pre --staging --staging-ref ``` Verified on staging with https://staging.gitlab.com/oyakovenko/ff-607488-yaml-tags-in-inputs, which covers the tag as the whole input value, nested in an array, nested in a hash, interpolated inside a string, and in an input `default:`, plus three control cases. **Production** - target specific actors first, and verify that a pipeline with a YAML tag in an input value fails with the expected error: ``` /chatops gitlab run feature set --project=gitlab-org/gitlab ci_reject_yaml_tags_in_inputs true ``` Then percentage rollout (wait >= 15 min between steps, watch the Events queries above): ``` /chatops gitlab run feature set ci_reject_yaml_tags_in_inputs <percentage> --actors /chatops gitlab run feature set ci_reject_yaml_tags_in_inputs true ``` ## Before global rollout Confirm the relevant gotchas before going to 100%, see [enabling a feature for GitLab.com](https://docs.gitlab.com/development/feature_flags/controls/#enabling-a-feature-for-gitlabcom): - [ ] [Docs + version history](https://docs.gitlab.com/development/documentation/feature_flags/) updated - [ ] [Breaking changes](https://docs.gitlab.com/development/documentation/release_notes/#deprecations-removals-and-breaking-changes) announced - [ ] [Change management issue](https://handbook.gitlab.com/handbook/engineering/infrastructure-platforms/change-management/#feature-flags-and-the-change-management-process) opened, if required ## Cleanup Remove the flag once [deemed stable](https://handbook.gitlab.com/handbook/product-development/how-we-work/product-development-flow/feature-flag-lifecycle/#feature-flag-lifecycle), see [cleaning up](https://docs.gitlab.com/development/feature_flags/controls/#cleaning-up). Set `default_enabled: true`, then remove the flag, its YAML definition, and the gating code. ``` /chatops gitlab run release check <merge-request-url> <milestone> /chatops gitlab run feature delete ci_reject_yaml_tags_in_inputs --dev --pre --staging --staging-ref --production ``` ## Rollback ``` /chatops gitlab run feature set ci_reject_yaml_tags_in_inputs false # production /chatops gitlab run feature set ci_reject_yaml_tags_in_inputs false --dev --pre --staging --staging-ref # non-production ```