- 12 Apr, 2017 1 commit
-
-
Z.J. van de Weg authored
When renaming, the argument on the projects hook API was forgotten. Now one could successfully set it again. The fix is a little ugly stylewise, but needed as the underlying model still refers to it as build_events. This commit is to fix it, later we should migrate the data to a new column. The edit on the spec file makes sure it passes now, and will fail when we migrate the column.
-
- 10 Apr, 2017 2 commits
-
-
Oswaldo Ferreira authored
-
Rémy Coutable authored
Signed-off-by: Rémy Coutable <remy@rymai.me>
-
- 09 Apr, 2017 1 commit
-
-
blackst0ne authored
-
- 06 Apr, 2017 1 commit
-
-
Kamil Trzciński authored
-
- 05 Apr, 2017 5 commits
-
-
Oswaldo Ferreira authored
Notice that this param is being supported since V3, but we have not added the proper docs for it
-
Douwe Maan authored
-
Douwe Maan authored
-
Mike Wyatt authored
-
Mark Fletcher authored
* Documentation was incorrectly advertising the missing param
-
- 04 Apr, 2017 1 commit
-
-
Rémy Coutable authored
Signed-off-by: Rémy Coutable <remy@rymai.me>
-
- 03 Apr, 2017 4 commits
-
-
Rémy Coutable authored
Signed-off-by: Rémy Coutable <remy@rymai.me>
-
Rémy Coutable authored
Signed-off-by: Rémy Coutable <remy@rymai.me>
-
Rémy Coutable authored
FFaker can generate data that randomly break our test suite. This simplifies our factories and use sequences which are more predictive. Signed-off-by: Rémy Coutable <remy@rymai.me>
-
Joren De Groof authored
The MergeRequestsFinder uses the milestone_title instead of the milestone_id
-
- 02 Apr, 2017 1 commit
-
-
Stan Hu authored
-
- 29 Mar, 2017 2 commits
-
-
Jacob Vosmaer authored
-
Jacob Vosmaer authored
-
- 28 Mar, 2017 1 commit
-
-
Alexander Randa authored
-
- 27 Mar, 2017 3 commits
-
-
Toon Claes authored
In API V4 all endpoints were changed so Merge Requests and Issues should be referred by iid, instead of id. Except the /notes endpoint was forgotten. So change the endpoints from: - /projects/:id/issues/:issue_id/notes - /projects/:id/merge_requests/:merge_request_id/notes To: - /projects/:id/issues/:issue_iid/notes - /projects/:id/merge_requests/:merge_request_iid/notes For Project Snippets nothing changes.
-
George Andrinopoulos authored
-
Toon Claes authored
Comments for a merge request should be obtained to the `notes` endpoint.
-
- 24 Mar, 2017 1 commit
-
-
Robert Speicher authored
-
- 20 Mar, 2017 8 commits
-
-
Adam Niedzielski authored
Closes #29631
-
George Andrinopoulos authored
-
Tomasz Maczukin authored
-
Tomasz Maczukin authored
In APIv1 we've been sending all jobs from previous stages and a `dependencies` list with names of jobs that user want to download artifacts from. This was selected on Runners side. In APIv1 we've planned to send only jobs that were defined (if any; and all previous jobs by default). However I've missed the fact that it was Runner who selected jobs, not GitLab. And now current version of APIV4 sends all jobs everytime. This commit fixes this. If user will define `dependencies` in his job, then GitLab will send only selected jobs.
-
Tomasz Maczukin authored
Artifacts download for authorization is using a job token of job to which the artifact belongs. In APIv1 the token was sent with dependent jobs details and in APIv4 it was designed to also contain it. However I forgot about this parameter while working on `/api/v4/jobs/request` endpoint. This commit adds a missing parameter which is required for APIv4 to work properly.
-
Tomasz Maczukin authored
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.
-
Tomasz Maczukin authored
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.
-
Rémy Coutable authored
Signed-off-by: Rémy Coutable <remy@rymai.me>
-
- 17 Mar, 2017 2 commits
-
-
Alex Sanford authored
-
Oswaldo Ferreira authored
-
- 16 Mar, 2017 3 commits
-
-
Rémy Coutable authored
Signed-off-by: Rémy Coutable <remy@rymai.me>
-
Toon Claes authored
To get the issues that have no label, the special keyword `No Label` can be used. This `No Label` label can be used like any other label.
-
Z.J. van de Weg authored
-
- 14 Mar, 2017 1 commit
-
-
Rémy Coutable authored
Signed-off-by: Rémy Coutable <remy@rymai.me>
-
- 13 Mar, 2017 3 commits
-
-
Rémy Coutable authored
This is not a good idea to memoize `json_response` using an instance variable because `rspec-retry` doesn't clear instance variables on retries, only `let` variables. This will avoid issues where retries would fail on a different line that the original failure, blurrying what's the real failure. Also, automatically add api: true to specs under /spec/requests/(ci/)?api/, and include JsonHelpers in controller, request and API specs. Signed-off-by: Rémy Coutable <remy@rymai.me>
-
Tomasz Maczukin authored
-
Bob Van Landuyt authored
merge_request_for_resolving_discussions -> merge_request_to_resolve_discussions_of
-