-
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
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.modandgo.sumcopy operation before setting the working directory - Adds explicit
go mod downloadstep 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 |
Copilot
AI
Sep 6, 2025
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 |
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. |
* fix(build): include CA certificates in Docker image (#483) Ensure the image contains trusted CA certificates so the app can establish secure HTTPS connections to AWS services. Without them, TLS handshakes fail with **x509: certificate signed by unknown authority**: `failed to check if infra exists: operation error SQS: GetQueueUrl, exceeded maximum number of attempts, 3, https response error StatusCode: 0, RequestID: , request send failed, Post "https://sqs.eu-west-1.amazonaws.com/": tls: failed to verify certificate: x509: certificate signed by unknown authority` * chore(build): Copy go mod files first to leverage Docker layer cachin… (#482) * chore(build): Copy go mod files first to leverage Docker layer caching for dependencies * chore(build): reorder WORKDIR command * chore: rename to dockerfile.example * chore: update dockerfile.example to include entrypoint.sh * chore: comment --------- Co-authored-by: Olivier Bazoud <olivier.bazoud@gmail.com>
…g for dependencies