gitpod
gitpod copied to clipboard
Show prebuild logs for all tasks
The prebuild logs viewer in workspace startup, and in project prebuilds, only shows the logs for the first tasks. This makes it difficult to debug prebuilds in workspaces with multiple tasks, e.g. multi-repo workspaces.
Since tasks can run in parallel, there need to be multiple log display areas in the page. I quite like the way the werft UI does this.

cc: @gtsiolis
This would be extremely helpful since if a prebuild step fails that isn't the first task in the list, you have to debug by re-ordering the task list so that the failing task is the first task. Also if the first task is faster than other tasks, it seems like the prebuild has hung, when actually it's just working on something else that the user can't see
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.
Another user request for this [1] (internal)
Just to help anyone in the same place here. It's actually do-able already via API calls their web makes.
If you watch the calls when you open the Prebuild log page you'll see a call to https://gitpod.io/headless-log-download/0971....-....-....-....-........baa3/0.
If you swap out the 0 at the end of all that for n+1 you get the other logs.
I had to blank the GUID because the links are also not secured.
I'll try put together a PR if I find some time over the next month.
Is there any chance that we'll see a solution here? It's very tricky to debug a failed prebuild. The solution from @moritonal only works for succeeded prebuilds in my case. Failed prebuilds unfortunately don't show any output.
You can reproduce a prebuild locally from the workspace with gp validate --prebuild --headless. See more info about gp validate: https://www.gitpod.io/docs/configure/workspaces#validate-your-gitpod-configuration
Thanks for the fast answer. I knew the gp validate command, but due to some mysql errors that I mentioned here I couldn't test my setup this way.
However, the --headless option was new for me and did the trick for me. Thanks for that! Unfortunately, this is not documented in the CLI itself and I couldn't find anything about that option in your documentation - maybe this could be added. Would have saved me a lot of time and some headaches before 😄
EDIT: Ok, the mysql problem seems to occur there as well, but I was able to easily see my current problem in the logs :)
It is strange --headless simply prevent IDEs to start. But maybe again shell scripts races are causing some weirdness.