| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| | |
|
| |
|
|
|
| |
parse logic will only run if the executable accept args.
healthcheck is the only one not accepting arguments.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, opentracing (if configured) was initialized late in the
gitlab-shell process's lifespan, coming just before making a gRPC
call to Gitaly.
By moving the opentracing initialization to be at process startup, we
make it available for the whole process lifecycle, which is very useful
to gitlab-sshd, as it means we'll only call tracing.Initialize() once
on process startup, rather than once per SSH connection.
To get this working, we need to introduce a context to gitlab-sshd.
This carries the client/service name, but also carries an initial
correlation ID. The main outcome of this is that all calls to the
authorized_keys endpoint from a given gitlab-sshd process will now
share a correlation ID. I don't have a strong opinion about this either
way.
Changelog: fixed
|
| |
|
|
| |
Changelog: fixed
|
| |
|
|
|
|
|
| |
Refactors introspection of execution environment to rely on
per-connection state (`gitlab-shell`) or per request (`gitlab-sshd`)
Relates to https://gitlab.com/gitlab-org/gitlab-shell/-/issues/496
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, gitlab-shell did not pass a context through the application.
Correlation IDs were generated down the call stack instead of passed
around from the start execution.
This has several potential downsides:
1. It's easier for programming mistakes to be made in future that lead
to multiple correlation IDs being generated for a single request.
2. Correlation IDs cannot be passed in from upstream requests
3. Other advantages of context passing, such as distributed tracing is
not possible.
This commit changes the behavior:
1. Extract the correlation ID from the environment at the start of
the application.
2. If no correlation ID exists, generate a random one.
3. Pass the correlation ID to the GitLabNet API requests.
This change also enables other clients of GitLabNet (e.g. Gitaly) to
pass along the correlation ID in the internal API requests
(https://gitlab.com/gitlab-org/gitaly/-/issues/2725).
Fixes https://gitlab.com/gitlab-org/gitlab-shell/-/issues/474
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Implements the feature requested in gitlab-org/gitlab#19672
This requires the internal api counterpart in gitlab-org/gitlab!36302 to
be merged first.
It can be used as follows:
```
censored@censored-VirtualBox:~/git/gitlab$ ssh git@gitlab-2004 personal_access_token
remote:
remote: ========================================================================
remote:
remote: Usage: personal_access_token <name> <scope1[,scope2,...]> [ttl_days]
remote:
remote: ========================================================================
remote:
censored@censored-VirtualBox:~/git/gitlab$ ssh git@gitlab-2004 personal_access_token newtoken read_api,read_repository 30
Token: aAY1G3YPeemECgUvxuXY
Scopes: read_api,read_repository
Expires: 2020-08-07
```
|
| | |
|
| |
|
