- 11 Apr, 2017 1 commit
-
-
Tiago Botelho authored
-
- 10 Apr, 2017 1 commit
-
-
Dmitriy Zaporozhets authored
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
-
- 09 Apr, 2017 1 commit
-
-
blackst0ne authored
-
- 05 Apr, 2017 1 commit
-
-
Douwe Maan authored
-
- 24 Mar, 2017 1 commit
-
-
Stan Hu authored
-
- 20 Mar, 2017 1 commit
-
-
Dmitriy Zaporozhets authored
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
-
- 17 Mar, 2017 2 commits
-
-
Kamil Trzciński authored
-
Stan Hu authored
-
- 16 Mar, 2017 1 commit
-
-
Grzegorz Bizon authored
-
- 14 Mar, 2017 2 commits
-
-
Valery Sizov authored
-
Valery Sizov authored
-
- 13 Mar, 2017 3 commits
-
-
Lin Jen-Shin authored
Closes #29106
-
Dmitriy Zaporozhets authored
That have wildcard routes associated and not reserved yet: artifacts, graphs, badges and refs Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
-
Yorick Peterse authored
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.
-
- 07 Mar, 2017 1 commit
-
-
Markus Koller authored
-
- 06 Mar, 2017 1 commit
-
-
Grzegorz Bizon authored
-
- 01 Mar, 2017 1 commit
-
-
Rémy Coutable authored
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>
-
- 23 Feb, 2017 4 commits
-
-
Douwe Maan authored
This reverts commit cb10b725c8929b8b4460f89c9d96c773af39ba6b.
-
Douwe Maan authored
-
Douwe Maan authored
-
Douwe Maan authored
-
- 16 Feb, 2017 1 commit
-
-
Annabel Dunstone Gray authored
-
- 15 Feb, 2017 2 commits
-
-
Annabel Dunstone Gray authored
-
Annabel Dunstone Gray authored
-
- 14 Feb, 2017 10 commits
-
-
Felipe Artur authored
-
Z.J. van de Weg authored
-
Lin Jen-Shin authored
-
Lin Jen-Shin authored
-
Lin Jen-Shin authored
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
-
Lin Jen-Shin authored
-
Lin Jen-Shin authored
by ourselves so that even if the setting has 1 connection we could still use more connections.
-
Lin Jen-Shin authored
-
Lin Jen-Shin authored
Note that we no longer generate this by default. This is for clearing legacy default data.
-
- 07 Feb, 2017 1 commit
-
-
Ruben Davila authored
-
- 24 Jan, 2017 3 commits
-
-
Z.J. van de Weg authored
-
Zeger-Jan van de Weg authored
-
Z.J. van de Weg authored
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.
-
- 11 Jan, 2017 1 commit
-
-
Yorick Peterse authored
This ensures that the project_authorizations rows exist for all users for which this data has not yet been populated. Fixes #26194
-
- 08 Jan, 2017 1 commit
-
-
Yorick Peterse authored
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.
-