Architecture of gitlab-shell
GitLab-shell has 3 parts:
- part that handles SSH connections
- holding git hooks (pre-receive,post-receive, update)
- gitlab-project commands. This does things like creating tags, branches, moving/removing projects and similar in the repo on disk.
Resolving dependencies:
The first part, SSH integration requires access to authorized_keys file. This file also needs to be persisted. For EE, we have a feature that no longer uses authorized_keys file. Requires a specific version of OpenSSH. If we move that feature to CE, we can resolve this dependency. https://gitlab.com/charts/helm.gitlab.io/issues/13
Second part, gitaly just reuses the hooks that gitlab-shell contains. The only reason why this is still in gitlab-shell is technical debt and the time required to port this over. This would require additional work to split up.
Third part should be in gitlab-rails and gitaly. Same reason as above, things work and there are more important priorities to port to gitaly. This would require additional work.
Example
An example of how gitlab-shell interracts with other components, pushing a commit over ssh:
- connection gets opened by sshd
- gitlab-shell uses auth_keys command to find out whether the user has permissions to push
- This is done by gitlab-shell querying GitLab Rails API
- gitlab-shell reads the response it got which also gives it the address of gitaly server
- gitlab-shell now starts a gitaly helper process which will talk to gitaly server
- gitaly server now talks to storage