| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Improve rename projects migration
Closes #29556
See merge request !10009
|
|
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
|
|
|
|
|
|
Add a test which would rollback db and migrate again
Closes #29106
See merge request !9908
|
|
|
|
|
|
Closes #29106
|
|
Blacklist nested groups and project names that can cause ambiguous routing for HA
Closes #29324
See merge request !9898
|
|
That have wildcard routes associated and not reserved yet: artifacts,
graphs, badges and refs
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
|
|
This migration resets `users.authorized_projects_populated` (in batches)
so that active users' permissions are refreshed on the next request.
This ensures that their permissions are properly stored.
|
|
|
|
|
|
migration
The `unless defined?(Service)` was useless since in production env,
models are eager loaded, thus we wouldn't disable the STI, resulting in
the following error:
The single-table inheritance mechanism failed to locate the subclass:
'GitlabCiService'. This error is raised because the column 'type' is
reserved for storing the class in case of inheritance. Please rename
this column if you didn't intend it to be used for storing the
inheritance class or overwrite Service.inheritance_column to use another
column for that
information./opt/gitlab/embedded/service/gitlab-rails/db/post_migrate/20170211073944_disable_invalid_service_templates.rb:11:in `up'
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
|
This reverts commit cb10b725c8929b8b4460f89c9d96c773af39ba6b.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
# Conflicts:
# db/schema.rb
|
|
Disable invalid service templates
Closes #25112
See merge request !8850
|
|
|
|
|
|
|
|
|
|
Feedback:
https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/8987#note_22938402
|
|
This way we could reuse this pool for other migrations
Feedback:
* https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/8987#note_22923350
* https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/8987#note_22923365
|
|
|
|
by ourselves so that even if the setting has 1 connection
we could still use more connections.
|
|
|
|
Note that we no longer generate this by default.
This is for clearing legacy default data.
|
|
|
|
|
|
|
|
There have been several bugs in the project deletion service and worker.
Resulting in projects stuck in pending delete state, which limits users
to create projects with the same name, keeps stale records in the
database, and all kinds of other trouble.
This post deployment migration requeues all these projects for deletion,
in the hope that most of these could be removed by the updated code.
|
|
This ensures that the project_authorizations rows exist for all users
for which this data has not yet been populated.
Fixes #26194
|
|
This column used to be a 32 bits integer, allowing for only a maximum of
2 147 483 647 rows. Given enough users one can hit this limit pretty
quickly, as was the case for GitLab.com.
Changing this type to bigint (= 64 bits) would give us more space, but
we'd eventually hit the same limit given enough users and projects. A
much more sustainable solution is to simply drop the "id" column.
There were only 2 lines of code depending on this column being present,
and neither truly required it to be present. Instead the code now uses
the "project_id" column combined with the "user_id" column. This means
that instead of something like this:
DELETE FROM project_authorizations
WHERE user_id = X
AND id = Y;
We now run the following when removing rows:
DELETE FROM project_authorizations
WHERE user_id = X
AND project_id = Y;
Since both user_id and project_id are indexed this should not slow down
the DELETE query.
This commit also removes the "dependent: destroy" clause from the
"project_authorizations" relation in the User and Project models.
Keeping this prevents Rails from being able to remove data as it relies
on an "id" column being present. Since the "project_authorizations"
table has proper foreign keys set up (with cascading removals) we don't
need to depend on any Rails logic.
|
|
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
|
|
# Conflicts:
# db/schema.rb
|
|
On GitLab.com this migration could take about 3 minutes. Disabling the
statement we know we have enough time to complete this.
Fixes #25976
|
|
This return is redundant as the query now uses "WHERE EXISTS (...)" to
filter out projects without a namespace.
|
|
This ensures threads don't re-use the same connection object, and use
fewer queries to perform the work.
|
|
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.
|
|
|
|
See https://gitlab.com/gitlab-org/gitlab-ce/issues/24386
|
