Skip to content

Dockerfile always rebuilding with "Incremental Prebuilds" enabled #11455

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

Open
aucampia opened this issue Jul 18, 2022 · 3 comments
Open

Dockerfile always rebuilding with "Incremental Prebuilds" enabled #11455

aucampia opened this issue Jul 18, 2022 · 3 comments
Labels
meta: never-stale This issue can never become stale ❓ clarification required type: bug Something isn't working

Comments

@aucampia
Copy link

aucampia commented Jul 18, 2022

Bug description

I have Incremental Prebuilds enabled for my project (https://gitpod.io/projects/rdflib/settings), however every time I commit to a PR branch the docker build starts from scratch as far as I can tell.

Steps to reproduce

  1. Create a branch from https://github.com/aucampia/rdflib/tree/iwana-20220718T2235-gitpod-issue
  2. Create a (draft) PR from the branch
  3. Wait for it to do a prebuild
  4. Create an arbitrary update to README.md on the branch
  5. Wait for it to do a prebuild

Workspace affected

https://gitpod.io/#https://github.com/aucampia/rdflib/tree/iwana-20220718T2235-gitpod-issue

Expected behavior

Each update to README.md after the first prebuild does not do a full docker build

Example repository

https://github.com/aucampia/rdflib/tree/iwana-20220718T2235-gitpod-issue

Anything else?

No response

Front logo Front conversations

@aucampia aucampia added the type: bug Something isn't working label Jul 18, 2022
@david-bakin
Copy link

david-bakin commented Jul 18, 2022

I noticed this in the past - but failed to report it, sorry. IIRC in my case the container wasn't build each time but most times, and also I don't think I had incremental prebuilds enabled. I couldn't figure out any pattern. But in any event it was rebuilt even though I had not pushed an updated .gitpod.Dockerfile.

This is a large time sink as docker container builds especially off of Gitpod.io's "workspace-full" container, are quite slow. And that defeats the main selling points of Gitpod.io - "Select project, start coding."

I think the custom container should only be updated on two occasions when doing a prebuild (or loading a workspace that hasn't been prebuilt):

  1. The custom dockerfile (specified of course by the image: attribute in .gitpod.yml) has been pushed.
  2. A custom dockerfile is specified, and the base container it specifies (via the FROM statement) has changed. (i.e., its image checksum has changed)
    • Yes, that does mean you have to look inside the customer dockerfile to find the base image's ref.

(As to discovering whether the image now at the tag is the same or different that the image that was last used in a customer dockerfile build: that's left as "an exercise for the reader" as my brief reading of various issues at Docker show that identifying a particular image is a hairball ... - but I'm no docker registry expert ...)

@nandubatchu
Copy link

Hey @csweichel - is this bug-fix being worked upon?

@stale
Copy link

stale bot commented Feb 5, 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 Feb 5, 2023
@axonasif axonasif added meta: never-stale This issue can never become stale and removed meta: stale This issue/PR is stale and will be closed soon labels Feb 7, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
meta: never-stale This issue can never become stale ❓ clarification required type: bug Something isn't working
Projects
Status: No status
Development

No branches or pull requests

4 participants