| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| |
|
|
|
|
|
|
|
| |
Testify features sub packages `assert` and `require`. The difference is
subtle, and lost on novice Golang developers that don't read the docs.
To create a more consistent code base `assert` will no longer be used.
This change was generated by a running a sed command on all `_test.go`
files, followed by `goimports -w`.
|
| |
|
|
|
|
| |
This message happens all the time and doesn't add a lot of value.
Relates to https://gitlab.com/gitlab-com/gl-infra/delivery/-/issues/1275
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
```
|
| |
|
|
|
| |
This will make it easier to tie an SSH access request to Rails API and
Gitaly requests.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
| |
Admins may want to know what client IP originated the request. This
commit adds a `remote_ip` field to the log that extracts the IP address
from the `SSH_CONNECTION` environment variable.
Closes https://gitlab.com/gitlab-org/gitlab-shell/-/issues/199
|
| | |
|
| |
|
|
|
|
|
|
|
| |
logrus fires a Goroutine to write logs, so the tests could fail if they
checked the event queue before the logrus have fired. Since there isn't
an easy way to flush all outstanding hooks, we just retry every 100 ms
for up to a second for log to arrive in the queue.
Closes https://gitlab.com/gitlab-org/gitlab-shell/-/issues/450
|
| |
|
|
|
|
|
|
| |
Calling logrus hook.LastEntry() can lead to race conditions. Use
AllEntries instead:
https://github.com/sirupsen/logrus/blob/60c74ad9be0d874af0ab0daef6ab07c5c5911f0d/hooks/test/test.go#L77
Closes https://gitlab.com/gitlab-org/gitlab-shell/-/issues/450
|
| | |
|
| | |
|
| |
|
|
| |
We'll reuse this module for uploadpack in the future
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
This restores the previous Ruby gitlab-shell behavior.
|
| |
|
|
|
|
|
|
|
|
|
| |
Both git-upload-pack and git-receive-pack services inspect the
GIT_PROTOCOL environment transferred via SSH in order to decide which
protocols are supported by a given client. Currently, we don't use the
environment variable at all, though, but instead forward the GitProtocol
field of the access verification response.
Improve this by passing on the GIT_PROTOCOL environment variable
provided by the client as-is.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Add support for Gitaly feature flags
See merge request gitlab-org/gitlab-shell!351
|
| | |
|
| | |
|
| |
|
