1. 20 Mar, 2017 10 commits
    • Rémy Coutable's avatar
      Fix ProjectWiki#http_url_to_repo signature · c1ed5d4b309f
      Rémy Coutable authored
      New Gitlab::UrlSanitizer.http_credentials_for_user method responsible
      for generating a credentials hash from a user.
      Signed-off-by: default avatarRémy Coutable <remy@rymai.me>
    • Dongqing Hu's avatar
      Fix Project Wiki update · ae8e0d815abd
      Dongqing Hu authored
    • George Andrinopoulos's avatar
    • Jarka Kadlecova's avatar
    • Tomasz Maczukin's avatar
      Update example's name in /runners/verify tests · 1fa3aa417c13
      Tomasz Maczukin authored
    • Tomasz Maczukin's avatar
      Send only defined dependencies · bef06efb327e
      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's avatar
      Send token of depenent job · 5b4030b44bdb
      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
    • Tomasz Maczukin's avatar
      Remove legacy Runners support in /api/v4/jobs/request · 31e3f670b5be
      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
      This commit removes useless code and complexity.
    • Tomasz Maczukin's avatar
      Make runner's veryfication working again · 722f2d0a0dd1
      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
      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
    • Rémy Coutable's avatar
  2. 17 Mar, 2017 12 commits
  3. 16 Mar, 2017 18 commits