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 collectioninput
(required): see Task PackageBuild.source_artifact
may be adebian:source-package
or adebian: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 determinedistribution
orenvironment
, depending onbackend
.backend
(optional string): see Task PackageBuildarchitectures
(required list of strings): list of architectures to build. It can includeall
to build a binary forArchitecture: all
arch_all_host_architecture
(string, defaults toamd64
): concrete architecture on which to buildArchitecture: all
packagesextra_repositories
(optional, default unset): enable extra APT repositories, see Task PackageBuild.environment_variant
(optional string): variant of the environment we want to build on, e.g.buildd
; appended during environment lookup fortarget_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 withm
for minutes,h
for hours,d
for days, orw
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
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.