autopkgtest

# Workflow `autopkgtest`

This workflow schedules autopkgtests for a single source package on a set of architectures.

- `task_data`:

  - `prefix` (string, optional): prefix this string to the item names provided in the internal collection

  - `reference_prefix` (string, optional unless `enable_regression_tracking` is set): prefix for the item names provided in the internal collection in the corresponding workflow run for reference tests

  - `source_artifact` (Single lookup, required): see Autopkgtest

  - `binary_artifacts` (Multiple lookup, required): see Autopkgtest

  - `context_artifacts` (Multiple lookup, optional): see Autopkgtest

  - `qa_suite` (Single lookup, optional unless `enable_regression_tracking` is True or `update_qa_results` is either `yes` or `force`): the debian:suite collection that reference tests are being run against to detect regressions

  - `reference_qa_results` (Single lookup, optional unless `enable_regression_tracking` is True or `update_qa_results` is either `yes` or `force`): the debian:qa-results collection that contains the reference results of QA tasks to use to detect regressions

  - `enable_regression_tracking` (boolean, defaults to False): configure the workflow to detect and display regressions in QA results

  - `update_qa_results` (string, defaults to `no`): whether to update reference QA results. Allowed values are `no`, `yes`, and `force`. When set to `yes`, the workflow runs QA tasks and updates the collection passed in `reference_qa_results` with the results, unless that collection already contains a current matching result. `force` is like `yes`, but does not check whether the collection already contains a current matching result.

    For compatibility, boolean False is equivalent to `no`, and boolean True is equivalent to `yes`.

  - `vendor` (string, required): the distribution vendor on which to run tests

  - `codename` (string, required): the distribution codename on which to run tests

  - `backend` (string, optional): see Autopkgtest

  - `extra_repositories` (optional): see Autopkgtest

  - `architectures` (list of strings, optional): if set, only run on any of these architecture names

  - `arch_all_build_architecture` (string, defaults to `amd64`): concrete architecture on which to run tasks for `Architecture: all` packages

  - `include_tests`, `exclude_tests`, `debug_level`, `pin_packages`, `extra_environment`, `needs_internet`, `fail_on`, `timeout`: see Autopkgtest

The workflow computes dynamic metadata as:

- subject: package name of `source_artifact`

- parameter_summary: package name_version

- source_artifact_id: id of the source artifact

- binary_artifacts_ids: ids of the binary artifacts

- context_artifacts_ids: ids of the context artifacts

Tests will be run on the intersection of the provided list of architectures (if any) and the architectures provided in `binary_artifacts`. If only `Architecture: all` binary packages are provided in `binary_artifacts`, then tests are run on `{arch_all_build_architecture}`.

The workflow creates an Autopkgtest for each concrete architecture, with task data:

- `input.source_artifact`: `{source_artifact}`

- `input.binary_artifacts`: the subset of `{binary_artifacts}` that are for the concrete architecture or `all`

- `input.context_artifacts`: the subset of `{context_artifacts}` that are for the concrete architecture or `all`

- `build_architecture`: the concrete architecture

- `environment`: `{vendor}/match:codename={codename}`

- `backend`: `{backend}`

- `extra_repositories` copied from the workflow task, and extended with overlay repositories (e.g. `experimental`) if `codename` is a known overlay.

- `include_tests`, `exclude_tests`, `debug_level`, `extra_environment`, `needs_internet`, `fail_on`, `timeout`: copied from workflow task data parameters of the same names

Any of the lookups in `input.source_artifact`, `input.binary_artifacts`, or `input.context_artifacts` may result in promises, and in that case the workflow adds corresponding dependencies. Binary promises must include an `architecture` field in their data.

Each work request provides its debian:autopkgtest artifact as output in the internal collection, using the item name `{prefix}autopkgtest-{architecture}`.

Todo

It would be useful to have a mechanism to control multiarch tests, such as testing i386 packages on an amd64 testbed.