Prebuild time

Hey there,

I just went into my workspace (a new one) and it skipped the prebuild part and went directly to the workspace vs code page.

So my setup grew like a lot in the last few days.

My setup is basically a rust project with 8 binaries and 2 libs.

My prebuild does:

  • build everything with docker-compose for hosting needed services as containers
  • build all binaries and libs to make sure all dependencies and all code is compiled and downloaded to minimize cargo run and cargo build times for devs
  • install some python libraries to use as commands
  • download mysql, mongo and rmq containers ready for development (and run them on command)

Is there a limit on how long a prebuild might take? If yes, may I change that? I have no problem if a prebuild takes 30+ Minutes as long as everything is setup correctly

1 Like

Hi @somehowchris! :wave:

That sounds like a fantastic Gitpod setup. :100: :crab:

Yes, currently prebuilds automatically time out if they run longer than 60 minutes.

There is unfortunately no user control over this time out duration today (but that could be a cool feature request).

On a side note, we’ve recently implemented an “incremental prebuild” feature, which can take older successful prebuilds of your project in order to build newer prebuilds on top (by re-fetching the latest commits and re-running all init tasks incrementally). This targets larger projects with frequent commits, but is still a bit experimental, so we’ve only enabled it for a few repositories. As part of that feature, we also wanted to extend the “base prebuild” timeout to 4 hours, but haven’t implemented this change yet.

EDIT: Oh and, another side note, we’ve also implemented a Prebuilds dashboard, where you can see all running / finished / failed prebuilds and their logs. This should become generally available in the coming weeks as part of the new “Teams & Projects” UI. This is also a little experimental, but if you’d like to try the current state, you can simply head to /new to enable the Teams & Projects UI for your user and create a new Project by adding your repository (after that, all Prebuilds will become visible under that Project). Please let us know if you have any questions or feedback on this as well. :slight_smile:

3 Likes

Thanks for the lovely response.

Sadly having to wait for docker-compose and cargo to do the initial install hit my productivity like real hard (takes sometimes 80+ minutes) and i had to go back go a usual desktop setup.

Hope that incremental builds get rolled out more and the base prebuild timeout duration change too.

I have tried to rerun the prebuild in the new ui, sadly it just didnt start at all and on a small project there were like no logs at all.

I read somewhere that there might be a config for allocated ressources sometime in the future, or was that just a myth? if yes can we configure different targets for prebuilds and actual work environments?

Hey again @somehowchris :wave:

Many thanks for the open feedback! I agree that prebuilds make even more sense for things that take > 60 minutes, so the 60 minutes timeout is really unfortunate here.

We’ll work on fixing that and get back to you when Gitpod has a better story for 80+ minutes init times.

Hey, thanks for giving it a try! These sound like bugs. :bug:

  • For the prebuild that didn’t rerun, could you please briefly explain what you tried? (E.g. add project, then click on Trigger Prebuild? Or something else?)

  • For the prebuild with no logs, we’re still working on a few different bugs that cause the logs view to remain empty. Hopefully we’ll have fixed them all soon!

Well, Configurable Resources is still listed for Q4 in the Gitpod 2021 roadmap. I believe the current idea is to create “premium workspaces”, which are e.g. 2x as powerful as regular workspaces (and use 2x the Gitpod hours), and that likely also makes sense for prebuilds. More news on this soon!