We cant have project with name 'project' or 'tree' anymore.
This merge request containts a migration that will find and rename all
projects using reserved names by adding N digit to the end of the name.
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
This adds a migration to remove unused services, where the properties
are empty. As the properties are empty, those do not contain any
settings or other information.
Fixes#25727
If we leave this as a regular migration, we could have the following flow:
1. Application knows nothing about scopes.
2. First migration runs, all existing personal access tokens have `api` scope
3. Application still knows nothing about scopes.
4. Second migration runs, all tokens created after this point have no scope
5. Application still knows nothing about scopes.
6. Tokens created at this time _should have the API scope, but instead have no scope_
7. Application code is reloaded, application knows about scopes
8. Tokens created after this point only have no scope if the user deliberately
chooses to have no scopes.
Point #6 is the problem here. To avoid this, we move the second migration to a
"post" migration, which runs after the application code is deployed/reloaded.
The AddVisibilityLevelToGroups migration introduced a visibility_level for
namespaces and specified that projects should always have a visibility level
less than or equal to their namespace. However, some invalid rows could have
been created.
This commit introduces a migration that updates the invalid rows, setting the
invalid project to have the same visibility_level as their namespaces. This
will make some projects internal or private when they would previously have
been public or internal, but this is better than silently making an internal
or private group public.
These are regular Rails migrations that are executed by default. A user
can opt-out of these migrations by setting an environment variable
during the deployment process.
Fixesgitlab-org/gitlab-ce#22133
