delta/gitlab/gitlab-shell.git/lib/gitlab_access.rb, branch v4.1.1 gitlab.com: gitlab-org/gitlab-shell.git Pass relevant git environment variables while calling `/allowed` 2016-12-16T04:09:12+00:00 Timothy Andrew mail@timothyandrew.net 2016-12-07T07:39:47+00:00 fc2016484aacb82980c1c9082e195110f0eacb34 1. Starting version 2.11, git changed the way the pre-receive flow works. - Previously, the new potential objects would be added to the main repo. If the pre-receive passes, the new objects stay in the repo but are linked up. If the pre-receive fails, the new objects stay orphaned in the repo, and are cleaned up during the next `git gc`. - In 2.11, the new potential objects are added to a temporary "alternate object directory", that git creates for this purpose. If the pre-receive passes, the objects from the alternate object directory are migrated to the main repo. If the pre-receive fails the alternate object directory is simply deleted. 2. In our workflow, the pre-recieve script calls the `/allowed` endpoint on the rails server. This `/allowed` endpoint calls out directly to git to perform various checks. These direct calls to git do _not_ have the necessary environment variables set which allow access to the "alternate object directory" (explained above). Therefore these calls to git are not able to access any of the new potential objects to be added during this push. 3. We fix this by passing the relevant environment variables (GIT_ALTERNATE_OBJECT_DIRECTORIES, GIT_OBJECT_DIRECTORY, and GIT_QUARANTINE_PATH) to the `/allowed` endpoint, which will then include these environment variables while calling out to git. 
1. Starting version 2.11, git changed the way the pre-receive flow works.

  - Previously, the new potential objects would be added to the main repo. If the
    pre-receive passes, the new objects stay in the repo but are linked up. If
    the pre-receive fails, the new objects stay orphaned in the repo, and are
    cleaned up during the next `git gc`.

  - In 2.11, the new potential objects are added to a temporary "alternate object
    directory", that git creates for this purpose. If the pre-receive passes, the
    objects from the alternate object directory are migrated to the main repo. If
    the pre-receive fails the alternate object directory is simply deleted.

2. In our workflow, the pre-recieve script calls the `/allowed` endpoint on the
   rails server. This `/allowed` endpoint calls out directly to git to perform
   various checks. These direct calls to git do _not_ have the necessary
   environment variables set which allow access to the "alternate object
   directory" (explained above). Therefore these calls to git are not able to
   access any of the new potential objects to be added during this push.

3. We fix this by passing the relevant environment variables
   (GIT_ALTERNATE_OBJECT_DIRECTORIES, GIT_OBJECT_DIRECTORY, and
   GIT_QUARANTINE_PATH) to the `/allowed` endpoint, which will then include
   these environment variables while calling out to git.
Add instrumentation to push hooks 2016-11-16T12:10:56+00:00 Ahmad Sherif me@ahmadsherif.com 2016-11-16T12:09:33+00:00 79558da92f627da9e310160c89acdeba8b92b359 Related to #22053 
Related to #22053
Use full repository path for API calls instead of extracting name 2016-10-27T13:57:57+00:00 Dmitriy Zaporozhets dmitriy.zaporozhets@gmail.com 2016-10-27T09:34:23+00:00 00bf30ba9f5831e74b6990d4179bd6e4c0ce072a Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com> 
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
Rename ENV['PROTOCOL'] to ENV['GL_PROTOCOL'] and make it mandatory with no fallback value 2016-07-05T23:03:29+00:00 Patricio Cano suprnova32@gmail.com 2016-06-22T17:54:27+00:00 6aa601866c66a62b4ab3db3fa55ab1b5e84e444d 






Allow GitLab Shell to check for allowed access based on the used Git protocol.
2016-07-05T23:01:12+00:00

Patricio Cano
suprnova32@gmail.com

2016-06-21T02:13:53+00:00

44e7804ddb408d85f091c7a5cd36e0fdbec63d13












Refactor repository paths handling to allow multiple git mount points
2016-06-29T17:58:20+00:00

Alejandro Rodríguez
alejorro70@gmail.com

2016-06-29T17:58:20+00:00

18b4d39ac7172cb02cec63e7bf1cc21807a9b3f0












Write GitlabAccess error to stderr.
2015-04-06T11:08:47+00:00

Douwe Maan
douwe@gitlab.com

2015-04-06T10:26:58+00:00

8f0f67622971d1861769a9deac6b102c9fdaed42












Show nice error message when internal API is unreachable.
2015-02-11T22:43:57+00:00

Douwe Maan
douwe@gitlab.com

2015-02-11T22:43:57+00:00

562d7eb4ecaa9ca35f970567c0f09cdb29d26521












Revert "Revert "Merge branch 'git_hook_messages'""
2014-11-24T11:58:07+00:00

Valery Sizov
vsv2711@gmail.com

2014-11-24T11:58:07+00:00

961fe45c4210dcb1a69f167ac468991ad6998793

This reverts commit f8453da5868dd7a23d0f2f3da7a45e33c441d1db.





This reverts commit f8453da5868dd7a23d0f2f3da7a45e33c441d1db.







Revert "Merge branch 'git_hook_messages'"
2014-11-20T10:06:27+00:00

Jacob Vosmaer
contact@jacobvosmaer.nl

2014-11-20T10:06:27+00:00

f8453da5868dd7a23d0f2f3da7a45e33c441d1db

At least the following things were broken:
- missing require for 'gitlab_access_status' in lib/gitlab_net.rb
- gitlabhq master internal API returns 'true' or 'false', gitlab-shell
  expects JSON

This reverts commit 11311a95545f967a5736cd16ab5fc37f7e658519, reversing
changes made to 45444597aef3e434571de2491934ae92357ad231.





At least the following things were broken:
- missing require for 'gitlab_access_status' in lib/gitlab_net.rb
- gitlabhq master internal API returns 'true' or 'false', gitlab-shell
  expects JSON

This reverts commit 11311a95545f967a5736cd16ab5fc37f7e658519, reversing
changes made to 45444597aef3e434571de2491934ae92357ad231.