While gitlab-shell currently has a major version of v14, the module path
it exposes is not using that major version like it is required by the Go
standard. This makes it impossible for dependents to import gitlab-shell
as a dependency without using a commit as version.

Fix this by changing the module path of gitlab-shell to instead be
`gitlab.com/gitlab-org/gitlab-shell/v14` and adjust all imports
accordingly.

Changelog: fixed

Before this change, the GitLab internal API could use a boolean
response field to indicate whether gitlab-shell should make
sidechannel connections go Gitaly. We now ignore that response field
and always use sidechannel connections.

Jacob Vosmaer authored 3 years ago and Igor Drozdov committed 3 years ago

If the GitLab API returns an allowed response with use_sidechannel set
to true, gitlab-shell will establish a sidechannel connection and use
SSHUploadPackWithSidechannel instead of SSHUploadPack. This is an
efficiency improvement.

Stan Hu authored 4 years ago and Igor Drozdov committed 4 years ago

Right now when a client such as gitlab-shell calls the
`/api/v4/internal/allowed` API, the response only tells the client what
user has been granted access, and it's impossible to tell which deploy
key/token was used in the authentication request.

This commit adds logs for the following when available:

1. `gl_key_type` (e.g. `deploy_key` or `key`)
2. `gl_key_id`

These fields make it possible for admins to identify the exact record
that was used to authenticate the user.

API changes in the `/internal/allowed` endpoint in
https://gitlab.com/gitlab-org/gitlab/-/merge_requests/37289 are needed
to support this.

Relates to https://gitlab.com/gitlab-org/gitlab-shell/-/issues/203

We'll reuse this module for uploadpack in the future