Workflows

Workflows are server-side logic that can schedule and combine server tasks and worker tasks to automate complex operations.

Workflows are created from a workflow template chosen from a set maintained by the server administrators, plus data coming from user input.

Workflow noop

This is a workflow that does nothing, and is mainly used in tests.

• task_data: empty

Workflow sbuild

This workflow takes a source package and creates sbuild work requests (see Sbuild task) to build it for a set of architectures.

• task_data:

  • input (required): see Task PackageBuild

  • target_distribution (required string): vendor:codename to specify the environment to use for building. It will be used to determine distribution or environment, depending on backend.

  • backend (optional string): see Task PackageBuild

  • architectures (required list of strings): list of architectures to build. It can include all to build a binary for Architecture: all

The source package will be built on the intersection of the provided list of architectures and the architectures supported in the Architecture: field of the source package. The architecture all packages are built in an amd64 environment.

The workflow may also apply a denylist of architectures if it finds a debian:suite collection corresponding to the build distribution/environment, and that suite provides one.

Workflow update_environments

This workflow schedules work requests to build tarballs and images, and adds them to a debian:environments collection.

• task_data:

  • vendor (required): the name of the distribution vendor, used to look up the target debian:environments collection

  • targets (required): a list of dictionaries as follows:

    • codename (required): the codename of an environment to build

    • variant (optional): an identifier to use as the variant name when adding the resulting artifacts to the target collection; if not given, the default is not to set a variant name

    • architectures (required): a list of architecture names of environments to build for this codename

    • mmdebstrap_template (optional): a template to use to construct data for the Mmdebstrap task

    • simplesystemimagebuild_template (optional): a template to use to construct data for the SimpleSystemImageBuild task

For each target, the workflow creates a group. Then, for each codename/architecture combination in that target, it fills in whichever of mmdebstrap_template and simplesystemimagebuild_template that are present and uses them to construct child work requests. In each one, bootstrap_options.architecture is set to the target architecture, and bootstrap_repositories[].suite is set to the target codename if it is not already set.

The workflow adds an event reaction to each child work request as follows, where {vendor} is the vendor from the workflow’s task data, {category} is debian:system-tarball for mmdebstrap tasks and debian:system-image for simplesystemimagebuild tasks, and {codename} is the codename from the corresponding target in the task data:

on_success:
  - action: "update-collection-with-artifacts"
    artifact_filters:
      category: "{category}"
    collection: "{vendor}@debian:environments"
    variables:
      - codename: "{codename}"

If the target in the task data has a variant field, then this event reaction’s variables field also includes variant: "{variant}".