![]() - It delegates name, path, gitlab_url, ssh_url_to_repo - Remove ability to set this parameters using CI API This fixes GitLab project rename, namespace change, repository rename, etc. |
||
---|---|---|
.. | ||
README.md | ||
builds.md | ||
commits.md | ||
projects.md | ||
runners.md |
README.md
GitLab CI API
Resources
Authentication
GitLab CI API uses different types of authentication depends on what API you use. Each API document has section with information about authentication you need to use.
GitLab CI API has 4 authentication methods:
- GitLab user token & GitLab url
- GitLab CI project token
- GitLab CI runners registration token
- GitLab CI runner token
Authentication #1: GitLab user token & GitLab url
Authentication is done by
sending the private-token
of a valid user and the url
of an
authorized Gitlab instance via a query string along with the API
request:
GET http://gitlab.example.com/ci/api/v1/projects?private_token=QVy1PB7sTxfy4pqfZM1U&url=http://demo.gitlab.com/
If preferred, you may instead send the private-token
as a header in
your request:
curl --header "PRIVATE-TOKEN: QVy1PB7sTxfy4pqfZM1U" "http://gitlab.example.com/ci/api/v1/projects?url=http://demo.gitlab.com/"
Authentication #2: GitLab CI project token
Each project in GitLab CI has it own token. It can be used to get project commits and builds information. You can use project token only for certain project.
Authentication #3: GitLab CI runners registration token
This token is not persisted and is generated on each application start. It can be used only for registering new runners in system. You can find it on GitLab CI Runners web page https://gitlab-ci.example.com/admin/runners
Authentication #4: GitLab CI runner token
Every GitLab CI runner has it own token that allow it to receive and update GitLab CI builds. This token exists of internal purposes and should be used only by runners
JSON
All API requests are serialized using JSON. You don't need to specify
.json
at the end of API URL.
Status codes
The API is designed to return different status codes according to context and action. In this way if a request results in an error the caller is able to get insight into what went wrong, e.g. status code 400 Bad Request
is returned if a required attribute is missing from the request. The following list gives an overview of how the API functions generally behave.
API request types:
GET
requests access one or more resources and return the result as JSONPOST
requests return201 Created
if the resource is successfully created and return the newly created resource as JSONGET
,PUT
andDELETE
return200 OK
if the resource is accessed, modified or deleted successfully, the (modified) result is returned as JSONDELETE
requests are designed to be idempotent, meaning a request a resource still returns200 OK
even it was deleted before or is not available. The reasoning behind it is the user is not really interested if the resource existed before or not.
The following list shows the possible return codes for API requests.
Return values:
200 OK
- TheGET
,PUT
orDELETE
request was successful, the resource(s) itself is returned as JSON201 Created
- ThePOST
request was successful and the resource is returned as JSON400 Bad Request
- A required attribute of the API request is missing, e.g. the title of an issue is not given401 Unauthorized
- The user is not authenticated, a valid user token is necessary, see above403 Forbidden
- The request is not allowed, e.g. the user is not allowed to delete a project404 Not Found
- A resource could not be accessed, e.g. an ID for a resource could not be found405 Method Not Allowed
- The request is not supported409 Conflict
- A conflicting resource already exists, e.g. creating a project with a name that already exists422 Unprocessable
- The entity could not be processed500 Server Error
- While handling the request something went wrong on the server side