Skip to content

Architecture of gitlab-shell

Screenshot_2017-10-12_15.46.29

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