[go: up one dir, main page]

Skip to content

Should REPO_REMOVAL_DELAY and the STALE_REMOVAL_DELAY be removed from GitLab

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

Summary

Are the REPO_REMOVAL_DELAY and the STALE_REMOVAL_DELAY, are those around solely for NFS?

Should they be removed from GitLab as they are now solely a Gitaly concern.

Context from the original Slack conversation:

REPO_REMOVAL_DELAY and the STALE_REMOVAL_DELAY, are those around solely for NFS? Not advocating the removal, but wondering if this is a Gitaly concern more than a GitLab one.

now that we have delayed project deletion more generally, I'd suggest it's outdated to have this as well, but I don't know the details

would need a look in the overall context - it's used by Projects::DestroyService, for instrance, and it might be that it's enqueued early, before other actions that need the repository to still be around

I excluded Repositories::* from my refactor that aimed to get rid of as much of the GitlabShellWorker stuff as possible last year, because it's a bit of a tangle and ISTR it's relied upon by geo as well

Improvements

Risks

Involved components

Optional: Intended side effects

Optional: Missing test coverage

Edited by 🤖 GitLab Bot 🤖