Skip to content

Deprecation - Support for resetting runner registration token through GraphQL API endpoints

Deprecation Summary

Add a brief description of the feature or functionality that is deprecated. Clearly state the potential impact of the deprecation to end users.

The support for runner registration tokens is deprecated. As a consequence, the support for resetting a registration token is also deprecated and will be removed in GitLab 18.0.

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?

Affected Customers

  • GitLab.com
  • Self-managed
  • Dedicated

Deprecation Milestone

%17.7 (the removal of runner registration tokens has been widely communicated since %15.6)

Planned Removal Milestone

%18.0

Links

Checklists

Timeline

Rollout Plan

DRIs:

  • Engineers: @pedropombeiro

  • 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

Communication Plan

DRIs:

  • Product Manager: @DarrenEastman

Add links to the relevant merge requests.

  • As soon as possible, but no later than the third milestone preceding the major release (for example, given the following release schedule: 17.8, 17.9, 17.10, 17.11, 18.0 – 17.9 is the third milestone preceding the major release):
  • On the major milestone:
    • The deprecated item has been removed.
    • If the removal of the deprecated item is a breaking change, the merge request is labeled breaking change.
    • Document the migration plan for users, clearly outlining the actions they need to take to mitigate the impact of the breaking change.

Development

DRIs:

  • Engineers: @pedropombeiro

  • 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
  • Engineering Manager @nicolewilliams
  • Senior Engineering Manager / Director @senior-eng-leader
  • Group / Director of Product Management @senior-product-leader

Mentions (as applicable)

  • 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 @gitlab-com/support/managers
    • Add Marketing counterpart or mention @cfoster3

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 Pedro Pombeiro