What does this MR do?
The problem was described in https://gitlab.com/gitlab-org/gitlab-ee/issues/1736#note_24262662.
An additional thing that I fixed is that once we found the new commits (via Gitlab::Popen.popen in Repository#new_commits), we try to instantiate commit objects for the returned SHAs. The issue was that those commits are still in the quarantine directories (GIT_OBJECT_DIRECTORY, and GIT_ALTERNATE_OBJECT_DIRECTORIES) at this point: we needed a way to tell the Rugged repo to look for these SHAs in these directories as well.
After some digging through libgit2 and Rugged, I found out that Rugged::Repository#new actually accepts an alternate keyword param just for that!
The final solution is thus to set environment variables in /api/v3/internal/allowed from GIT_OBJECT_DIRECTORY, and GIT_ALTERNATE_OBJECT_DIRECTORIES passed from gitlab-shell and use those variable when instantiating the Rugged repo in Rugged::Repository#new.
Are there points in the code the reviewer needs to double check?
I've removed the passing of env to Gitlab::GitAccess#new since these are already available from the subprocess spawned by Gitlab::Popen.popen.
Why was this MR needed?
To fix push-rules and other commit checks that happens in pre-receive hooks.
Does this MR meet the acceptance criteria?
-
Changelog entry added, if necessary - Tests
-
Added for this feature/bug -
All builds are passing
-
-
Conform by the merge request performance guides -
Conform by the style guides -
Branch has no merge conflicts with master(if it does - rebase it please) -
Squashed related commits together -
Be sure to have a single commit for the changes to app/models/repository.rbsince these are the only one EE-specific
What are the relevant issue numbers?
Closes #1736 (closed)