| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
As of 7eb45672b7, NamesHelper is no longer used.
|
|
|
|
|
| |
This reverts commit 3aaf4751e09262c53544a1987f59b1308af9b6c1, reversing
changes made to c6577e0d75f51b017f2f332838b97c3ca5b497c0.
|
|
|
|
|
|
| |
* Use gl_id when we don't know if it's a key-X or user-X
* Use Actor.new_from(gl_id) which will figure out if it's a Key or User
* Use key_str when we're referring to key-X as key_id is confusing
|
| |
|
|
|
|
|
|
|
|
|
|
| |
* Move gitaly, git-lfs and 2FA logic out from gitlab_shell.rb
* Streamline parsing of origin_cmd in GitlabShell
* Utilise proper HTTP status codes sent from the API
* Also support 200 OK with status of true/false (ideally get rid of this)
* Use HTTP status constants
* Use attr_reader definitions (var over @var)
* Rspec deprecation fixes
|
|
|
|
|
|
| |
* Rename actor to key_id
* protected to private
* Move attr_reader defintions under private
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
Related to #22053
|
|
|
|
| |
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
|
|
|
|
| |
fallback value
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
This reverts commit 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.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
when a user has access. Doing an exit 0 effectively ended the
thread. No code would be executed after the call to exec.
This changes fixes the problem for the pre-receive hooks but you want
to check that GitlabAccess.exec is not used elsewhere. A quick
grep of the code seems to indicate this is not the case
|
| |
|
|
|
|
|
|
|
| |
This commit made changes to GitLab shell to work with huge pushed (ex.
1k branhes) using POST request to API
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
|
|
Gitlab Access handles security check. GitlabPostReceive creates a sidekiq job
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
|