-
-
Notifications
You must be signed in to change notification settings - Fork 7.6k
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
fix(dockerfile): bugfix for broken docker build + optimization #4154
Conversation
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.
git \ | ||
musl-dev && \ | ||
go get github.com/golang/dep/cmd/dep && \ | ||
go get github.com/kardianos/govendor && \ |
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 not relying on the current working directory?
Wouldn't it be something interesting to be able to generate an image from the current directory (for development or testing for example)?
go get github.com/kardianos/govendor && \ | ||
govendor get github.com/gohugoio/hugo && \ | ||
cd /go/src/github.com/gohugoio/hugo && \ | ||
dep ensure && \ |
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.
Although you consider it breaks docker best practices, you may consider that doing this requires re-building
and re-downloading everything for every single docker build
.
It is okay when the build step is built by a remote server that always discards cache, but might be interesting when iterating on docker build
locally. Docker has even edited its best practices explaining latest versions of docker have "have mitigated the need" of minimizing the number of layers.
As suggested in #4077 distinguishing installing dependent tools, dependencies and actual binary generation allows to benefit the docker build cache while building the image.
Having a dockerfile of (as set in #4077 ):
RUN apk add --no-cache \
git \
musl-dev \
&& go get github.com/golang/dep/cmd/dep
COPY Gopkg.lock Gopkg.toml /go/src/github.com/gohugoio/hugo/
WORKDIR /go/src/github.com/gohugoio/hugo
RUN dep ensure -vendor-only
COPY . /go/src/github.com/gohugoio/hugo/
RUN go install -ldflags '-s -w'
considers that:
dep
,git
,musl-dev
are external tools that change the less, without a strong dependency on the exact versiongo
dependencies are changing slower than the code itself, and quite long to install that are worth caching in local developments, and needs to be re-built every timeGopkg.*
changeshugo
code changes the most often and thus needs to be re-build every time a file is changed
Thanks for your consideration @ellerbrock I have proposed kind of the same paragraph on best practices :) |
yeah i saw that one, nice idea to rewrite the docker best practices :D |
If I had to choose, I think I would go for merging #4077 that has the advantage of benefiting build cache for who is using it locally while keeping the same final image |
This issue has been automatically marked as stale because it has not had recent activity. The resources of the Hugo team are limited, and so we are asking for your help. |
This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
Hello Hugo's,
i just found out that the Docker Build is broken, so i fixed that for you.
Further i cleaned up the Dockerfile and updated Alpine Linux to Version 3.7 and the Go Lang Build Image to Version 1.10-rc.
Another PR is coming soon with some further optimizations.
Cheers Maik