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

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

  • host_architecture: the concrete architecture, or {arch_all_host_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.