Builds API

API used by runners to receive and update builds.

Note: This API is intended to be used only by Runners as their own communication channel. For the consumer API see the Builds API.

Authentication

This API uses two types of authentication:

  1. Unique Runner's token which is the token assigned to the Runner after it has been registered.

  2. Using the build authorization token. This is project's CI token that can be found under the Builds section of a project's settings. The build authorization token can be passed as a parameter or a value of BUILD-TOKEN header.

These two methods of authentication are interchangeable.

Builds

Runs oldest pending build by runner

POST /ci/api/v1/builds/register
Attribute Type Required Description
token string yes Unique runner token
curl --request POST "https://gitlab.example.com/ci/api/v1/builds/register" --form "token=t0k3n"

Responses:

Status Data Description
201 yes When a build is scheduled for a runner
204 no When no builds are scheduled for a runner (for GitLab Runner >= v1.3.0)
403 no When invalid token is used or no token is sent
404 no When no builds are scheduled for a runner (for GitLab Runner < v1.3.0) or when the runner is set to paused in GitLab runner's configuration page

Update details of an existing build

PUT /ci/api/v1/builds/:id
Attribute Type Required Description
id integer yes The ID of a project
token string yes Unique runner token
state string no The state of a build
trace string no The trace of a build
curl --request PUT "https://gitlab.example.com/ci/api/v1/builds/1234" --form "token=t0k3n" --form "state=running" --form "trace=Running git clone...\n"

Incremental build trace update

Using this method you need to send trace content as a request body. You also need to provide the Content-Range header with a range of sent trace part. Note that you need to send parts in the proper order, so the begining of the part must start just after the end of the previous part. If you provide the wrong part, then GitLab CI API will return 416 Range Not Satisfiable response with a header Range: 0-X, where X is the current trace length.

For example, if you receive Range: 0-11 in the response, then your next part must contain a Content-Range: 11-... header and a trace part covered by this range.

For a valid update API will return 202 response with:

  • Build-Status: {status} header containing current status of the build,
  • Range: 0-{length} header with the current trace length.
PATCH /ci/api/v1/builds/:id/trace.txt

Parameters:

Attribute Type Required Description
id integer yes The ID of a build

Headers:

Attribute Type Required Description
BUILD-TOKEN string yes The build authorization token
Content-Range string yes Bytes range of trace that is sent
curl --request PATCH "https://gitlab.example.com/ci/api/v1/builds/1234/trace.txt" --header "BUILD-TOKEN=build_t0k3n" --header "Content-Range=0-21" --data "Running git clone...\n"

Upload artifacts to build

POST /ci/api/v1/builds/:id/artifacts
Attribute Type Required Description
id integer yes The ID of a build
token string yes The build authorization token
file mixed yes Artifacts file
curl --request POST "https://gitlab.example.com/ci/api/v1/builds/1234/artifacts" --form "token=build_t0k3n" --form "file=@/path/to/file"

Download the artifacts file from build

GET /ci/api/v1/builds/:id/artifacts
Attribute Type Required Description
id integer yes The ID of a build
token string yes The build authorization token
curl "https://gitlab.example.com/ci/api/v1/builds/1234/artifacts" --form "token=build_t0k3n"

Remove the artifacts file from build

DELETE /ci/api/v1/builds/:id/artifacts
Attribute Type Required Description
id integer yes The ID of a build
token string yes The build authorization token
curl --request DELETE "https://gitlab.example.com/ci/api/v1/builds/1234/artifacts" --form "token=build_t0k3n"