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:

    • prefix (optional): prefix this string to the item names provided in the internal collection

    • 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

    • arch_all_host_architecture (string, defaults to amd64): concrete architecture on which to build Architecture: all packages

    • environment_variant (optional string): variant of the environment we want to build on, e.g. buildd; appended during environment lookup for target_distribution above.

    • build_profiles (optional, default unset): select a build profile, see Task PackageBuild.

    • binnmu (optional, default unset): build a binNMU, see Task PackageBuild.

    • retry_delays (optional list): a list of delays to apply to each successive retry; each item is an integer suffixed with m for minutes, h for hours, d for days, or w for weeks.

    • signing_template_names (dictionary, optional): mapping from architecture to list of names of binary packages that should be used as templates by the ExtractForSigning task

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. Architecture all packages are built on arch_all_host_architecture.

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.

The workflow adds event reactions that cause the debian:upload artifact in the output for each architecture to be provided as {prefix}build-{architecture} in the workflow’s internal collection.

If the workspace has a debian:package-build-logs collection, then the workflow adds update-collection-with-data and update-collection-with-artifacts event reactions to each sbuild work request to record their build logs there.

If retry_delays is set, then the workflow adds a corresponding on_failure retry-with-delays action to each of the sbuild work requests it creates. This provides a simplistic way to retry dependency-wait failures. Note that this currently retries any failure, not just dependency-waits; this may change in future.

If signing_template_names exists, then the workflow adds event reactions that cause the corresponding debian:binary-package artifacts in the output for each architecture to be provided as {prefix}signing-template-{architecture}-{binary_package_name} in the workflow’s internal collection.