All requests to the API must provide a valid API key in the
Auth-Key
HTTP header. The only exception are the endpoints that
manipulate the API keys themselves, in which case the requests must be
authenticated using another method (HTTP basic authentication, client
certificates, etc).
Example:
$ KEY='00000000-0000-0000-0000-000000000000' $ curl --header "Auth-Key: $KEY" https://ci.debian.net/api/v1/auth
To get an API key, you first need to be logged-in the self-service interface. You should then see a "Get API Key" button that will redirect you to the right page.
This endpoint can be used to test your API key. It returns a 200 (OK) HTTP status if your API key is valid, and 403 (Forbidden) otherwise. The response also includes the username corresponding to the API key in the Auth-User
header.
Gets the reject list i.e. list of packages which won’t be tested by this DebCI instance.
The response is a JSON object where each key is a package. The value of each package is an object where each key is a suite for which it is blocked. Each suite key has an object with blocked architecture as key which is followed by a level of versions. The wildcard *
is a valid value signifying all suites.
{ "package": { "suite": { "arch": { "version": "" } } } }
Example:
{ "bash": { "testing": { "*": { "*": "" } }, "unstable": { "amd64": { "5.0.0": "" } } } }
This blocks bash
from testing
for all architectures and versions. It also blocks it for unstable but only for amd64 and version 5.0.0.
Presents a simple UI for retrying a test
Retries the test with the given ID.
Retrieves results for your test requests.
Parameters:
since
: UNIX timestamp; tells the API to only retrieve results that are newer then the given timestamp, i.e. jobs that were either created after it, or finished after it.
Some test results may be returned in multiple calls to this endpoint that use different value of since
. For example, while a test is still running, it will be returned, but its status will be null
. After it is completed, it will be updated to have the final status. So, if you are processing test results, make sure you support receiving the same result more than once, and updating the corresponding data on your side.
The response is a JSON object containing the following keys:
until
: UNIX timestamp that represents the timestamp of the latest results available. can be used as the since
parameter in subsequent requests to limit the list of results to only the ones newer than it.
results
: a list of test results, each of each will containing at least the following items:
trigger
: the same string that was provided in the test submission. (string)
package
: name of tested package (string)
arch
: architecture where the test ran (string)
suite
: suite where the test ran (string)
version
: version of the package that was tested (string)
status
: “pass”, “fail”, or “tmpfail” (string), or null if the test didn’t finish yet.
run_id
: an id for the test run, generated by debci (integer)
is_private
: bool value to specify whether test is private or not
extra_apt_sources
: an array specifying extra apt sources added to /etc/apt/sources.list.d
for the test.
updated_at
: timestamp of the last update to the job (string)
date
: timestamp of when the test run finished (string)
Note that this endpoint will only list requests that were made by the same API key that is being used to call it.
Example:
$ curl --header "Auth-Key: $KEY" https://ci.debian.net/api/v1/test?since=1508072999 { "until": 1508159423, "results": [ { "trigger": "foo/1.2", "package": "bar", "arch": "amd64", "suite": "testing", "version": "4.5", "status": "fail", "run_id": 12345 "is_private": false, "extra_apt_sources": [], }, { "trigger": "foo/1.2", "package": "baz", "arch": "amd64", "suite": "testing", "version": "2.7", "status": "pass", "run_id": 12346, "is_private": true, "extra_apt_sources": [], } ] }
“‘
URL parameters:
:suite
: which suite to test
:arch
: which architecture to test
Other parameters:
tests
: a JSON object describing the tests to be executed. This parameter can be either a file upload or a regular POST parameter.
priority
: an integer between 1 and 10 describing the priority to assign the requested tests
The tests
JSON object must be an Array of objects. Each object represents a single test request, and can contain the following keys:
package
: the (source!) package to be tested
trigger
: a string that identifies the reason why this test is being requested. debci only stores this string, and it does not handle this in any special way.
pin-packages
: an array describing packages that need to be obtained from different suites than the main one specified by the suite
parameter. This is used e.g. to run tests on testing
with a few packages from unstable
, or on unstable
with a few packages from experimental
. Each item of the array is another array with 2 elements: the first is the package, and the second is the source. Examples:
["foo", "unstable"]
: get foo
from unstable
["src:bar", "unstable"]
: get all binaries built from bar
from unstable
["foo,src:bar", "unstable"]
: get foo
and all binaries built from bar
from unstable
Note: each suite can be only present once.
is_private
: bool value that need to be set true
if test is private and if not given takes false
as default.
extra-apt-sources
: an array specifying extra apt sources which is added to /etc/apt/sources.list.d
. Note that if you use both extra-apt-sources
and pin-packages
, then you must pass all APT sources necessary to resolve your pinnings.
In the example below, we are requesting to test debci
and vagrant
from testing, but with all binaries that come from the ruby-defaults
source coming from unstable:
$ cat tests.json [ { "package": "debci", "trigger": "ruby/X.Y", "pin-packages": [ ["src:ruby-defaults", "unstable"] ], "is_private": true, "extra-apt-sources": [ "bullseye-security" ] }, { "package": "vagrant", "trigger": "ruby/X.Y", "pin-packages": [ ["src:ruby-defaults", "unstable"] ] } ] # tests as a file upload $ curl --header "Auth-Key: $KEY" --form tests=@tests.json https://ci.debian.net/api/v1/test/testing/amd64 # tests as a regular POST parameter, with specific priority $ curl --header "Auth-Key: $KEY" --data tests="$(cat tests.json)" --data priority=8 https://ci.debian.net/api/v1/test/testing/amd64
This is a shortcut to request a test run for a single package.
URL parameters:
:suite
: which suite to test
:arch
: which architecture to test
:package
: which (source!) package to test
priority
: an integer between 1 and 10 describing the priority to assign the requested tests
is_private
: bool value that need to be set true
if test is private and if not given takes false
as default
extra_apt_sources
: a JSON array specifying extra apt sources which is added to /etc/apt/sources.list.d
.
Example:
$ curl --header "Auth-Key: $KEY" --data '' https://ci.debian.net/api/v1/test/unstable/amd64/debci
To publish private tests.
Parameter:
run_ids
: a string of run ids of private tests to be published separated by comma (,)
Example:
curl --header "Auth-Key: $KEY" --data 'run_ids=25,26' https://ci.debian.net/api/v1/test/publish