gitpod-io / gitpod-io/gitpod

Ensure COPY . . is working correctly in custom workspace images

Open
#7,945 3 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

feature: workspace image build meta: never-stale
Dominant language
TypeScript
Stars
13.8k
Forks
1.4k
Avg merge
17h 58m
Merged PRs (30d)
5

Description

Bug description

Some users get a file name too long error when building images if they have specified COPY . .

Steps to reproduce
  • The content of the customer repository is initialized under /workspace e.g.
COPYING.txt         VERSION.txt         condarc.yml         pkgs                tox.ini
Makefile            bootstrap           configure.ac        pyrightconfig.json
Pipfile.m4          build               docker              sage
README.md           buildkit            m4                  src
  • The root directory for buildkit (which is used by buildkit to store the layers of the container image that is build) is located at /workspace/buildkit
  • The context for the image build is /workspace
buildctl build --progress=plain --output=type=image,name=localhost:8080/base:latest,push=true,oci-mediatypes=true --local=context=/workspace --frontend=dockerfile.v0 --local=dockerfile=/workspace/docker --opt=filename=.gitpod.Dockerfile
  • The dockerfile for the image build specifies COPY . . somewhere
  • The context of the docker build contains the buildkit directory itself -> The buildkit directory is used to store the context -> COPY . . copies everything including the buildkit directory. This leads to a recursive copy of the build context which gets bigger and bigger with each pass until it hits the storage quota and the build fails.
Workspace affected

n.a.

Expected behavior

Image build should be executed successfully.

Example repository

https://github.com/Furisto/sagetrac-mirror

Anything else?

There are several ways to solve this issue:

  • Put the buildkit directory somewhere else e.g. under /tmp. We have to check how well this works with ephemeral storage limits.
  • Use a .dockerignore file to exclude the buildkit directory. The customer might already have a .dockerignore, but it is possible to specify our own during build. We would need to create a new .dockerignore which contains the content of the customer .dockerignore + our own exclusions.
  • Adapt the builder-mk3 to adapt the Initializer, Context and Dockerfile arguments.
Related issues

https://github.com/gitpod-io/gitpod/issues/7602
https://github.com/gitpod-io/gitpod/issues/7157

Front logo Front conversations

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by tracing the builder-mk3 flow and its Initializer, Context, and Dockerfile arguments, then reproduce the buildctl invocation with COPY . . and a context containing the buildkit directory. Compare the proposed context-location and .dockerignore approaches. Done means the image build completes without recursively copying its own build context.

Written by the indexing model from the issue text.

Assessment

Tech stack
docker, typescript
Domain
build-system, devops
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.