fix(dockerfile): bugfix for broken docker build + optimization

[ellerbrock]

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

[tjamet]

Nice using scratch image!

I am personally thinking that building the local repository rather than cloning it from github is interesting, as well as keeping the local re-build optimisation.

Moreover, I am wondering how duplicate this is with #4077 or even #4155, shall we focus on one?

[tjamet]

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)?

[tjamet]

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 version
• go 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 time Gopkg.* changes
• hugo code changes the most often and thus needs to be re-build every time a file is changed

[ellerbrock]

@tjamet,

thanks for the explanation from the developer view working on localhost.
makes totally sense and i made a new pr with the requested changes #4157

that's why working with other smart people on open source makes so much fun.

cheers maik

[tjamet]

Thanks for your consideration @ellerbrock I have proposed kind of the same paragraph on best practices :)

[ellerbrock]

yeah i saw that one, nice idea to rewrite the docker best practices :D

[ellerbrock]

@tjamet any thoughts in merging it?
and like mentioned here: #4155 i already created a hugoio account for you guys with automated builds. i can give it over to you guys ...

cheers maik

[tjamet]

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
But I am a contributor, I can't decide what to merge or not

[stale]

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.
If this is a bug and you can still reproduce this error on the master branch, please reply with all of the information you have about it in order to keep the issue open.
If this is a feature request, and you feel that it is still relevant and valuable, please tell us why.
This issue will automatically be closed in the near future if no further activity occurs. Thank you for all your contributions.

[github-actions]

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.