Skip to content

Replace FF with settings migration in runner token blueprint

Vladimir Shushlin requested to merge vshushlin/runner-blueprint-remove-ff into master

What does this MR do and why?

Initially, we wanted to introduce a feature flag to disable the old registration token workflow. This MR replaces the FF with just flipping settings in the database.

Here's why:

  1. With the FF we would have 3 different settings to control that: instance level, group level and FF itself. That would make it very hard to understand, especially for self-managed users who would have access to all of them.
  2. In the old plan, if after 16.6 if clients experience any problems, they would need to flip the FF. And they can't do that themselves for .com. All of that would create a huge load on our support teams.
  3. We can't actually have a single FF because we would likely want to disable it for certain groups on .com. Technically we need 2 FF's for that. And that would make it even more complicated.

So the proposed solution is:

  1. in %17.0 we by default disable old registration workflow on .com. If users want, they still can re-enable it in settings.
  2. in %17.0 we also disable old registration workflow on the instance level for self-managed. If users want, they still can re-enable it in settings.
  3. in %18.0 we disable old registration workflow on .com completely.
  4. in %18.0 we remove support for the old registration tokens completely.

This way:

  1. settings are much simplier
  2. we still "nudge" users to migrate by intentionally breaking their workflow in %17.0
  3. but users can temporarily re-enable it for some time (until %18.0). And they can self-serve without reaching out to our support, or going to the rails console.

Related discussion in Slack(internal)

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

Edited by Pedro Pombeiro

Merge request reports