sbuild

Workflow sbuild

This workflow takes a source package and creates Sbuild work requests 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 PackageBuild. source_artifact may be a debian:source-package or a debian:upload. This workflow cannot be populated until this is a real artifact, not merely a promise.

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

    • extra_repositories (optional, default unset): enable extra APT repositories, see PackageBuild.

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

    • binnmu (optional, default unset): build a binNMU, see 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 workflow computes dynamic metadata as:

  • subject: package name of input.source_artifact

  • parameter_summary: package name of input.source_artifact_”version”

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 extra_repositories are copied from the workflow task, and extended with overlay repositories (e.g. experimental) if target_distribution is a known overlay.

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, and the debian:package-build-log artifact in the output for each architecture to be provided as {prefix}buildlog-{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.