Prebuild not triggered


I am having trouble getting prebuilds to work.
They are not triggered for new commits to the master branch.

My repo: GitHub - LukasBreitwieser/gitpod-vnc

Gitpod shows the last commit on the branches page (Update BioDynaMo commit id · LukasBreitwieser/gitpod-vnc@4a6886d · GitHub), but did not start a prebuild for it:

Thus, the next time I created a new workspace, the Docker image had to be built.

Many thanks in advance for your help!


Hi Lukas,

For prebuilds to trigger automatically on every commit, you need an “init” task in your .gitpod.yml
Did you trigger those prebuilds in your screenshot manually from the Configuration page?

I see you are using a gitpod.Dockerfile - I would expect any commits to the Dockerfile to be picked up in the image used by subsequent new workspaces.

If you open a workspace right after changing the Dockerfile I can imagine you may see what looks like a docker build inside the workspace, but I haven’t tried that myself to be honest, so I’m not 100% sure what that looks like.

Anyway, let us know if you still think something is broken or have other questions.

Thanks for your help Jürgen!
The init command did the trick.

Unfortunately, I ran into another issue.
The prebuild fails with the following message:

Connecting to workspace logs...

Error: build failed: cannot build base image: context deadline exceeded

Don’t know if this info helps, but if I start a new workspace building the Docker image takes around 18min. I also built the image locally and measured a size of 4.5GB.

I found this post with the same error, but @cro reported that for him it disappeared on its own.


Hi Lukas,

I’ll check to see if that is a known issue or file a new report and let you know.

In the meantime, one workaround I could suggest may be to do the docker build separately (maybe in a GitHub action) and push the image to a public docker registry, and then reference the exact image (with sha if necessary) from the .gitpod.yml. This would give you total control over the image build and the exact image used in the workspace – but I realize that comes at the expense of a little more manual work.


Hi Jürgen,

Thanks for taking a look!

I already tried the workaround you described before turning to prebuilds.
The problem is that the first time someone opens a workspace after the docker image has been updated it takes 9 minutes before it is ready.

From the logs I see that Gitpod is creating another image performing the following steps:

  • Download image from docker hub
  • Add gitpod layer
  • push new image to (internal?) registry

Is there a way to skip these steps?
Isn’t the gitpod layer included in gitpod/workspace-full-vnc?


Yes, i can see that pulling a large image would be slower the first time.

The 3 steps you’re describing sound like a prebuild, with a new image push in the last step. That would be expected from the init task in gitpod-vnc/.gitpod.yml at docker-hub · LukasBreitwieser/gitpod-vnc · GitHub

I have done a little more research about when Gitpod triggers a docker build, using the gitpod.Dockerfile inside your repo (like you have on master branch).

That docker build is only triggered when you modify the Dockerfile, not on every commit like the prebuild init task. So, you have to be careful to bump the Dockerfile if you’re copying other files from your repo into the image during the docker build.

Normally you would use an init task in a prebuild to do the heavier tasks which depend on (regularly changing) files in your repo so that users don’t wait for those in the startup commands.

If you can get these 2 things working (docker build for global installs etc, and prebuilds for file-dependent initialization) that should give your users the best chance of fast workspace starts.

Good luck, and let us know if you have more questions.

1 Like

Hi Jürgen,

Maybe best to focus on the prebuild issue then.
The prebuilds still fail with the same error.
For example for this commit

Error: build failed: cannot build base image: context deadline exceeded

Do you have any news about that?


Hi Lukas,

I managed to reproduce the error you reported the 2nd time that I triggerd the docker build on a fork of your repository (the first time I tried it, it worked.) I suspect that it may due to a timeout, since that docker build can take a while.

I am investigating further, and will keep you updated and let know when I learn more.

1 Like