summaryrefslogtreecommitdiff
path: root/client/httpsclient_test.go
Commit message (Collapse)AuthorAgeFilesLines
* GitLab API Client support for client certificatesPaul Okstad2020-11-171-8/+25
|
* tests: Replace assert with requirezj-remove-testify-assertZeger-Jan van de Weg2020-10-151-4/+3
| | | | | | | | | 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`.
* Make it possible to propagate correlation ID across processesStan Hu2020-09-201-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Fix gitlab-shell not handling relative URLs over UNIX socketssh-fix-unix-relative-url-accessStan Hu2020-08-201-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Move gitlabnet client to client packagejc-refactor-gitlabnet-clientJohn Cai2020-05-041-0/+115