cloudapi download

[bcl]

This pull request includes:

• adequate testing for the new functionality or fixed issue
• adequate documentation informing people about the change such as
  • submit a PR for the READMEs listed here
  • submit a PR for the osbuild.org website repository if this PR changed any behavior not covered by the automatically updated READMEs

[croissanne]

So I wonder if we even need this. Currently we implemented downloading / copying etc… the artefact just by using cockpit-files (osbuild/image-builder-frontend#2820).

I think it might make more sense to expand the local target to accept a target artefact location / output directory instead (like ~/.cache/cockpit-image-builder/artefacts) or something.

[bcl]

I think we should have both. The cloudapi is incomplete without this, and may be accessed by things that can't use the local filesystem or cockpit plugins. And doing it that way feels like a hack -- it is breaking the separation between the internals and the client needing to know details like file paths.

[croissanne]

I think we should have both. The cloudapi is incomplete without this, and may be accessed by things that can't use the local filesystem or cockpit plugins. And doing it that way feels like a hack -- it is breaking the separation between the internals and the client needing to know details like file paths.

Hm I think the separation is maintained as long as the path to the artefacts are resolved by composer, it's in the upload status, part of the osbuild job result. So it's not like the user is aware of where exactly the artefacts are saved, and if the artefact directory would change, the cockpit plugin wouldn't have to be updated.

I'm not sure if it's a hack to have composer output an artefact somewhere on your system. And in the case of the cockpit plugin, we have to pipe it through the cockpit api anyway, as the cockpit server might be remote. Might as well let cockpit-files handle all that. Though I agree it would be nicer to save it somewhere else, so that we don't have to point the user to /var/lib/osbuild-composer, which is an internal directory.

[bcl]

I'm not sure what you mean by it being in the upload status. But either way I need this in order to finish the move from weldr api to cloud api, and for composer-cli. The cloudapi is incomplete without this.

[bcl]

I'm not sure what you mean by it being in the upload status.

LOL. I figured it out :)

[lucasgarfield]

@croissanne we'll also want this for composer-cli as part of our work towards deprecating the weldr api, won't we?

[kingsleyzissou]

Thanks this look good to me, maybe @croissanne can have another look first