thanks for the feedback. The current implementation of prebuilds really is an MVP. We are now working on the next much more fleshed out implementation that will surface what is going on much more.
You’ll be able to see logs reliable for running and past prebuilds similar to how you see builds in a CI system.
Some answers to your questions:
- The log is not shown reliable which makes it nearly impossible to debug what is going on within a rebuild.
We are reworking the log streaming infrastructure. It will be fixed by the end of June.
- Is it possible to abort running prebuilds?
Not yet, but we are working on it. (ETA July)
- What is happing when a user does two pushs in a row, is the first prebuild stopped?
Currently, the previous one is running without a way to cancel or even view it. In future we will cancel them. (ETA July)
- Is somewhere an overview available of active prebuilds for my repository?
Not yet. (ETA July)
- Is it possible to configure prebuilds that they are just started on a manual function call?
Prebuilds are currently started through webhooks (GitHub App, GitLab webhooks) or can be triggered manually using the rebuild context URL, that is e.g. `https://gitpod.io/#prebuild/https://github.com/gitpod-io/spring-petclinic``
- Within our developer user profiles, we are storing secrets within the variables which allows them to access our container registry, how can we provide those secrets to the prebuilds?
This is currently not possible and is also not part of the current work. But it’s in our backlog and probably something we will work on later this year.
- How long is a prebuild executed when it gets stuck?
Currently, the timeout is 60 mins. We’ll likely allow adjustments here soon.
Is somewhere a log available when a prebuild failed?
Logs are currently only stored within the rebuild snapshot itself. So you can start a workspace based ona. failed prebuild and will find the logs in (
/workspace/.gitpod). they are also echoed into the terminal on starts.