CI: continous integration support¶
CI module in SQUAD¶
This subsystem has the following features:
- receiving test job requests
- submitting test job requests to test execution backends
- pulling test job results from test execution backends
The data model for the CI subsystem looks like this:
+---------+ +---------+ +------------------------+
| TestJob |--->| Backend |--->| Backend implementation |
+---------+ +---------+ +------------------------+
|
| +---------------------+
+-------->| TestRun (from core) |
+---------------------+
TestJob holds the data related to a test job request. This test job is going to
be submitted to a Backend, and after SQUAD gets results back from that backend,
it will create a TestRun object with the results data. A Backend is a
representation of a given test execution system, such as a LAVA server, or
Jenkins. Backend
contains the necessary data to access the backend, such as
URL, username and password, etc, while Backend implementation
encapsulates
the details on how to interact with that type of system (e.g. API calls, etc).
So for example you can have multiple backends of the same type (e.g. different
2 LAVA servers).
For the CI loop integration to work, you need to run a few extra processes beyond the web interface. See Installation Instructions for production environments for details.
Submitting test job requests¶
The API is the following
POST /api/submitjob/:group/:project/:build/:environment
group
,project
,build
andenvironment
are used to identify which project/build/environment will be used to record the results of the test job.- The following data must be submitted as POST parameters:
backend
: name of a registered backend, to which this test job will be submitted.definition
: test job definition. The contents and format are backend-specific. If it is more convenient, the definition can also be submitted as a file upload instead of as a POST parameter.
Example (with test job definition as POST parameter):
$ DEFINITION="$(cat /path/to/definition.txt)"
$ curl \
--header "Auth-Token: $SQUAD_TOKEN" \
--form backend=lava \
--form definition="$DEFINITION" \
https://squad.example.com/api/submitjob/my-group/my-project/x.y.z/my-ci-env
Example (with test job definition as file upload):
$ curl \
--header "Auth-Token: $SQUAD_TOKEN" \
--form backend=lava \
--form definition=@/path/to/definition.txt \
https://squad.example.com/api/submitjob/my-group/my-project/x.y.z/my-ci-env
Submitted jobs on finished builds do not cause events (email/patchsource/callback notifications) to be triggered when the job is fetched. But there's an option named CI_RESET_BUILD_EVENTS_ON_JOB_RESUBMISSION that tells SQUAD to reset all build events on job submission so that they can be triggered once more next time the build reaches its "finished" state.
The user owning the SQUAD_TOKEN should be a member of the group and should have the "Staff Status" permission.
Submitting test job watch requests¶
Test job watch request are similar to test job requests. The only difference is that some other service submitted the test job for execution and SQUAD is requested to track the progress. After test job is finished SQUAD will retrieve the results and do post processing. The API is following:
POST /api/watchjob/:group/:project/:build/:environment
group
,project
,build
andenvironment
are used to identify which project/build/environment will be used to record the results of the test job.- The following data must be submitted as POST parameters:
backend
: name of a registered backend, to which this test job was be submitted.testjob_id
: test job ID. The contents and format are backend-specific.
Example (with test job definition as POST parameter):
$ curl \
--header "Auth-Token: $SQUAD_TOKEN" \
--form backend=lava \
--form testjob_id=123456 \
https://squad.example.com/api/watchjob/my-group/my-project/x.y.z/my-ci-env
Backend settings¶
Backends support internal settings that are stored in the database. It is assumed that settings are a valid YAML markup.
Supported backends¶
LAVA¶
SQUAD supports only LAVA v2. Old version of LAVA was made obsolete with 2017.11 LAVA release.
- LAVA backend supports the following settings:
- CI_LAVA_INFRA_ERROR_MESSAGES a list of strings that cause automated job resubmission when matched in the LAVA error message
- CI_LAVA_SEND_ADMIN_EMAIL
boolean flag that prevents sending admin emails for each resubmitted
job when set to
False
- CI_LAVA_HANDLE_SUITE
boolean flag that parses results from LAVA test suite when
set to
True
. Please note that this option can be overwritten by having the same option with different value in Project project_settings - CI_LAVA_CLONE_MEASUREMENTS
boolean flag that allows to save LAVA result as both Test and Measurement
when set to
True
. Default isFalse
. Can be overwritten for each project separately (similar to CI_LAVA_HANDLE_SUITE). - CI_LAVA_HANDLE_BOOT
boolean flag that parses LAVA auto-login-action as a boot
test when set to
True
. Default isFalse
. Can be overwritten for each project separately (similar to CI_LAVA_HANDLE_SUITE). NOTE: Before SQUAD 1.x series, the default behavior was to always process auto-login-action as boot. After 1.x, the default behavior has changed to do the opposite. - CI_LAVA_WORK_AROUND_INFRA_ERRORS boolean flag that allows to accept test results from 'Incomplete' jobs if the failure was caused by infrastracture. NOTE: Use with caution!
- CI_LAVA_JOB_ERROR_STATUS string that coincides with the LAVA job health. Used when sending email notifications for the ON_ERROR notification strategy
Example LAVA backend settings:
CI_LAVA_INFRA_ERROR_MESSAGES:
- 'Connection closed'
- 'lava_test_shell connection dropped.'
- 'fastboot-flash-action timed out'
- 'u-boot-interrupt timed out'
- 'enter-vexpress-mcc timed out'
- 'Unable to fetch git repository'
CI_LAVA_SEND_ADMIN_EMAIL: False
CI_LAVA_HANDLE_SUITE: True
TuxSuite¶
SQUAD supports only LAVA v2. Old version of LAVA was made obsolete with 2017.11 LAVA release.
- LAVA backend supports the following settings:
- TEST_METADATA_KEYS a list of strings to extract metadata info from test results
- BUILD_METADATA_KEYS a list of strings to extract metadata info from build results
Example TuxSuite backend settings:
BUILD_METADATA_KEYS:
- 'build_status'
- 'download_url'
- 'git_describe'
- 'git_ref'
- 'git_repo'
- 'git_sha'
- 'git_short_log'
- 'kernel_version'
- 'kconfig'
- 'target_arch'
- 'toolchain'
Multinode¶
SQUAD supports fetching results from LAVA multinode jobs. There are however a few limitations with this setup:
- All results from multinode will share environment name Since test jobs are submitted via SQUAD using the environment from submit URL there is no way for SQUAD to distinguish between different environmens on different parts of multinode job.
- Resubmit will repeat the whole set In SQUAD all parts of multinode job will share the multinode definition. For this reason re-submitting any part of the multinode job will result in new multinode job that includes all parts.
- Each part of the multinode job will be retrieved separately This means that each part will create a TestRun in SQUAD. This should not be a major issue as all results will still be available. Users need to make sure that the test names don't overlap as SQUAD will not have any means of distinguishing between identically named tests from different parts of multinode job.
Callbacks¶
In SQUAD, callbacks can be attached to Builds. They are triggered once the given build finishes fetching all test jobs from the backend.
There's currently two ways of attaching a callback to a build:
- POST /api/createbuild/<group_slug>/<project_slug>/<build_version> (when creating a build)
- POST /api/build/<build_id>/callbacks/ (attach to an existing build)
And the following parameters are accepted for both endpoints:
$ curl -X POST /api/build/<build_id>/callbacks/ \
-F "callback_url=https://your-callback-url.com"
The following attributes are optional:
- callback_method - string
post
orget
defining the callback request method. Defaults topost
- callback_event - string
on_build_finished
defining at which point the callback should be dispatched. Defaults toon_build_finished
- callback_headers - JSON-formatted string defining the callback headers, useful to define auth tokens
- callback_payload - JSON-formatted string defining the callback payload
- callback_payload_is_json - string with
true
orfalse
indicating whether the payload should be sent as JSON or as form-data. Defaults totrue
- callback_record_response - string with
true
orfalse
indicating whether or not the callback response should be recorded in SQUAD
Authentication¶
Callbacks usually require some sort of authentication. In SQUAD this can be accomplished in two forms:
- via
callback_headers
, where a JSON-formatted string is expected and will be used in the callback headers when it triggers. Ex:
$ curl -X POST /api/build/<build_id>/callbacks/ \
-F "callback_url=https://your-callback-url.com" \
-F "callback_headers='{\"Auth-Token\": \"your-really-safe-token\"}'"
- via project settings
/<group_slug>/<project_slug>/settings/advanced/
(YAML-formatted):
CALLBACK_HEADERS:
Auth-Token: your-really-safe-token
Notes¶
It's important to point out that:
- Multiple callbacks are allowed for a build, given that they point to different urls
- Attaching the same callback twice to the same build results in noop
- The callback headers will be merged with the build's project settings if available. If header names collide, project settings will get overwritten
- Callbacks are available in read-only mode at
GET /api/builds/<id>/callbacks/