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.
Customers often have Sidekiq jobs that failed without much context. Without
Sentry, there's no way to tell where these exceptions were hit. Adding
in additional lines adds a bit more Redis storage overhead. This commit
adds in backtrace logging for workers that delete groups/projects and
import/export projects.
Closes#27626
Customers often have Sidekiq jobs that failed without much context. Without
Sentry, there's no way to tell where these exceptions were hit. Adding
in additional lines adds a bit more Redis storage overhead. This commit
adds in backtrace logging for workers that delete groups/projects and
import/export projects.
Closes#27626
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.
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.
