Repository: gohugoio/hugo (language: go)

Issue:
Create and publish official Docker images
The latest docker image on https://hub.docker.com/r/klakegg/hugo is 0.111.3 which was pushed 2 weeks ago but was released on 12 March.
When searching for any higher version like 0.112.0 or 0.114.0 no images/tags can be found.

Same issue as #10324 reported some months ago.


Discussion / hints:
/cc ... @klakegg 
Hi @klakegg, may I kindly remember you regarding this issue?
Have a look here: https://discourse.gohugo.io/t/the-up-to-date-hugo-docker-images/43293  I think we should make this one (or another) default since @klakegg has not touched the repo since end of last year + also in the past (based on the issues/PRs there) the communication wasnt the very best. Likely some private matters - So why not move the docker stuff into a more community handled repo? 
@fsmeier Thanks for pointing this thread out to me.

In my opinion it would be best if something along the lines of a CI/CD is directly implemented within the `gohugoio/hugo` repository with the help of e.g. GitHub Actions. Using just another private implementation/pipeline would be also prone to the same errors as before.

Additionally, using a CI/CD, one could use something with a more "official" name, e.g. hub.docker.com/r/hugo or similiar.
Currently, it might be hard to guess the correct repository - if its klakegg or razonyang or any other repo which might be created in the future.

However, the question would be if hugo wants to support/provide a docker image directly.
If yes, than I would propose that it is also handled directly by hugo and it's community using an official name.
Otherwise, I would be fine with any other third-party named repository, however, I think I would build my own image just for the sake of continuity and security.
As this issue is now link from other ones, I want to take the oppertunity to summarize the current state:

As far as I know, klakegg's repository is/was the one, which was references as the most official repository.
When searching for a hugo image, several others pop up using Google search and/or directly on dockerhub:
https://hub.docker.com/r/nixpkgs/hugo
https://hub.docker.com/r/razonyang/hugo
https://hub.docker.com/r/immawanderer/archlinux-hugo
https://github.com/jojomi/docker-hugo
https://github.com/jguyomard/docker-hugo

Some have several thousand pulls. Also GitLab itself (https://gitlab.com/gitlab-ci-utils/docker-hugo) built its own image to use within their CI/CD.
Klakegg's repository (https://hub.docker.com/r/klakegg/hugo) has over 10M pulls.

The repository which would be the "offical" one regarding the name (https://hub.docker.com/r/gohugoio/hugo) has also over 6k pulls but is currently not maintained.

As you can see, the repositories are cluttered over the web and several companies/ppl are creating ones so there is definitely a need for it.
Devs new to Hugo would have a hard time figuring out which image to use and, in the worst case, would use one which is not maintained anymore. Even if they do it is unsure how long it is maintained (see klakegg)

For myself, I also like to use an image in my CI/CD as it saves me from the trouble of always downloading the binary and installing it. The image is cached by k8s (or whatever cluster you're using), but the download would be not by default.

In the end, I would strongly recommend to create an official repository (using gohugoio/hugo in the best case).
For extended builds, [Kaniko](https://github.com/GoogleContainerTools/kaniko) could be of use, however, as hugo can be installed as a single-binary the Dockerfile itself should be fairly simple.

If needed, I can provide help to set up a CI. Currently, I'm only using GitLab's CI, however, familiarize myself with GitHub Actions should be possible :)
an earlier PR is at https://github.com/gohugoio/hugo/pull/8700
@bep Updated title and description as @klakegg seem to have pushed 0.111.3 to the repository 2 weeks ago. However, this version was released more than 3 months ago and is already outdated.
@bep Latest tag on @klakegg is still 0.111.3 but current release is 0.117.0.

In general, is an offical docker image something which is likely to be considered, or is it more like a "wont-fix"?
>or is it more like a "wont-fix"?

It's currently mostly a "don't have time", which you could also blame on priorities.
Thanks for your answer @bep.
I just wanted to know, as there was only little feedback. I can fully understand, if you're short on time or have other priorities.
But I'm glad that this is considered and maybe the community (and I) can help you out.

Is this something you would accept a merge request for, or would you prefer to do it on your own, maybe because you have some restrictions/requirements in mind?
Yea, this project is a handful of maintainers more or less active, and when one of those (e.g. klakegg) gets other priorities (e.g. life/work), this happens. 

To ask a more practical question -- how does Docker images published to GitHub work vs. Docker hub? I say this because that would simplify "things". I'm trying to avoid having to maintain yet another or on yet another host.


@bep Publishing should work in the same way and technically there is no much difference than to use another domain to push the image to.

For both options there are examples in GitHub's documentation on how to implement this workflow using GitHub Actions: https://docs.github.com/en/actions/publishing-packages/publishing-docker-images

However, using the Docker Hub would have some significant advantages:
If someone wants to use hugo, they propably search on Docker Hub at first and pull the image using `docker pull gohugoio/hugo`.
Personally, I always search for images on Docker Hub prior to anywhere else.

If using GitHub Packages, either the docker daemon needs to be reconfigured to use ghcr.io as an additional registry, or one needs to run `docker run ghcr.io/gohugoio/hugo`.

Additionally, Google shows the Docker Hub at the very first position and there is already an entry for gohugoio/hugo.
I'd propose either to update the repository there or to try to remove it as it does not reflect the current state of the application.
Hi @Flauschbaellchen, It seems that this issue has not been improved yet. Before the official release of the docker image, I created an automated GitHub CICD process to fetch the latest version daily, compile it into a docker image, and push it to docker hub.

I currently offer versions after v0.115.4. Although the images provided are not as rich as [klakegg/hugo](https://hub.docker.com/r/klakegg/hugo), I believe they should be sufficient for use. If there are any inconveniences or requirements, feel free to provide me with a PR.

Hugo's release version after v0.115.4 can be accessed using the image I provide at [jafee201153/hugo](https://hub.docker.com/r/jafee201153/hugo/tags).
If you encounter any issues or have feature requests, please submit an issue or PR at: https://github.com/leoli0605/docker-hugo.
@leoli0605 I don't think it's a good idea to have just _another_ docker repository for hugo.
This issue/discussion exists to prevent it.

I think it just takes a bit more time and some discussion what would be the best way so we don't need to change something else only some months in the future.
As far as I understand, there is no rejection against an offical docker image.
I do the development of my blog using a Hashicorp product called [Vagrant](https://www.vagrantup.com/).  Think of Vagrant like Docker, but for VMs (e.g., declarative file with all dependencies, easy to pass around to different machines to have the same development environment).

If you're not aware, Hashicorp recently [changed](https://www.hashicorp.com/blog/hashicorp-adopts-business-source-license) all of their products to a Business Source License (BSL). This has mostly upset the [Terraform](https://www.terraform.io/) community, but it affects all Hashicorp products. Here is the [commit](https://github.com/hashicorp/vagrant/commit/731e9cb6c48df71d8c3f8d2b929dd35875250d2d) with the change to Vagrant's license.

I'd like to start doing development of my blog in Docker, but found the https://hub.docker.com/r/gohugoio/hugo image hasn't been updated in years. Doing some searching, I found this issue. 

I'm all in favor of having an official Docker image, I just think Hugo should advertise *which* image that is. It's not clear if that is `klakegg/hugo` or `hugomods/hugo` or something else. Ideally, Hugo would use CI/CD to publish their own image (whether it's to DockerHub or GHCR doesn't matter to me).
@Flauschbaellchen I completely agree with your point that continuous deployment of updates on DockerHub by the official is the best practice. However, it seems that neither the official nor `klakegg/hugo` intends to maintain it continuously at the moment. Therefore, I just provided a transitional solution before the official source is willing to continue this maintenance process. (Although I am not sure why there are concerns about manpower when this can be fully automated through CI/CD.)
hi all,
For those who's searching for an updated version of @klakegg repository, i cloned it and made an github workflow that will update the repo and respective Docker images whenever new hugo version is released. For those interested, you can take a look at https://github.com/floryn90/docker-hugo 
Hey @bep Can we keep [this discussion ongoing](https://github.com/gohugoio/hugo/issues/10760#issuecomment-1698560025)? As you see, others are happily creating new repositories, increasing the chaos already present :see_no_evil: 
I just stumbled upon this since I was confused that the most recent image on https://hub.docker.com/r/gohugoio/hugo is 6 years old.

I'm one of the maintainers for https://github.com/community-tooling, we do maintain a set of OCI images in the https://github.com/community-tooling/oci-images repository, these are built 100% automated and published to GitHub Packages.

If there's interest here, I can open a PR with a GitHub Actions workflow that will automatically build and publish new OCI/Docker images for every release.
Just want to add this seems like such an obvious win, as others have shown once its up and running it shouldn't take make much to keep going. Not only that the docker pulls are a much more relevant sign than the github requests.

@Flauschbaellchen @morremeyer please keep trying.

Fix patch:
diff --git a/.github/workflows/image.yml b/.github/workflows/image.yml
new file mode 100644
index 00000000000..477343bb271
--- /dev/null
+++ b/.github/workflows/image.yml
@@ -0,0 +1,120 @@
+name: Build Docker image
+
+on:
+  push:
+    tags:
+      - "*"
+    paths:
+      - Dockerfile
+      - .github/workflows/image.yml
+  pull_request:
+permissions:
+  packages: write
+
+env:
+  REGISTRY_IMAGE: ghcr.io/gohugoio/hugo
+
+jobs:
+  build:
+    runs-on: ubuntu-latest
+    strategy:
+      fail-fast: false
+      matrix:
+        platform:
+          - linux/amd64
+          - linux/arm64
+    steps:
+      - name: Prepare
+        run: |
+          platform=${{ matrix.platform }}
+          echo "PLATFORM_PAIR=${platform//\//-}" >> $GITHUB_ENV
+
+      - name: Checkout
+        uses: actions/checkout@692973e3d937129bcbf40652eb9f2f61becf3332 # v4.1.7
+
+      - name: Docker meta
+        id: meta
+        uses: docker/metadata-action@8e5442c4ef9f78752691e2d8f8d19755c6f78e81 # v5.5.1
+        with:
+          images: ${{ env.REGISTRY_IMAGE }}
+
+      - name: Set up QEMU
+        uses: docker/setup-qemu-action@49b3bc8e6bdd4a60e6116a5414239cba5943d3cf # v3.2.0
+
+      - name: Set up Docker Buildx
+        uses: docker/setup-buildx-action@988b5a0280414f521da01fcc63a27aeeb4b104db # v3.6.1
+
+      - name: Login to GHCR
+        # Login is only needed when the image is pushed
+        uses: docker/login-action@9780b0c442fbb1117ed29e0efdff1e18412f7567 # v3.3.0
+        with:
+          registry: ghcr.io
+          username: ${{ github.repository_owner }}
+          password: ${{ secrets.GITHUB_TOKEN }}
+
+      - name: Build and push by digest
+        id: build
+        uses: docker/build-push-action@16ebe778df0e7752d2cfcbd924afdbbd89c1a755 # v6.6.1
+        with:
+          context: .
+          push: ${{ startsWith(github.ref, 'refs/tags') }}
+          platforms: ${{ matrix.platform }}
+          labels: ${{ steps.meta.outputs.labels }}
+          outputs: type=image,name=${{ env.REGISTRY_IMAGE }},push-by-digest=true,name-canonical=true,push=true
+
+      - name: Export digest
+        run: |
+          mkdir -p /tmp/digests
+          digest="${{ steps.build.outputs.digest }}"
+          touch "/tmp/digests/${digest#sha256:}"
+
+      - name: Upload digest
+        uses: actions/upload-artifact@834a144ee995460fba8ed112a2fc961b36a5ec5a # v4.3.6
+        with:
+          name: digests-${{ env.PLATFORM_PAIR }}
+          path: /tmp/digests/*
+          if-no-files-found: error
+          retention-days: 1
+
+  merge:
+    runs-on: ubuntu-latest
+    needs:
+      - build
+    steps:
+      - name: Download digests
+        uses: actions/download-artifact@fa0a91b85d4f404e444e00e005971372dc801d16 # v4.1.8
+        with:
+          path: /tmp/digests
+          pattern: digests-*
+          merge-multiple: true
+
+      - name: Set up Docker Buildx
+        uses: docker/setup-buildx-action@988b5a0280414f521da01fcc63a27aeeb4b104db # v3.6.1
+
+      - name: Docker meta
+        id: meta
+        uses: docker/metadata-action@8e5442c4ef9f78752691e2d8f8d19755c6f78e81 # v5.5.1
+        with:
+          images: ${{ env.REGISTRY_IMAGE }}
+
+          flavor: |
+            latest=false
+
+      - name: Login to GHCR
+        uses: docker/login-action@9780b0c442fbb1117ed29e0efdff1e18412f7567 # v3.3.0
+        with:
+          registry: ghcr.io
+          username: ${{ github.repository_owner }}
+          password: ${{ secrets.GITHUB_TOKEN }}
+
+      - name: Create manifest list and push
+        if: ${{ startsWith(github.ref, 'refs/tags') }}
+        working-directory: /tmp/digests
+        run: |
+          docker buildx imagetools create $(jq -cr '.tags | map("-t " + .) | join(" ")' <<< "$DOCKER_METADATA_OUTPUT_JSON") \
+            $(printf '${{ env.REGISTRY_IMAGE }}@sha256:%s ' *)
+
+      - name: Inspect image
+        if: ${{ startsWith(github.ref, 'refs/tags') }}
+        run: |
+          docker buildx imagetools inspect ${{ env.REGISTRY_IMAGE }}:${{ steps.meta.outputs.version }}


Test patch: