Fix Docker/Dockerhub situation

[kav]

I'm aware that in #4155 @ellerbrock created dockerhub and quay accounts and @bep mentioned a different dockerhub account and @skoblenick proposed that one day hugo should be an Official image and #4518 incorporated all @ellerbrock's changes into the dockerfile.

However...

Neither Quay nor Dockerhub currently have a remotely up to date version of hugo at present in any of the above mention locations.

What would it take to get automatic publishing on dockerhub tied to this repo at either of the gohugo or gohugoio dockerhub accounts?

[bep]

Some months ago I would probably have answered "why do you need a Docker version?", but with the recent libsass extensions, I can see the need.

I have one Docker image living in my account that belongs to Gohugo, and we should also get a binary version in here. I remember vaguely the person behind the gohugoio said he was willing to transfer ownership.

[kav]

Well it’s less so needing or not needing to run Hugo on Docker. It’s pretty straightforward to clone the repo and use the existing file to do that.

It’s more a case that one might expect to find Hugo on Dockerhub or Quay and naively use one of the existing out of date images.

I’m not sure what you mean by a binary version in here. Can you explain a bit more?

[ghost]

Would be very handy to see a BusyBox tag, Alpine for dev and then copy the binary into scratch for custom build pipelines with CI/CD as suggested in #4693 by adding another layer to multistage build. BusyBox will enable theme maintainers an easy way to move themes into containers to run alongside the final binary without having to pull the top layers.

[bep]

I’m not sure what you mean by a binary version in here. Can you explain a bit more?

The current Dockerfile builds the current development version from source, which is different from a Dockerfile with a given Hugo binary version.

I have not followed the history of the current Dockerfile -- I don't need it. For me, Docker in this context is all about CI and reproducibility -- i.e. the Hugo 0.46 Docker image will continue to build my 0.46 site for decades.

[nizsheanez]

FYI: i using klakegg/hugo:0.46-ext-alpine
this repo is very good: automatically releasing new versions, has extended hugo, it's small.
but this repo a bit doesn't follow standard hugo folders structure, for example it has /src and /target volumes.

In my CI it looks this way:

docker run --rm -v $(pwd)/:/src -v $(pwd)/public:/target -e "HUGO_ENV=production" klakegg/hugo:0.46-ext-alpine --baseURL="https://mywebsite.com/"

[maiki]

Pinging @felicianotech, as they build felicianotech/docker-hugo => https://hub.docker.com/r/cibuilds/hugo/, and update it in the release notes (0.46, for example).

[dkarlovi]

FYI: i using klakegg/hugo:0.46-ext-alpine

It might be my inexperience about Hugo, but I've updated this one to use 0.48 and it seems 0.48 extended doesn't work as it should? The file says it's dynamically linked?

FROM busybox:1.28 AS fetch-standard
ARG VERSION=0.48
ADD https://github.com/gohugoio/hugo/releases/download/v${VERSION}/hugo_${VERSION}_Linux-64bit.tar.gz /hugo.tar.gz
RUN tar -zxvf hugo.tar.gz
RUN ["/hugo", "version"]

FROM busybox:1.28 AS fetch-extended
ARG VERSION=0.48
ADD https://github.com/gohugoio/hugo/releases/download/v${VERSION}/hugo_extended_${VERSION}_Linux-64bit.tar.gz /hugo.tar.gz
RUN tar -zxvf hugo.tar.gz

FROM alpine:latest
RUN apk add --no-cache file
COPY --from=fetch-standard /hugo /bin/hugo
COPY --from=fetch-extended /hugo /bin/hugo-extended
# ENTRYPOINT ["/bin/hugo-extended"]
CMD ["--help"]

/site $ file /bin/hugo-extended 
/bin/hugo-extended: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=469449216871b6bc6d846f86cf47a4af7922a5c8, stripped

[dkarlovi]

If anybody is looking for Hugo extended in Alpine base image, I've created an automated build:
https://hub.docker.com/r/dkarlovi/docker-hugo/

Repo here https://github.com/dkarlovi/docker-hugo

If you're interested, I could PR to this repo with the Dockerfiles and a complete automated setup on Dockerhub (if anybody has access to the account, I'll describe what needs to be setup for it to work).

[felicianotech]

Since I was tagged in here, just wanted to say,

1. I do maintain a Docker image, cibuilds/hugo. This image is designed to be run well in a CI environment first and foremost. Though you can use it locally.

2. One of the things I'll be adding to the image for 2019 is a better website testing suite built in Go as well as a nightly (or similar) tag so that people can use non-release versions of Hugo.

[jmooring]

Moving conversation to #10760

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.