An error occurred fetching the project authors.
- 19 Oct, 2018 1 commit
-
-
Bob Van Landuyt authored
This removes the `ForkedProjectLink` model that has been replaced by the `ForkNetworkMember` and `ForkNetwork` combination. All existing relations have been adjusted to use these new models. The `forked_project_link` table has been dropped. The "Forks" count on the admin dashboard has been updated to count all `ForkNetworkMember` rows and deduct the number of `ForkNetwork` rows. This is because now the "root-project" of a fork network also has a `ForkNetworkMember` row. This count could become inaccurate when the root of a fork network is deleted.
-
- 30 Apr, 2018 1 commit
-
-
Tiago Botelho authored
-
- 01 Mar, 2018 1 commit
-
-
Dmitriy Zaporozhets authored
Signed-off-by:
Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
-
- 07 Oct, 2017 2 commits
-
-
Bob Van Landuyt authored
The helper creates a fork of a project with all provided attributes, but skipping the creation of the repository on disk.
-
Bob Van Landuyt authored
The helper creates a fork of a project with all provided attributes, but skipping the creation of the repository on disk.
-
- 22 Aug, 2017 3 commits
-
-
Toon Claes authored
There might be some projects where the namespace was removed, but the project wasn't. For these the projects still have a `namespace_id` set. So this adds a post-deploy migration remove all projects that are pending delete, and have a `namespace_id` that is non-existing.
-
Grzegorz Bizon authored
Since this already exists in `every_sidekiq_worker_spec.rb`.
-
Gabriel Mazetto authored
-
- 21 Aug, 2017 1 commit
-
-
Grzegorz Bizon authored
-
- 02 Aug, 2017 2 commits
-
-
Robert Speicher authored
-
Robert Speicher authored
-
- 01 Aug, 2017 2 commits
-
-
Gabriel Mazetto authored
-
Gabriel Mazetto authored
-
- 10 May, 2017 2 commits
-
-
Toon Claes authored
Since this is a cleanup, ran by a post-deploy, there is no need to lookup the admin to run the cleanup.
-
Toon Claes authored
Destroying projects can be very time consuming. So instead of destroying them in the post-deploy, just schedule them and make Sidekiq do the hard work. They are scheduled in batches of 5000 records. This way the number of database requests is limited while also the amount data read to memory is limited.
-