[Feature flag] Rollout of ci_reject_yaml_tags_in_inputs

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

Summary

This issue is to roll out rejecting YAML tags in CI/CD input values on production, which is currently behind the ci_reject_yaml_tags_in_inputs feature flag.

  • Feature flag name: ci_reject_yaml_tags_in_inputs
  • Feature flag type: gitlab_com_derisk
  • Introduced by: !249492 (merged)
  • Feature issue: #607053

What it does

A YAML tag such as !reference is resolved after input interpolation, so a tag passed as an include: inputs: value is never resolved and its internal object is dumped into the configuration, for example #<Gitlab::Ci::Config::Yaml::Tags::Reference:0x...>.

When the flag is enabled, such a value is rejected with `<input>` input: provided value cannot contain a YAML tag. This covers a tag as the entire value, a tag nested in an array or hash, and a tag in an input default:.

When the flag is disabled, behavior is unchanged and the tag object continues to be dumped into the configuration.

Reusing a value across configuration files does not need !reference: an array input defined in an external file can be shared and extended with additional items.

Owners

Expectations

What are we expecting to happen?

Configurations that pass a YAML tag in an input value fail with a clear error instead of silently producing a dumped object. Configurations without tags in input values are unaffected, because the flag is only evaluated when a tag is present in an input value.

What might happen if this goes wrong?

This turns a silently broken configuration into a pipeline error, so a project that currently tolerates the dumped object in its configuration starts failing. Disabling the flag restores the previous behavior immediately.

Known limitations during targeted rollout

The flag is evaluated through Gitlab::Ci::Config::FeatureFlags, which reads a thread-local actor. Gitlab::Ci::Config sets it, so pipeline creation evaluates the flag per project. A few other entry points load CI YAML without an actor (Ci::PipelineCreation::FindPipelineInputsService, Security::CiConfiguration::BaseCreateService, CloudSeed::GoogleCloud::GeneratePipelineService) and fall back to the global flag state. This resolves itself once the flag is enabled globally.

Rollout Steps

  • Enable on GitLab.com for a few select projects/groups (/chatops run feature set --project=gitlab-org/gitlab ci_reject_yaml_tags_in_inputs true)
  • Verify that pipelines using a YAML tag in an input value fail with the expected error, and that other pipelines are unaffected
  • Enable globally on GitLab.com (/chatops run feature set ci_reject_yaml_tags_in_inputs true)
  • Monitor for at least a few days
  • Set default_enabled: true in the YAML definition
  • Clean up the feature flag and remove the gating code
Edited by Oleg Yakovenko