Before exporting a project, run GitGarbageCollectWorker with prune

Release notes

Dealing with large project exports can be problematic. We've added Git's own reflog expiry and gc to our project export process to provide smaller export files, esp. for large projects in active development.

Problem to solve

We recently documented a workaround for importing too large repos to a GitLab instance. Since then @onemoz & me found that one of the reasons for too large exports, is that the project.bundle can still contain lots of data in the reflog and loose objects. This is addressed by workaround, but it could also be prevented earlier.

Proposal

As an early stage of the exporting process, invoke a relevant part of the Housekeeping stack.

Intended users

• Delaney (Development Team Lead)
• Sidney (Systems Administrator)

What does success look like, and how can we measure that?

• Generally smaller uploads & faster imports.
• Less errors seen during project import, specifically due to too large files.
• Fewer support requests to help with the import workaround.

What is the type of buyer?

Customers who migrate their data, for example from self-managed to GitLab.com