UX: Dead end when image-build fails during prebuild

[geropl]

Bug description

When an image build for a preview fails, the user is left on alone on a HeadlessLogView, without any error being displayed.

The gap here stems from the fact that the HeadlessLogView assumes we will navigate away from it on workspace start, no matter the prebuild result. But we'll only do so if ideUrl is set for that instance - which is not the case during image builds.

Context:

• discovered as part of Prebuild process gets stuck (when updating .gitpod.Dockerfile) #4856 (comment)

Steps to reproduce

1. apply a commit like this to a testing branch
2. start a prebuild which triggers an image build taking longer than that period

Expected behavior

The exact behavior is up to discussion, but we should make sure we unstuck the user here!

Example repository

No response

Anything else?

No response

[csweichel]

/schedule

[geropl]

/cc @jankeromnes @gtsiolis

[csweichel]

If the image build for a prebuild fails, the following options come to mind:

1. restart the workspace with default image and no prebuild:

• pro: starts a workspace immediately
• con: it's not very clear to the user what just happened. They end up in a workspace with an unexpected image and no prebuild

2. restart the workspace with no prebuild:

• pro: starts a workspace immediately
• con: it's likely that the image build will fail here, too, so the user will be left with an error after all. At least now they can understand what the error is

3. show an option button giving the user a choice to "Skip Prebuild" and/or "Skip Prebuild and use Default Image"

• pro: the least magical choice
• con: really feels like the "boot in rescue mode"

Either way, we should probably show the image build error irregardless :)

[csweichel]

Let's clarify on how we want to do this, and then re-schedule (due to its priority it will end up at the top of the list anyways).
I'll remove this from groundwork until then.

[geropl]

Regarding 2:

con: it's likely that the image build will fail here, too, so the user will be left with an error after all. At least now they can understand what the error is

This is exactly what happened in the incident where this was discovered. So no viable option IMO.

Regarding 3: Given the above "Skip Prebuild and use Default Image" feels like the only non-magic option that helps the user.

Another option:

4. show a button "Open Docker Editor" bringing the user into the fast-feedback-loop we're implementing for the onboarding flow to fix this issue quickly. 😍 But that might be out-of-scope for this, depending on the availability/maturity of said editor.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[shaal]

Is there a solution for this issue?

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[shaal]

Is there a solution for this issue?

[gtsiolis]

Haven't seen any recent discussions about this. Probably a fallback action during workspace start could suffice. Do you still run into this, @shaal?

It could be interesting to see some metrics about the error rates here and decide about the severity of this. Cc @jldec @jldec

[shaal]

@gtsiolis It's hard to know what is the cause of the issue, but I'm still experiencing prebuilds are "stuck".
Without status/warning/error messages, this process can be frustrating/confusing.

[jldec]

Prioritizing as part of #7812

[AlexTugarev]

This might be solved in 5a6250c.

The "How to test" from #10357 should be sufficient to verify this issue on a preview environment. Maybe the procedure would require to append RUN exit 1 to the Dockerfile to let the image build fail intentionally.

[laushinka]

Tested this with an image build that fails and I was able to continue. I will close this.
@shaal I hope this has worked for you as well.

[shaal]

Thank you