Permalink
Find file Copy path
Fetching contributors…
Cannot retrieve contributors at this time
511 lines (377 sloc) 21.5 KB

API definition

General information

GET operations will be non-authenticated. POST operations will require authentication using username+password.

Password information is stored in the database using the SHA512 hash.

All data will be sent/received using JSON objects, unless stated otherwise.

API calls

GET /api/last_tested_repo

Get the last tested repo since a specific time.

If a job_id is specified, the order of precedence for the repo returned is:

  • The last tested repo within that timeframe for that CI job.
  • The last tested repo within that timeframe for any CI job, so we can have several CIs converge on a single repo.
  • The last "consistent" repo, if no repo has been tested in the timeframe.

If sequential_mode is set to true, a different algorithm is used. Another parameter previous_job_id needs to be specified, and the order of precedence for the repo returned is:

  • The last tested repo within that timeframe for the CI job described by previous_job_id.
  • If no repo for previous_job_id is found, an error will be returned

The sequential mode is meant to be used by CI pipelines, where a CI (n) job needs to use the same repo tested by CI (n-1).

Normal response codes: 200

Error response codes: 400, 404, 415

Request:

Parameter Type Description
max_age integer Maximum age (in hours) for the repo to be considered. Any repo tested or being tested after "now - max_age" will be taken into account. If set to 0, all repos will be considered.
success boolean (optional) If set to a value, find repos with a successful/unsuccessful vote (as specified). If not set, any tested repo will be considered.
job_id string (optional) Name of the CI that sent the vote. If not set, no filter will be set on CI.
sequential_mode boolean (optional) Use the sequential mode algorithm. In this case, return the last tested repo within that timeframe for the CI job described by previous_job_id. Defaults to false.
previous_job_id string (optional) If sequential_mode is set to true, look for jobs tested by the CI identified by previous_job_id.

Response:

Parameter Type Description
commit_hash string commit_hash of tested repo
distro_hash string distro_hash of tested repo
success boolean whether the test was successful or not
job_id string name of the CI sending the vote
in_progress boolean is this CI job still in-progress?
timestamp integer timestamp for the repo
user string user who created the CI vote

GET /api/repo_status

Get all the CI reports for a specific repository.

Normal response codes: 200

Error response codes: 400, 404, 415

Request:

Parameter Type Description
commit_hash string commit_hash of the repo to fetch information for
distro_hash string distro_hash of the repo to fetch information for
success boolean (optional) If set to a value, only return the CI reports with the specified vote. If not set, return all CI reports.

Response:

The JSON output will contain an array where each item contains:

Parameter Type Description
job_id string name of the CI sending the vote
commit_hash string commit_hash of tested repo
distro_hash string distro_hash of tested repo
url string URL where to find additional information from the CI execution
timestamp integer Timestamp (in seconds since the epoch)
in_progress boolean False -> is this CI job still in-progress?
success boolean Was the CI execution successful?
notes Text Additional notes
user string user who created the CI vote

GET /api/promotions

Get all the promotions, optionally for a specific repository or promotion name. The output will be sorted by the promotion timestamp, with the newest first, and limited to 100 results per query.

Normal response codes: 200

Error response codes: 400, 404, 415

Request:

Parameter Type Description
commit_hash string (optional) If set, commit_hash of the repo to use as filter key. Requires distro_hash.
distro_hash string (optional) If set, commit_hash of the repo to use as filter key. Requires commit_hash.
promote_name string (optional) If set to a value, filter results by the specified promotion name.
offset integer (optional) If set to a value, skip the initial <offset> promotions.
limit integer (optional) If set to a value, limit the returned promotions amount to <limit>.

The JSON output will contain an array where each item contains:

Parameter Type Description
commit_hash string commit_hash of the promoted repo
distro_hash string distro_hash of the promoted repo
repo_hash string Repository hash, composed of the commit_hash and short distro_hash
repo_url string Full URL of the promoted repository
promote_name string name used for the promotion
timestamp integer Timestamp (in seconds since the epoch)
user string user who created the promotion

The array will be sorted by the promotion timestamp, with the newest first.

GET /api/metrics/builds

Retrieve statistics on the number of builds during a certain period, optionally filtered by package name.

Normal response codes: 200

Error response codes: 400, 415

Parameter Type Description
start_date string Start date for the period, in YYYY-mm-dd format. The start date is included in the reference period.
end_date string End date for the period, in YYYY-mm-dd format. The end date is not included in the period, so it is start_date <= date < end_date.
package_name string (optional) If set to a value, report metrics only for the specified package name.

Response:

Parameter Type Description
succeeded integer Number of commits that were built successfully in the period
failed integer Number of commits that failed to build in the period
total integer Total number of commits processed in the period

POST /api/last_tested_repo

Get the last tested repo since a specific time (optionally for a CI job), and add an "in progress" entry in the CI job table for this.

If a job_id is specified, the order of precedence for the repo returned is:

  • The last tested repo within that timeframe for that CI job.
  • The last tested repo within that timeframe for any CI job, so we can have several CIs converge on a single repo.
  • The last "consistent" repo, if no repo has been tested in the timeframe.

If sequential_mode is set to true, a different algorithm is used. Another parameter previous_job_id needs to be specified, and the order of precedence for the repo returned is:

  • The last tested repo within that timeframe for the CI job described by previous_job_id.
  • If no repo for previous_job_id is found, an error will be returned

The sequential mode is meant to be used by CI pipelines, where a CI (n) job needs to use the same repo tested by CI (n-1).

Normal response codes: 201

Error response codes: 404, 415

Request:

Parameter Type Description
max_age integer Maximum age (in hours) for the repo to be considered. Any repo tested or being tested after "now - max_age" will be taken into account. If set to 0, all repos will be considered.
reporting_job_id string Name of the CI that will add the "in progress" entry in the CI job table
success boolean (optional) If set to a value, find repos with a successful/unsuccessful vote (as specified). If not set, any tested repo will be considered.
job_id string (optional) name of the CI that sent the vote. If not set, no filter will be set on CI.
sequential_mode boolean (optional) Use the sequential mode algorithm. In this case, return the last tested repo within that timeframe for the CI job described by previous_job_id. Defaults to false.
previous_job_id string (optional) If sequential_mode is set to true, look for jobs tested by the CI identified by previous_job_id.

Response:

Parameter Type Description
commit_hash string commit_hash of tested repo
distro_hash string distro_hash of tested repo
success boolean whether the test was successful or not
job_id string name of the CI sending the vote
in_progress boolean True -> is this CI job still in-progress?
timestamp integer Timestamp for this CI Vote (taken from the DLRN system time)
user string user who created the CI vote

POST /api/report_result

Report the result of a CI job.

Normal response codes: 201

Error response codes: 400, 404, 415, 500

Request:

Parameter Type Description
job_id string name of the CI sending the vote
commit_hash string commit_hash of tested repo
distro_hash string distro_hash of tested repo
url string URL where to find additional information from the CI execution
timestamp integer Timestamp (in seconds since the epoch)
success boolean Was the CI execution successful?
notes Text Additional notes (optional)

Response:

Parameter Type Description
job_id string name of the CI sending the vote
commit_hash string commit_hash of tested repo
distro_hash string distro_hash of tested repo
url string URL where to find additional information from the CI execution
timestamp integer Timestamp (in seconds since the epoch)
in_progress boolean False -> is this CI job still in-progress?
success boolean Was the CI execution successful?
notes Text Additional notes
user string user who created the CI vote

POST /api/promote

Promote a repository. This can be implemented as a local symlink creation in the DLRN worker, or any other form in the future.

Note the API will refuse to promote using promote_name="consistent" or "current", since those are reserved keywords for DLRN.

Normal response codes: 201

Error response codes: 400, 403, 404, 415, 500

Request:

Parameter Type Description
commit_hash string commit_hash of the repo to be promoted
distro_hash string distro_hash of the repo to be promoted
promote_name string name to be used for the promotion. In the current implementation, this is the name of the symlink to be created

Response:

Parameter Type Description
commit_hash string commit_hash of the promoted repo
distro_hash string distro_hash of the promoted repo
repo_hash string Repository hash, composed of the commit_hash and short distro_hash
repo_url string Full URL of the promoted repository
promote_name string name used for the promotion
timestamp integer Timestamp (in seconds since the epoch)
user string user who created the promotion

POST /api/remote/import

Import a commit built by another instance. This API call mimics the behavior of the dlrn-remote command, with the only exception of not being able to specify a custom rdoinfo location.

Normal response codes: 201

Error response codes: 400, 415, 500

Request:

Parameter Type Description
repo_url string Base repository URL for remotely generated repo

Response:

Parameter Type Description
repo_url string Base repository URL for imported remote repo

Running the API server using WSGI

Requirements

It is possible to run the DLRN API server as a WSGI process in Apache. To do this, you need to install the following packages:

$ sudo yum -y install httpd mod_wsgi

WSGI file and httpd configuration

To run the application, you need to create a WSGI file. For example, create /var/www/dlrn/dlrn-api.wsgi with the following contents:

import os
import sys
sys.path.append('/home/centos-master/.venv/lib/python2.7/site-packages/')

def application(environ, start_response):
    os.environ['CONFIG_FILE'] = environ['CONFIG_FILE']
    from dlrn.api import app
    return app(environ, start_response)

You need to change the path appended using sys.path.append to be the path to the virtualenv where you have installed DLRN.

Then, create an httpd configuration file to load the WSGI application. The following is an example file, named /etc/httpd/conf.d/wsgi-dlrn.conf:

<VirtualHost *>
    ServerName example.com

    WSGIDaemonProcess dlrn  user=centos-master group=centos-master threads=5
    WSGIScriptAlias / /var/www/dlrn/dlrn-api-centos-master.wsgi
    SetEnv CONFIG_FILE /etc/dlrn/dlrn-api.cfg

    <Directory /var/www/dlrn>
        WSGIProcessGroup dlrn
        WSGIApplicationGroup %{GLOBAL}
        WSGIScriptReloading On
        WSGIPassAuthorization On
        Order deny,allow
        Allow from all
    </Directory>
</VirtualHost>

Set CONFIG_FILE to the path of the DLRN configuration file, and make sure you specify the right user and group for the WSGIDaemonProcess line.

DLRN API configuration

The DLRN API take a default configuration from file dlrn/api/config.py. Since it may not match your actual configuration when deployed as an WSGI application, you can create a configuration file, /etc/dlrn/dlrn-api.cfg in the above example, with the following syntax:

DB_PATH = 'sqlite:////home/centos-master/DLRN/commits.sqlite'
REPO_PATH = '/home/centos-master/DLRN/data/repos'
CONFIG_FILE = 'projects.ini'

Where DB_PATH is the path to the SQLite database for your environment, REPO_PATH will point to the base directory for the generated repositories, and CONFIG_FILE will point to the projects.ini file used when running DLRN.

User management

There is a command-line tool to manage DLRN API users:

User creation

Use the create subcommand to create a new user.

$ dlrn-user create --username foo --password bar

If you do not specify a password in the command-line, you will be prompted to enter one interactively.

User update

You can use the update subcommand to change user data. Currently, only the password can be changed.

$ dlrn-user update --username foo --password new

User deletion

Use the delete subcommand to delete a user.

$ dlrn-user delete --username foo

The command will ask for confirmation, and you have to type "YES" (without the quotes) in uppercase to delete the user. You can also avoid the confirmation request by adding the --force parameter.

$ dlrn-user delete --username foo --force