-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Cache downloaded Go dependencies and Atlantis compilation in Docker #2738
Conversation
This has the potential to speed up rebuilds of the Atlantis container significantly, especially for non-x86 platforms which are emulated when done in GitHub Actions. It works by using cache mounts: https://docs.docker.com/engine/reference/builder/#run---mounttypecache. They mean we can have specific paths set that are carried over from one image build to the next, regardless of which files are changed in the project. The files are however at the same time not part of the final image, which reduces the generated "builder" image from 1.66 GB to just 386 MB on the current main branch. In my local tests, which doesn't make use of emulation, I saw a drop for the "go build" step going from taking just over 40 seconds with an empty cache to around 1 second when I make a one character change to a Go source file. That is otherwise a change that prior to this would cause a complete rebuild of the Docker image layer.
I just tried the same quick comparison locally when doing cross-compiling. I'm on an arm64 machine, so I added With a reused download cache, but where it had to do all the cross-compiling, the |
@@ -3,7 +3,9 @@ FROM golang:1.19.3-alpine AS builder | |||
|
|||
WORKDIR /app | |||
COPY . /app | |||
RUN CGO_ENABLED=0 go build -trimpath -ldflags "-s -w" -v -o atlantis . | |||
RUN --mount=type=cache,target=/go/pkg/mod \ | |||
--mount=type=cache,target=/root/.cache/go-build \ |
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.
Have you been able to test this in your fork to confirm if this works as intended?
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.
I have tested it locally and use the same pattern in a bunch of other repositories which also build using GitHub Actions.
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.
For this to have any effect in CI here, though, I believe it needs the caching options from my other PR, otherwise the cache won't be shared between the runs.
…unatlantis#2738) This has the potential to speed up rebuilds of the Atlantis container significantly, especially for non-x86 platforms which are emulated when done in GitHub Actions. It works by using cache mounts: https://docs.docker.com/engine/reference/builder/#run---mounttypecache. They mean we can have specific paths set that are carried over from one image build to the next, regardless of which files are changed in the project. The files are however at the same time not part of the final image, which reduces the generated "builder" image from 1.66 GB to just 386 MB on the current main branch. In my local tests, which doesn't make use of emulation, I saw a drop for the "go build" step going from taking just over 40 seconds with an empty cache to around 1 second when I make a one character change to a Go source file. That is otherwise a change that prior to this would cause a complete rebuild of the Docker image layer. Co-authored-by: nitrocode <[email protected]>
what
This has the potential to speed up rebuilds of the Atlantis container significantly, especially for non-x86 platforms which are emulated when done in GitHub Actions.
It works by using cache mounts:
https://docs.docker.com/engine/reference/builder/#run---mounttypecache. They mean we can have specific paths set that are carried over from one image build to the next, regardless of which files are changed in the project. The files are however at the same time not part of the final image, which reduces the generated "builder" image from 1.66 GB to just 386 MB on the current main branch.
why
In my local tests, which doesn't make use of emulation, I saw a drop for the "go build" step going from taking just over 40 seconds with an empty cache to around 1 second when I make a one character change to a Go source file. That is otherwise a change that prior to this would cause a complete rebuild of the Docker image layer.
references