Uploading packages
Pipeline considerations
The package_upload workflow will typically be used as a sub-workflow of a smart “pipeline” workflow. There are three main use cases:
Upload a source package to debusine, have it tested, and then have debusine pass on that upload to an external upload queue.
In this case, the
package_upload
workflow’s task data should setsource_artifact
to the source package and leavebinary_artifacts
empty.Upload a source package to debusine, have it tested, and then have debusine upload both the source and all built binaries to an external upload queue. (For example, this is useful when uploading a package to Debian that will land in the NEW queue, since Debian currently requires binaries for NEW uploads.)
In this case, the
package_upload
workflow’s task data should setsource_artifact
to the source package, setbinary_artifacts
to a list of single lookups matching each of the binary uploads from the super-workflow’s internal collection (e.g.[internal@collections/name:build-all, internal@collections/name:build-amd64]
, and setmerge_uploads
to True.debusine acts as a build daemon, building a source package for a number of architectures and uploading each of them as soon as the builds finish.
In this case, the
package_upload
workflow’s task data should leavesource_artifact
unset, setbinary_artifacts
to a list of single lookups matching each of the binary uploads from the super-workflow’s internal collection, and setmerge_uploads
to False.
Generic code for creating child work requests using artifacts from the workflow’s internal collection adds appropriate dependencies on the work requests that are expected to provide those artifacts.
If the parent workflow needs some kind of manual validation step to complete
before starting the upload (typically in the case of manual uploads but not
when acting as a build daemon), it should add a dependency from the
package_upload
sub-workflow to the validation workflow step. The
package_upload
sub-workflow will be populated before validation is
complete (since the root workflow handles population of all its
sub-workflows), but it will not start running until validation is complete.