File: piuparts.rst

package info (click to toggle)
debusine 0.14.1
  • links: PTS, VCS
  • area: main
  • in suites: forky, sid
  • size: 15,056 kB
  • sloc: python: 193,072; sh: 848; javascript: 335; makefile: 116
file content (92 lines) | stat: -rw-r--r-- 4,003 bytes parent folder | download | duplicates (2)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
.. workflow:: 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`` (:ref:`lookup-single`, required): the
    :artifact:`debian:source-package` or :artifact:`debian:upload` artifact
    that built the binaries to be tested
  * ``binary_artifacts`` (:ref:`lookup-multiple`, required): see
    :task:`Piuparts`

  * ``qa_suite`` (:ref:`lookup-single`, optional unless
    ``enable_regression_tracking`` or ``update_qa_results`` is True): the
    :collection:`debian:suite` collection that reference tests are being run
    against to detect regressions
  * ``reference_qa_results`` (:ref:`lookup-single`, optional unless
    ``enable_regression_tracking`` or ``update_qa_results`` is True): the
    :collection:`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 :task:`Piuparts`
  * ``environment`` (string, optional): the environment to run piuparts in
  * ``extra_repositories`` (optional): see :task:`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:

.. dynamic_data::
  :method: debusine.server.workflows.piuparts::PiupartsWorkflow.build_dynamic_data


``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 :task:`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
:bare-data:`promises <debusine:promise>`, 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``.