Deprecation - Change logic to reject container image pull policies that are not included in the allowed_pull_policies configuration setting.

Deprecation Summary

As documented, the current allowed_pull_policies feature in GitLab runner indicates that if the allowed_pull_policies configuration option is set in the runner config.toml, then the defined pull policies in the .gitlab-ci.yml file must match. If there is no match, then the job should not run and return an error.

config.toml


[[runners]]
  (...)
  executor = "docker"
  [runners.docker]
    (...)
    allowed_pull_policies = ["always", "if-not-present"]

.gitlab-ci.yml

job:
  image:
    name: ruby:3.0
    pull_policy: ["never,", "if-not-present"]

However, the current implementation does not correctly handle the scenario where multiple policies are included in the .gitlab-ci.yml file, but one of the pull policies is not specified in the allowed_pull policies key. In this scenario the CI job does not fail.

The correct behavior is that the job should fail.

User / Customer Impact: RISK OF CI JOB FAILURES

We are flagging this logic change as a deprecation as some users may have implemented pipelines with values in the pull_policy configuration that do not match what is allowed in the runner on which those pipelines are executed.

Therefore, with this change in logic in GitLab Runner 18.0, a CI job in such a pipeline that previously ran will not run. Users will, thus, be confused about why a CI job is failing.

Documentation

Product Usage

Describe why deprecation of this feature is necessary, ideally with dashboards/metrics that show product usage. add links to the documentation

Breaking Change?

Does this deprecation contain a breaking change? Yes / No

Affected Customers

Who is affected by this deprecation: GitLab.com users, Self-managed users, or Dedicated users? (choose all that apply)

  • GitLab.com
  • Self-managed
  • Dedicated

Additional impact details for GitLab.com

  • CI jobs running on GitLab Hosted Runners: No impact. The allowed_pull_policies or pull_policy configuration options are not set in the GitLab hosted runners config.toml.

  • CI jobs running in Self managed runners attached to GitLab.com: Yes

What pricing tiers are impacted?

  • GitLab Free
  • GitLab Premium
  • GitLab Ultimate

Deprecation Milestone

This deprecation will be announced in milestone: xx.xx If this deprecation has already been announced, include information about when the initial announcement went out and what follow-up announcements are scheduled.

Planned Removal Milestone

The current functionality will change in milestone: 18.0

Links

https://gitlab.com/gitlab-org/security/gitlab-runner/-/merge_requests/75

Checklists

Timeline

Rollout Plan

  • DRI Engineers: @engineer(s)

  • DRI Engineering Manager: @nicolewilliams

  • Describe rollout plans on GitLab.com

    • Link to a feature flag rollout issue that covers:
      • Expected release date on GitLab.com and GitLab version
      • Rollout timelines, such as a percentage rollout on GitLab.com
      • Creation of any clean-up issues, such as code removal

  • Determine how to migrate users still using the existing functionality

  • Document ways to migrate with the tooling available

  • Automate any users who have not yet migrated, but ensure it's a two-way door decision

Development

  • DRI Engineers: @engineer(s)
  • DRI Engineering Manager: @nicolewilliams
  • Measure usage of the impacted product feature
    • Evaluate metrics across GitLab.com, Self-Managed, Dedicated
    • add issue link
    • list any metrics and/or dashboards
  • Create tooling for customers to manually migrate their data or workflows
    • add issue link
  • Build mechanism for users to manually enable the breaking change ahead of time
    • add issue link
  • Automate the migration for those who do not take any manual steps (ensure the automation can be reverted)
    • add issue link
  • Develop rollout plan of breaking change on GitLab.com
    • add feature flag rollout issue
  • Dogfood the changes on GitLab.com or a Self-Managed test instance
    • add issue link
  • (Optional) Create UI controls for instance admins to disable the breaking change, providing flexibility to Self-Managed / Dedicated customers. Optional as this depends on the breaking change.
    • add issue link

Approvals

  • Product Manager @DarrenEastman
  • Senior Engineering Manager / Director @nicolewilliams
  • Group / Director of Product Management @jreporter
  • Product / Eng Leaders in the CPO or CTO organizations, as applicable (optional - depends on scope of change)

Keep in mind that approval check boxes and deprecations notices alone are not sufficient communication about breaking changes. Despite having approvals documented here, the PM/EM will still need to take active steps to partner with internal stakeholders and customers to ensure a positive user experience.

Stakeholder Mentions

  • Product Designer @ProductDesigner
  • Tech Writer @TW
  • Software Engineering in Test @SET
  • Any other stable counterparts based on the product categories:
    • Add Sales/CS counterpart or mention @timtams
    • Add Support counterpart or mention @jfarmiloe
    • Add Marketing counterpart or mention @martin_klaus
    • Add Corp comms if direct customer comms are needed @jmalleo
    • Add Product Security counterpart, if relevant to your deprecation
    • Mention (in internal note) Customer Success Managers / Acount Managers / Solutions Architects for impacted customers

Labels

  • This issue is labeled deprecation, and with the relevant ~devops::, ~group::, and ~Category: labels.
  • This issue is labeled breaking change if the removal of the deprecated item will be a breaking change.

References

Edited by Darren Eastman