Provide a nicer image build failed message

[filiptronicek]

Description

Make the message you see when an image build fails nicer for humans, including the recommendation for gp validate.

Related Issue(s)

Fixes ENT-724

How to test

1. Open https://ft-nicer-ie500177c4c.preview.gitpod-dev.com/new#https://github.com/kylos101/gitpod-custom-image/tree/kylos101/build-fail

[kylos101]

Hey @filiptronicek , to test you could try using an image build that will fail, like this one: https://github.com/kylos101/gitpod-custom-image/tree/kylos101/build-fail

It fails like so in catfood:

[filiptronicek]

@kylos101 thanks for sharing, I have been able to get this screen as well. What I was originally curious about is this image build screen without any logs, where the improved error message would be a very nice addition:

For the purposes of testing this PR, your suggestion will be enough, though. Thanks!

[kylos101]

Oh, I see - have you tried deleting the image build pod, before logs start to stream? We might be able to enable debug with image-builder-mk3 too. I think that introduces a delay in the image build process, which might give us time to delete the imagebuild pod itself.

[filiptronicek]

Trying with Kyle's example I actually still get Error: headless task failed: exit status 1. I must be changing this in an incorrect place?

[mustard-mh]

@filiptronicek maybe you're looking for this one

gitpod/components/supervisor/pkg/supervisor/supervisor.go

Lines 1603 to 1604 in 359934c

	msg := []byte("headless task failed: " + string(success))
	err := ioutil.WriteFile("/dev/termination-log", msg, 0o644)

?

content inside /dev/termination-log will be consider as failed reason / status of a pod

update: but it's not always work well, like this one, it will show another message relates to pod sometimes if I remember it correctly

container workspace completed; containers of a workspace pod are not supposed to do that

[filiptronicek]

Thanks so much for sharing that, @mustard-mh, that's exactly what I was looking for (I originally thought we display the error we catch from the workspace starter).

update: but it's not always work well, like this one, it will show another message relates to pod sometimes if I remember it correctly

Oh, that's a bummer. Do we have an issue for that? Feels like we should to make our error messages reliable

[mustard-mh]

Oh, that's a bummer. Do we have an issue for that? Feels like we should to make our error messages reliable

@filiptronicek Searched, seems we don't have such issue

[mustard-mh]

@filiptronicek ws-manager will read content of /dev/termination-log here

gitpod/components/ws-manager-mk2/controllers/status.go

Line 140 in fea7d78

workspace.Status.SetCondition(workspacev1.NewWorkspaceConditionHeadlessTaskFailed(cs.State.Terminated.Message))

In case you need to investigate further

[filiptronicek]

@mustard-mh could you help me understand why we fail the image build as part of the supervisor's stopWhenTasksAreDone? I never thought of that phase as a task because it can't run in parallel with the other ones. Are we adding it somewhere artificially to the list?

If so, we could make this work by communicating through the success channel not just the success state, but also some task identifier. If that matched the image build, we could trigger a special message.

Edit: I think I found it:

gitpod/components/image-builder-mk3/pkg/orchestrator/orchestrator.go

Line 420 in d483e85

{Name: "GITPOD_TASKS", Value: `[{"name": "build", "init": "sudo -E /app/bob build"}]`},

[filiptronicek]

🎉

[lucasvaltl]

🎉

Regarding the actual error message we show. Is my assumption correct that in effectively every case this is an error caused by the user? I.e. something is wrong with the image being built, e.g. a mistake in the docker file? If this is the case, let's make this clear in the error message we show. E.g. (feel free to improve with AI) "The image failed to build. Most likely, this is due to a misconfiguration of the image that causes an error due to the build process. To debug this, it is advised to use gp validate (link to docs)."

[filiptronicek]

@lucasvaltl: Regarding the actual error message we show. Is my assumption correct that in effectively every case this is an error caused by the user?

Yes, when a headless task fails, we categorize it as a user error.

I'm going to try with another message, adapted from your suggestion. Trying to keep it short to fit in all places we show these messages (wish we had a link shortener for the long gp validate docs link 🙈)

[filiptronicek]

Argh, it doesn't really fit

Maybe we can do this without the docs link?

Edit: I ± made it work with allowing up to two lines before truncating:

[mustard-mh]

LGTM

Image Build

nit: see screenshot, the links we provide on 'Learn More' and logs are different.

[mustard-mh]

nit: Other config will read env when init, we should do it the same for isImageBuild to align with others

[filiptronicek]

Thanks for pointing this out, fixed in e1b1d79 (#20281).