-
Notifications
You must be signed in to change notification settings - Fork 886
feat: add git to Docker image #6034
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
I'm unable to test the docker-base.yaml workflow I added since github does not seem to like running workflow files that don't exist in the main branch, but I've linted it and it looks good by eye so I think we should merge it and I can fix any bugs that happen in main. |
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.
Awesome!
@@ -0,0 +1,27 @@ | |||
# This is the base image used for Coder images. It's a multi-arch image that is |
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.
Why do we need a base? Can we do all builds in depot? then we don't need the forking logic.
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.
Because then every developer needs to have depot access and install depot CLI and authenticate it just to build docker images. The forking logic makes it easier overall as most people won't have to worry about dealing with the build process anyways.
I also don't think it adds that much overhead and it's clearly documented at the top of each Dockerfile what they're for.
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.
Makes sense!
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'd prefer if Dockerfile.base
wasn't in the root. It seems like a bespoke asset exclusively used for a CI job, so we might want to hide it.
Thoughts on tossing it in scripts
or even in .github/workflows
?
This PR creates a new base image which is compiled for all 3 architectures we ship for (
amd64
,arm64
andarmv7
) and compiles it on depot.dev cloud on real hardware. This enables us to use RUN commands inDockerfile.base
to install tools etc., and just use the regularDockerfile
for copying in the binary and setting labels.The base image is built via a new GitHub workflow every Monday, Wednesday and Friday, and is built during the release process for each release on it's own tag. It's available at
ghcr.io/coder/coder-base:latest
.I chose to use depot.dev to avoid using qemu or getting/managing/maintaing custom build boxes to do the Docker building. depot.dev have offered us an open-source coupon which eliminates the $25/mo fee and gives us plenty of build minutes, which I will ask them for once merged.
Local image builds using the supported make commands will just use our periodically built latest tag as the base image. This does not change the regular image building process to use depot.dev, local builds still happen only locally and do not require authentication.
Closes #3724