Additional Deployment Elements

At this stage we should already have a bootable image deployment, so the semantics surrounding a deployment Element implementation should already be decided.

Cancelled: After implementing what we did, it no longer makes much sense to treat these specially. Instead one can simply bst checkout a built artifact from the cache and tar it up or commit it to an external ostree repo. The rationale here is that BuildStream should not allow elements to touch outside of the restricted sandbox, every element is a mutation and it's output can be checked out directly, but an element cannot be told where to put it's output, the output is always an artifact.

OSTree Deployment

Deploying to an ostree repository is interesting from the perspective of generating full operating systems which are convenient for atomic upgrades, but besides this, it is also required in order to deploy Flatpak SDKs, Runtimes and Apps.

Status: TODO

Tarball Deployment

This is not currently a hard requirement for our milestones, but given that it will be extremely easy to implement and that it can be useful for sending out a tarred up SDK for a third party to chroot into, we should probably just do it.

Status: TODO

Projects/BuildStream/Roadmaps/Initial2017/AdditionalDeployments (last edited 2018-01-03 11:42:02 by SamThursfield)