| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
Updates changed method names and fixes spec failures
|
| |
|
|
|
|
|
|
|
|
| |
https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/24624 extracted
the X-Forwarded-For address directly, but this didn't consider the case
where multiple proxies are in the chain. To fix this, we use the Rails
implementation to filter trusted proxies, as documented by Grape:
https://github.com/ruby-grape/grape#remote-ip
Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/58103
|
| |
|
|
|
|
|
|
| |
Check if `X-Forwarded-For` is set before getting the IP of the request,
with this the real IP address of the runner is shown if it's behind a
proxy.
closes https://gitlab.com/gitlab-org/gitlab-ce/issues/53676
|
| |
|
|
|
|
|
|
|
|
| |
Partially addresses #47424.
Had to make changes to spec files because
stubbing methods on frozen objects is a mess
in RSpec and leads to failures:
https://github.com/rspec/rspec-mocks/issues/1190
|
| | |
|
| | |
|
| |\
| |
| |
| | |
38265-stuckcijobsworker-wrongly-detects-cancels-stuck-builds-when-per-job-timeout-is-more-than-an-hour
|
| | |
| |
| |
| | |
including/extending it
|
| | | |
|
| | | |
|
| | | |
|
| |/ |
|
| |
|
|
| |
Adds a rubocop rule (with autocorrect) to ensure line break after guard clauses.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The initializers including this were doing so at the top level, so every object
loaded after them had a `current_application_settings` method. However, if
someone had rack-attack enabled (which was loaded before these initializers), it
would try to load the API, and fail, because `Gitlab::CurrentSettings` didn't
have that method.
To fix this:
1. Don't include `Gitlab::CurrentSettings` at the top level. We do not need
`Object.new.current_application_settings` to work.
2. Make `Gitlab::CurrentSettings` explicitly `extend self`, as we already use it
like that in several places.
3. Change the initializers to use that new form.
|
| | |
|
| |
|
|
|
|
| |
These changes are ported over from
https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/1502 to reduce
the number of merge conflicts that may occur.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In Runner v1.3.0 we've started to send User-Agent header with Runner's
version data. Since GitLab v8.12.0 we've started to use this header to check
if used Runner's version supports 204 status code instead of 404 as a
response when there is no jobs to execute by a Runner.
In APIv4 (introduced in GitLab 9.0.0) will require Runner v9.0.0. And
writing more accurately: GitLab Runner v9.0.0 will require GitLab at
least 9.0.0. Because of such breaking change we are able to switch
entirely to 204 response code and there is no need to do check of
User-Agent.
This commit removes useless code and complexity.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
