piuparts

# Workflow `piuparts`

This workflow schedules `piuparts` checks for binaries built by 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): the debian:source-package or debian:upload artifact that built the binaries to be tested

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

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

  - `reference_qa_results` (Single lookup, optional unless `enable_regression_tracking` or `update_qa_results` is True): 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` (boolean, defaults to False): when set to True, the workflow runs QA tasks and updates the collection passed in `reference_qa_results` with the results.

  - `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 Piuparts

  - `environment` (string, optional): the environment to run piuparts in

  - `extra_repositories` (optional): see Piuparts

  - `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

The workflow computes dynamic metadata as:

- subject: source package names of `binary_artifacts` separated by spaces

- parameter_summary: “subject” in `vendor`:`codename`

- source_artifact_id: id of the `source_artifact`

- binary_artifacts_ids: ids of the `binary_artifacts`

`piuparts` will be run on the intersection of the provided list of architectures (if any) and the architectures provided in `binary_artifacts`, in each case grouping arch-all + arch-any together. If only `Architecture: all` binary packages are provided in `binary_artifacts`, then `piuparts` will be run once for arch-all on `{arch_all_build_architecture}`.

The workflow creates a Piuparts task for each concrete architecture, with task data:

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

- `build_architecture`: the concrete architecture, or `{arch_all_build_architecture}` if only `Architecture: all` binary packages are being checked by this task

- `environment`: `{environment}` if specified, falling back to `{vendor}/match:codename={codename}`

- `base_tgz`: `{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.

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

Todo

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

Todo

It would be useful to be able to set `base_tgz` separately from `environment`.