-
Notifications
You must be signed in to change notification settings - Fork 18
chore(build): Copy go mod files first to leverage Docker layer cachin… #482
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
base: main
Are you sure you want to change the base?
Conversation
…g for dependencies
@obazoud is attempting to deploy a commit to the Hookdeck Team on Vercel. A member of the Team first needs to authorize it. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull Request Overview
This PR optimizes the Docker build process by leveraging Docker layer caching for Go dependencies. The change reorders Dockerfile commands to copy Go module files first and download dependencies before copying the entire source code.
- Moves
go.mod
andgo.sum
copy operation before setting the working directory - Adds explicit
go mod download
step to cache dependencies in a separate layer
Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.
build/Dockerfile
Outdated
COPY go.mod go.sum ./ | ||
RUN go mod download | ||
WORKDIR /app |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The WORKDIR command should be set before copying files. Currently, go.mod and go.sum are copied to the root directory (/) instead of the intended /app directory, which will cause the go mod download command to fail.
COPY go.mod go.sum ./ | |
RUN go mod download | |
WORKDIR /app | |
WORKDIR /app | |
COPY go.mod go.sum ./ | |
RUN go mod download |
Copilot uses AI. Check for mistakes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Similar question to the message in another thread, would love to understand your use case here. Since I personally don't use this Dockerfile, I just want to understand the motivation.
Potentially, I think it may make sense to simply remove this Dockerfil instead if you can continue your workflow without. With that in mind, happy to proceed and support this if it helps.
I just think this Dockerfile is nowhere close to production-ready, and I want to avoid spending time maintaining an unused Dockerfile if we can avoid it.
I’ve explained in the other thread how I use this Dockerfile in my local workflow to test my changes. |
…g for dependencies