Release artifacts should match proper os and architecture naming

[mblaschke-daimlertruck]

Currently release artifacts are created eg:

• hugo_0.101.0_Linux-64bit.deb
• hugo_0.101.0_Linux-ARM64.deb

It would be good if that would match eg TARGETOS and TARGETARCH and/or TARGETVARIANT (also dpkg --print-architecture) from docker so these variables could be used inside Dockerfiles.

TARGETOS: linux, darwin, windows
TARGETARCH: amd64, arm64

Currently amd64 must be mapped to 64bit and arm64 to ARM64.

Suggestion:

• hugo_0.101.0_linux-amd64.deb
• hugo_0.101.0_linux-arm64.deb
• hugo_0.101.0_darwin-amd64.deb (or keep it macos)
• hugo_0.101.0_darwin-arm64.deb (or keep it macos)

[bep]

So, I don't disagree, but we have had this naming scheme like ... forever, so changing it will create some havoc in the wild.

[mblaschke-daimlertruck]

But it would make much more sense and it would make it easier to install it. Now we have to map it for each os/arch to get it installed.

And *_Linux-64bit doesn't make sense as 64bit is not an architecture 😉

Maybe this request is more a bug report then a feature report 🙂

[sid-r-singh]

I agree with you, @mblaschke-daimlertruck that it would make more sense to have such naming.

But I wonder what will happen the moment this is done. In my limited knowledge, this can lead to:

• Thousands of websites which depend on Netlify will suffer (unless Netlify also recognises the change & implements fix). Same with Cloudfare pages & other similar services.
• All Hugo websites which pull the latest Hugo binaries in their CI/CD pipeline will fail.
• Any organisation which uses Hugo in production (which includes government websites in some countries) will have their builds fail if they are trying to fetch the latest Hugo binaries.

This might create convenience for some people. It is obviously logical to name binaries like you mentioned.
But don't you think the inconvenience which this will create outweighs the convenience it will create?

What can be done ?

Maybe this can be introduced in Hugo v1.000 which denotes breaking changes as per conventional commit guidelines.

[mblaschke-daimlertruck]

• Thousands of websites which depend on Netlify will suffer (unless Netlify also recognises the change & implements fix). Same with Cloudfare pages & other similar services.
• All Hugo websites which pull the latest Hugo binaries in their CI/CD pipeline will fail.
• Any organisation which uses Hugo in production (which includes government websites in some countries) will have their builds fail if they are trying to fetch the latest Hugo binaries.

But that would also mean gohugo should never ever introduce breaking changes in their codebase 🤔
From the last 2 years I can tell that there were many breaking changes which broke our builds but that is expected when using latest. It's the same when using docker tag :latest.

What about shipping Docker images? Many people and GitHub actions are using Docker based builds but https://hub.docker.com/r/gohugoio/hugo was updated 5 years ago.

You could also upload the old layout and deprecate them but also upload the new one so people have time to adapt it.

[paolomainardi]

This is a quick and dirty dockerfile I am using to multiplatform building:

FROM alpine:3.11.3
RUN apk add --no-cache vim py-pip python curl build-base libc6-compat

# Download and install hugo
ARG TARGETARCH
ENV HUGO_VERSION 0.102.3

# Install Hugo.
RUN if [ $TARGETARCH == 'arm64' ]; then  \
      export HUGO_BINARY=hugo_extended_${HUGO_VERSION}_Linux-ARM64.tar.gz; \
    else \
      export HUGO_BINARY=hugo_extended_${HUGO_VERSION}_Linux-64bit.tar.gz; \
    fi && \
    curl -Lo /tmp/${HUGO_BINARY} https://github.com/gohugoio/hugo/releases/download/v${HUGO_VERSION}/${HUGO_BINARY} \
    && tar xzf /tmp/${HUGO_BINARY} -C /usr/local/bin \
    && rm -rf /tmp/*

# Add sources.
WORKDIR /app
ADD src/ .

# By default, serve site.
EXPOSE 1313 35729
CMD hugo server --bind 0.0.0.0

[bep]

https://hub.docker.com/r/gohugoio/hugo was updated 5 years ago.

That's not our Docker account. And yes, you could argue that we should do something about that.

I have since this issue was created I have spent a stupid amount of energy rewriting Hugo's build/release setup, which makes it considerably cheaper to keep one or more "alias archives". So I suggest that for the next release we release with new names, but keep the Linux AMD64 as a duplicate for the forseaable future, which should cover the Netlify people etc.

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