| Age | Commit message (Collapse) | Author |
|---|
|
New version of the gem returns 200 status code on delete with content
instead of 204 so we explicitly set status code to keep existing
behavior
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
|
|
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
|
|
|
used path
|
|
|
|
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.
|
|
In APIv1 we were using UpdateJob to verify if the runner exists. It was
the only method that was using Runner's token and used in special way
had no side effects (like scheduling a new job or unregisterring a
Runner).
In APIv4 we've change UpdateJob to use job's token as authentication
credentials, and that way we've removed the only endpoint that could
be used to verify if the Runner with a certain token exists in target
GitLab installation.
This commit adds `POST /api/v4/runners/verify` endpoint whose only
responsibility is to respond if Runner with posted credentials exists or
not.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
