Wire gitlab-workhorse and gitlab-shell to the client
As of f2d0435b of gitlab-workhorse, these sub-commands are used (based on gitCommand usage):
-
archive -
format-patch,diff,cat-file -
git-upload-pack,git-receive-pack
As of e1b0aca1 of gitlab-shell, these sub-commands are used:
-
git-upload-pack,git-receive-pack -
git-upload-archive -
git-annex-shell -
git-lfs-authenticate -
git-tag -
git-push -
git-init --bare -
git-remote rm -
git-clone --bare -
git-ls-remote -
git-gc(It seems that GitLab doesn't use gitlab-shell for GC anymore; it runs the command from the application. It works nonethless.)
Activity
changed milestone to %Simple Prototype
I would recommend to forget about workhorse for now @ahmadsherif we are good with just gitlab-shell for a simple prototype.
@pcarranza OK.
@ahmadsherif in gitlab-shell, I believe you're missing the following commands that are in
lib/gitlab_projects.rb:git-taggit-pushgit-init --baregit-remote rmgit-clone --baregit-ls-remotegit-gc
Status update: Currently we don't pass (or even use) standard input to the server, so I was implementing that for
git-receive-packand the likes of it. It's not that simple because the input apparently needs to be read in some special way (input is organized into "packets"), so I'll be investigating how to do that.-
I would try to not get in the middle yet, when the client gets something in stdin, it just sends the bytes upstream to the server, and the server just writes down into the process stdin.
We should aim to make this completely transparent for now, not understanding the protocol at all yet.
But if you want to understand the git protocol, read this: https://git-scm.com/book/en/v2/Git-Internals-Transfer-Protocols
Edited by username-removed-274314 mentioned in merge request !10 (merged)
marked the task
git-tag-
@jacobvosmaer-gitlab ping here, this is going on already.
Thanks for the ping @pcarranza but I don't really understand what is going on here. ;)
@jacobvosmaer-gitlab We're checking if gitlab-shell is functioning properly/transparently using the client executable instead of the normal git one. Above is the list of git commands gitlab-shell uses and whether they work with our implementation or not.
Thanks @ahmadsherif .
if gitlab-shell is functioning properly/transparently using the client executable instead of the normal git one
Do you have an example of what that looks like?
@jacobvosmaer-gitlab Simply renaming
gitaly-clienttogit(or any other git executable, see !15 (closed)) and prepending the path to such executable toPATHshould work as expected.OK, neat. But I am not sure if this is a good path to go down.
Gitlab-shell does four things:
- SSH session gatekeeper
- authorized_keys / AuthorizedKeysCommand (not Gitaly's job)
- Git hooks for all GitLab projects
- random other command that do stuff inside individual Git repositories
That last item is something we want to get rid of https://gitlab.com/gitlab-org/gitlab-shell/issues/44 . Why not do that now. We could be making REST calls straight from gitlab-ce.
Different question: is there a concrete improvement that this 'transparent git executable replacement' approach gives us? If we have this gitaly-client system in 8.16, what will be better?
Also see my alternative proposal for connecting things in https://gitlab.com/gitlab-org/gitaly/issues/5#note_20294280
The point was to make a prototype that just works without changing too many parts, to see how things go, or at least that was the vision before we had our meeting and decided how things are gonna go. For your other question, this approach was for stage one; improving availability.
@ahmadsherif thanks, I am putting this on the agenda for tomorrow's meeting.
