Remove ability to convert an instance (shared) runner to a project (specific) runner
Deprecation Summary
-
Converting or "downgrading" an instance (shared) Runner to a project (specific) runner is deprecated.
-
This feature enables an administrator of a GitLab instance to convert an instance (shared) runner to a project (specific) runner.
-
In addition to this capability being a one-way transition, continued support of this capability has resulted in technical debt that negatively impacts our ability to introduce new features and capabilities to simplify the management of a fleet of runners in the GitLab UI.
Docs: Making an existing Shared Runner specific
If you are an admin on your GitLab instance, you can turn any shared Runner into a specific one, but not the other way around. Keep in mind that this is a one way transition.
- Navigate to the Admin Area in the left navigation bar and select Overview ➔ Runners
- In the Admin Area ➔ Runners (
/admin/runners
) screen click on the edit icon for a runner where Type/State = Shared - Enable any project under Restrict projects for this Runner to be used with the Runner.
Breaking Change
Users that need to add a project runner can still do so by registering a runner for that project.
Affected Topology
GitLab Self-Managed
Affected Tier
- Free
- Premium
- Ultimate
Checklist
-
@mention your stage's stable counterparts on this issue. For example, Customer Support, Customer Success (Technical Account Manager), Product Marketing Manager. - To see who the stable counterparts are for a product team visit product categories
- If there is no stable counterpart listed for Sales/CS please mention
@timtams
- If there is no stable counterpart listed for Support please @mention
@gitlab-com/support/managers
- If there is no stable counterpart listed for Marketing please mention
@williamchia
- If there is no stable counterpart listed for Sales/CS please mention
- To see who the stable counterparts are for a product team visit product categories
-
@mention your GPM so that they are aware of planned deprecations. The goal is to have reviews happen at least two releases before the final removal of the feature or introduction of a breaking change.
Deprecation Milestone
14.5
Planned Removal Milestone
15.0