Skip to content

Gitpod Image Build Logs #16485

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
ShaunSHamilton opened this issue Feb 20, 2023 · 6 comments
Closed

Gitpod Image Build Logs #16485

ShaunSHamilton opened this issue Feb 20, 2023 · 6 comments
Labels
aspect: gitpod loading process Related to the loading order of Gitpod processes, such as env variables, IDE, dotfiles etc feature: docker in workspaces feature: gp validate feature: prebuilds meta: stale This issue/PR is stale and will be closed soon

Comments

@ShaunSHamilton
Copy link

Is your feature request related to a problem? Please describe

After opening a Gitpod workspace, it would be useful to be able to view the Docker/build logs for the container.

Describe the behaviour you'd like

Currently, Gitpod comes with a Gitpod: Export all logs command. However, this only exports the logs from the various VSCode outputs (I do not know anything about the other editor options).

I would like the container logs to be added to the folder of logs generated. Similar to what you can do when building an image/container locally on VSCode.

Describe alternatives you've considered

On the Discord, someone mentioned the gp rebuild command as a workaround to see the logs as the image builds. However, this is just a workaround.

@loujaybee
Copy link
Member

loujaybee commented Feb 21, 2023

Hey @ShaunSHamilton, thanks for raising 🙏 Could you explain a little more about what it is that you're looking for with the logs? Could you explain a little about what the issue is that you're trying to resolve that you need the logs for?

On the Discord, someone mentioned the gp rebuild command as a workaround to see the logs as the image builds. However, this is just a workaround.

gp rebuild is in beta and we're actively improving it day-by-day right now (docs), I am also giving a demo on it tomorrow in the community, so I wouldn't really call it a "workaround". The command emulates almost entirely a workspace build (we are working towards as close to 100% parity as reasonable), so I see no good reason not to trust the logs from that command. Is there something insufficient about the output from that command currently for your use case?

CC: @axonasif incase you have more context.

@ShaunSHamilton
Copy link
Author

Could you explain a little more about what it is that you're looking for with the logs? Could you explain a little about what the issue is that you're trying to resolve that you need the logs for?

Honestly, I have forgotten why I needed (wanted) the logs. It was most likely to do with debugging the init during build.

Is there something insufficient about the output from that command currently for your use case?

No. The reason I said "workaround" is that I have to rebuild to get the logs. I just thought that odd, because I assume there are already build logs somewhere out there from when the container was first created?


Are the logs that are shown sometimes during the pre-build phase stored anywhere on the file system?

@loujaybee
Copy link
Member

Honestly, I have forgotten why I needed (wanted) the logs. It was most likely to do with debugging the init during build.

Gotcha. gp rebuild has some flags such as --prebuild and --as="prebuild" which allow you to emulate different prebuild scenarios, which should make init task debugging simpler.

No. The reason I said "workaround" is that I have to rebuild to get the logs. I just thought that odd, because I assume there are already build logs somewhere out there from when the container was first created?

We don't put those build logs into the built workspace to my understanding. I can see the appeal, but also do think that gp rebuild may well become the default way that we encourage Gitpod users to configure, validate and test their configurations. However, if there are situations that doesn't make sense, exposing the build logs could also be useful. I'm going to refer this one to @gitpod-io/engineering-workspace as I think they'll be best placed on the feasibility on accessing and putting those logs in the workspace.

Thanks for the additional info, @ShaunSHamilton !

@axonasif
Copy link
Member

axonasif commented Feb 21, 2023

For context, primary discussion on Discord:

@stale
Copy link

stale bot commented Jun 10, 2023

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.

@stale stale bot added the meta: stale This issue/PR is stale and will be closed soon label Jun 10, 2023
@stale stale bot removed the meta: stale This issue/PR is stale and will be closed soon label Sep 5, 2023
Copy link
Contributor

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.

@github-actions github-actions bot added the meta: stale This issue/PR is stale and will be closed soon label May 22, 2024
@github-actions github-actions bot closed this as not planned Won't fix, can't repro, duplicate, stale Jun 2, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
aspect: gitpod loading process Related to the loading order of Gitpod processes, such as env variables, IDE, dotfiles etc feature: docker in workspaces feature: gp validate feature: prebuilds meta: stale This issue/PR is stale and will be closed soon
Projects
No open projects
Status: No status
Development

No branches or pull requests

3 participants