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