remote-build should be asynchronous by default

[steinbro]

What needs to get done

Given the queue length and speed for some architectures, remote-build should exit immediately after uploading and submitting the job.

The user should be presented with a URL to open to check the build status, and the followup command to execute to fetch the result. A new argument like --wait could be used if the user wants the current behavior.

Why it needs to get done

A blocking command is reasonable for actions that are expected to take seconds or minutes, not hours or days.

[steinbro]

I discussed this with @mr-cal who recommends this be opt-in as a --detach flag.

[lengau]

cc @jnsgruk who I believe has opinions here :-)

[jnsgruk]

remote-build should exit immediately after uploading and submitting the job

I'm trying to work out when this would be useful?

If you're running in CI, you almost certainly want to wait until the command returns so you have the artifact to test/upload/do something with, and if you're running locally I think the same applies?

For me, the biggest issues with remote-build are around resilience when something goes wrong -- there is no (or limited?) notion of how to retry if at the end of the pack something unexpected happens and file isn't downloaded, or there is some transient error in fetching a package, etc.

I'm not necessarily against this, though I think if we're going to do it then making it opt-in is a better option, but I feel like I'm lacking context on where this would actually be useful?

[steinbro]

The situation is: you're a naive new user who wants to build your snap on riscv64. You run snapcraft remote-build --build-for riscv64 and... wait. You let it sit for an hour, or two, and it's still going. You need to pack up for the day, but you're not sure what to do. Can you background the process without breaking the connection? If you send Ctrl-C, will it terminate the remote build that's already so far along? Actually, has it even started yet? Is the progress indicator at all meaningful?

All of these are reasons why it's poor UX to use a blocking command for a task that has a decent chance of taking hours or days, at least when it's being invoked interactively. Agreed that it's perfectly suitable (and preferable) for a CI environment.

[jnsgruk]

Yeh, I guess that's fair. We'd need to think through the UX of how to pull that job back into the foreground - although I guess it's similar to the current resume flow.

Either way, I think this should be explcit with --bg or --detach or similar.

[steinbro]

Yeah, and the above scenario could even be largely addressed simply with an output message saying something to the effect of "This may take a long time; you can safely terminate this process before your build has completed and continue waiting later with --resume."

I don't know if Launchpad exposes an API for the queue length shown at https://launchpad.net/builders but that information (and the existence of that page) may be useful to share as well.