-
-
Notifications
You must be signed in to change notification settings - Fork 986
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
Adds a Dockerfile that creates a terragrunt image #1665
base: main
Are you sure you want to change the base?
Conversation
fwiw, demonstrating it builds...
and runs:
|
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.
Thanks for the PR!
I could configure a Docker Hub build as you mentioned here, but there are a few gotchas:
- How do we set the version number in the binary? See my comment in the PR itself.
- How do we test the
Dockerfile
before merging/releasing? I'd rather not merge something and later find out the Docker Hub build failed. - Docker Hub has introduced a bunch of limits recently, and seems to be heading in the direction of adding still more. Terragrunt might be popular enough to trip this limits... Not sure how many people use it via Docker though.
Dockerfile
Outdated
|
||
COPY . . | ||
|
||
RUN make 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.
This will end up with an empty version number in the binary. It needs to be set via:
-ldflags "-X main.VERSION=<VERSION>"
But it's not clear what version number we'd be able to use?
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 version is not empty! That's one reason I used the make build
target. The version is determined by the command git describe --tags --abbrev=12 --dirty --broken
. When the checkout matches a git tag, the value is just the git tag. When the checkout is not a tag, you get the last tag plus a git ref marker.
If you go with the dockerhub build service, dockerhub clones the repo and has all the tags, so this evaluates correctly. I'd expect any other container build service would also.
$ git describe --tags --abbrev=12 --dirty --broken
v0.29.2-2-gc90d385e21b8
$ git tag v0.29.3-testing
$ git describe --tags --abbrev=12 --dirty --broken
v0.29.3-testing
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 example:
$ docker run --rm gruntworkio/terragrunt --version
terragrunt version v0.29.2-3-gdbe93918437f-dirty
Dockerfile
Outdated
|
||
### | ||
|
||
FROM alpine:latest |
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.
NIT: couldn't this be scratch
? I think a standalone Go binary doesn't need anything else...
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.
Perhaps? Using alpine:latest
and the multistage build, it's only a 40MB image. Might be over-optimizing... I'll give it a shot though.
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 scratch base image worked, just needed to use CGO_ENABLED=0
. Image size is 34MB.
$ docker run --rm gruntworkio/terragrunt --version
terragrunt version v0.29.2-4-g4deae14c6db3-dirty
I addressed that inline. The version is being set!
What I usually do is build the image in CI and then run the container, exercising some suite of tests. How thorough I want to be with the image generally depends on how confident I am in the unit tests or integration tests I run more directly. Sometimes I just will run the container passing a basic flag, like
I haven't seen any DockerHub limits on building or pushing images for public projects. There are rate limits on users pulling images, and it is the user's responsibility to login to dockerhub to avoid the rate limit. There is also a plan to expire images that have not been used in 6 months, for accounts on the free tier. That seems pretty reasonable, though. If the image is being used, it remains available. If it's not used for 6 months, it seems likely it is not needed (and a user in desperate need could build it themselves at that point). |
@brikis98 I added a step to the circle-ci config to build the container as an example of how to validate the docker build in CI, but I have no ability to run it, of course. I also have never used circle-ci, so I may have guessed wrong about how to do this! 😬
|
Hey folks, |
Following on from @angeloskaltsikis's question, what is blocking progression on this PR? I am happy to pick up getting this merged into branch so that alpine/terragrunt at Dockerhub with over 10 million downloads can be deprecated. |
Related to #1655