Controlling prebuilds

Hi,

prebuilds are a pretty awesome feature, but at the moment they are very tough to handle.

  • The log is not shown reliable which makes it nearly impossible to debug what is going on within a prebuild.
  • Is it possible to abort running prebuilds?
  • What is happing when a user does two pushs in a row, is the first prebuild stopped?
  • Is somewhere an overview available of active prebuilds for my repository?
  • Is it possible to configure prebuilds that they are just started on a manual function call?
  • 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?
  • How long is a prebuild executed when it gets stuck?

Is there a roadmap with a timeline existent when prebuild handling will be improved?

Best regards,
Sebastian

And one more that just came into my mind :slight_smile:

  • Is somewhere a log available when a prebuild failed?

Hey Sebastian,

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.

1 Like

Hey @svenefftinge:
Thank you very much for the great insight!
I am looking forward to the upcoming changes :slight_smile:

Best regards,
Sebastian

Hi @svenefftinge

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``

Is it possible for us to trigger a prebuild from another CI server? The gitpod.io#prebuild URLs require a login, so we would need a way to do it with a token instead.

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.

This is working for us BTW. All our Gitpod users have a secret env var in Settings which is used to authenticate with a private Docker registry during an init task. The prebuilds seem to work fine, but maybe this is not secure?

This is currently not supported. Could you create an issue on github for this and also outline your use case?

Atm we inject the env vars of the user that has setup the prebuilds. We are moving this to a team level and will allow having env vars on a per-project level as well later this year.

Hi @svenefftinge,
are there any news on this yet?