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

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.

Architecture-independent packages will be included in every run.

If all binary_artifacts are for architecture-independent, then the workflow schedules one run for each available architecture (intersected with the architectures list, if provided).

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

  • 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.