Block creation of groups whose paths have recently been changed

Release notes

In case you have to change your top-level group URL, GitLab provides helpful redirects in the browser and git clients, prompting clients to configure the changed URLs locally. This redirect is stable as long as no new group is created with the original URL. In order to ease group URL changes and the associated migration on GitLab.com, the original URL can now be protected from being claimed by new groups for a timespan of 30 days.

Problem to solve

Context

Customers sometimes have to change their group URLs to reflect a change of company or product names. The existing feature to change a group path makes this relatively easy. However, the URL also has to be changed in many places, like documentation, automation and git clients. Our existing redirect feature supports this migration by automatically redirecting from the old URLs to the new one. In case of git clients, a helpful message is displayed and the git calls are forwarded automatically to the right place. Especially automations breaking from non-updated links provide a large operational risk of changing the URL, so the redirects are an essential migration tool.

Problem description

This functionality stops working when a new group is created in place of the original group URL. This causes issues when customers want to change their group URL and rely on the forwarding feature as a migration support tool. As a new group creation in place of the original group path could happen at any time and can not be controlled by the original group owners, their migration could be cut short at any point. This is a not a good experience for customers that need to rely on the forwarding feature to support a seamless migration.

Proposal

Support migration to new group paths by providing a reliable timespan (like 30 days) the redirects will keep working for. For example, when changing a group path from /source-group to /target-group, prevent the creation of a new /source-group for that timespan, thus ensuring the redirects stay in place.

This feature is targeted on GitLab.com as multi-tenant environment. On self-managed, this probably needs to be configurable in some fashion, as claiming of groups can be effectively prevented by the business itself.

Intended users

  • Priyanka (Platform Engineer) can rely on redirects being available as migration tool, ensuring there is a fallback if some links have been forgotten to be updated during migration preparations and users will get reminders in their git clients without disruption.
  • Dakota (Application Development Director) can rely on business continuity in development operations throughout the migration process.

Feature Usage Metrics

  • I don't see "change group URL" instrumented at all as a feature so far
  • Monthly counts of "change group URL" as well as "number of redirected URL accesses to customer groups" would be interesting

Does this feature require an audit event?

Not sure, probably not.