| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
| |
The user agent for requests to the internal API endpoints used the
default Go provided user agent. This change updates that to always set
something else, by default `GitLab-Shell`.
Than for others importing the package, there's a new API to set it to
something else. This has been done with new method, a setter, to
maintain backwards compatibility in the API.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
From
https://gitlab.com/gitlab-org/omnibus-gitlab/-/merge_requests/4498#note_397401883,
if you specify a relative path such as:
```
external_url 'http://gitlab.example.com/gitlab'
```
gitlab-shell doesn't have a way to pass the `/gitlab` to the host. For example, let's say we have:
```
gitlab_url: "http+unix://%2Fvar%2Fopt%2Fgitlab%2Fgitlab-workhorse%2Fsocket"
```
If we have `/gitlab` as the relative path, how do we specify what is the
UNIX socket path and what is the relative path? If we specify:
```
gitlab_url: "http+unix:///var/opt/gitlab/gitlab-workhorse.socket/gitlab
```
This is ambiguous. Is the socket in
`/var/opt/gitlab/gitlab-workhorse.socket/gitlab` or in
`/var/opt/gitlab/gitlab-workhorse.socket`?
To fix this, this merge request adds an optional
`gitlab_relative_url_root` config parameter:
```
gitlab_url: "http+unix://%2Fvar%2Fopt%2Fgitlab%2Fgitlab-workhorse%2Fsocket"
gitlab_relative_url_root: /gitlab
```
This is only used with UNIX domain sockets to disambiguate the socket
and base URL path. If `gitlab_url` uses `http://` or `https://`, then
`gitlab_relative_url_root` is ignored.
Relates to https://gitlab.com/gitlab-org/gitlab-shell/-/issues/476
|
| |
|
|
|
| |
This will make it easier to tie an SSH access request to Rails API and
Gitaly requests.
|
| |
|
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
This would make it easier to filter the logs by status code.
|
| |
|
