Repository navigation
remote-build should be asynchronous by default #1105
Description
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.
Activity
steinbro commentedon Jul 2, 2026
I discussed this with @mr-cal who recommends this be opt-in as a
--detachflag.lengau commentedon Jul 14, 2026
cc @jnsgruk who I believe has opinions here :-)
jnsgruk commentedon Jul 15, 2026
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-buildare 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 commentedon Jul 17, 2026
The situation is: you're a naive new user who wants to build your snap on riscv64. You run
snapcraft remote-build --build-for riscv64and... 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 commentedon Jul 17, 2026
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
resumeflow.Either way, I think this should be explcit with
--bgor--detachor similar.steinbro commentedon Jul 17, 2026
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.