Skip to content
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 Docker/Dockerhub situation #5056

Open
kav opened this issue Aug 10, 2018 · 13 comments

Comments

@kav
Copy link

commented Aug 10, 2018

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

This comment has been minimized.

Copy link
Member

commented Aug 10, 2018

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.

@bep bep changed the title Dockerhub/Quay hugo builds not current Fix Docker/Dockerhubo situation Aug 10, 2018

@bep bep added the Enhancement label Aug 10, 2018

@bep bep changed the title Fix Docker/Dockerhubo situation Fix Docker/Dockerhub situation Aug 10, 2018

@bep bep added this to the v0.47 milestone Aug 10, 2018

@kav

This comment has been minimized.

Copy link
Author

commented Aug 11, 2018

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

This comment has been minimized.

Copy link

commented Aug 13, 2018

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

This comment has been minimized.

Copy link
Member

commented Aug 13, 2018

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

This comment has been minimized.

Copy link

commented Aug 14, 2018

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/"

@bep bep modified the milestones: v0.47, v0.48 Aug 14, 2018

@maiki

This comment has been minimized.

Copy link

commented Aug 15, 2018

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

@bep bep modified the milestones: v0.48, v0.49 Aug 22, 2018

@dkarlovi

This comment has been minimized.

Copy link

commented Sep 2, 2018

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

This comment has been minimized.

Copy link

commented Sep 4, 2018

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

@bep bep modified the milestones: v0.49, v0.50 Sep 13, 2018

@bep bep modified the milestones: v0.50, v0.51 Oct 6, 2018

@bep bep modified the milestones: v0.51, v0.53 Nov 8, 2018

ships added a commit to ships/concourse-generics that referenced this issue Nov 13, 2018

@bep bep modified the milestones: v0.53, v0.54 Dec 6, 2018

@bep bep modified the milestones: v0.54, v0.55 Dec 26, 2018

@felicianotech

This comment has been minimized.

Copy link
Contributor

commented Dec 26, 2018

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.

@bep bep modified the milestones: v0.55, v0.56 Feb 1, 2019

brianredbeard added a commit to brianredbeard/hugo that referenced this issue May 18, 2019

dockerfile: Switch base image for final build
Switching the base image for the final build to alpine as it still
provides a minimal interface, but has a mechanism for easily including
relevant CA certificates.  This is currently pinned to a tagged version,
though since none of the underlying mechanisms are used this should
balance both remaining stable, supported for a period of time, and
providing usable functionality.

Resolves gohugoio#5970
Affects gohugoio#5056

anthonyfok added a commit that referenced this issue May 23, 2019

dockerfile: Switch base image for final build
Switching the base image for the final build to alpine as it still
provides a minimal interface, but has a mechanism for easily including
relevant CA certificates.  This is currently pinned to a tagged version,
though since none of the underlying mechanisms are used this should
balance both remaining stable, supported for a period of time, and
providing usable functionality.

Resolves #5970
Affects #5056
@stale

This comment has been minimized.

Copy link

commented Jun 1, 2019

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.

@stale stale bot added the Stale label Jun 1, 2019

@Yajo

This comment has been minimized.

Copy link

commented Jun 3, 2019

This is a feature request, but I think it's still relevant because the job of creating a static blog is most likely to be done via a CI/CD system, and all of them nowadays work or support natively Docker/OCI images to execute those jobs.

Besides, some dependencies for some parts of hugo are not clear in the docs, and having a image where everything is available and installed makes it easier to maintain, because:

  • If an issue cannot be reproduced in the image, it's a problem in your installation.
  • If it cannot be reproduced outside the image, it's a problem in the image.

So you have one supported distribution that works everywhere. It's good!

FTR I currently use registry.gitlab.com/pages/hugo, which seems to be a properly maintained image.

@stale stale bot removed the Stale label Jun 3, 2019

@bep

This comment has been minimized.

Copy link
Member

commented Jun 3, 2019

We will eventually get around to this. I have registered that GitHub now has a Docker registry, which should simplify the account/permission situation. I have a Docker release image (used to build Hugo releases) living under my account which I plan to move below /gohugoio ... when I get my priorities straight....

@bep bep modified the milestones: v0.56, v0.57 Jun 14, 2019

@bep bep modified the milestones: v0.57, v0.58 Jul 31, 2019

@bep bep modified the milestones: v0.58, v0.59 Aug 13, 2019

@bep

This comment has been minimized.

Copy link
Member

commented Aug 17, 2019

We're (the gohugoio org) now in the GitHub Package Registry program, which should at least lay the foundation for this.

https://help.github.com/en/articles/about-github-package-registry?utm_source=announcement&utm_medium=email&utm_campaign=ww-gpr-beta

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
7 participants
You can’t perform that action at this time.