-
-
Notifications
You must be signed in to change notification settings - Fork 7.5k
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
Release artifacts should match proper os and architecture naming #10073
Comments
So, I don't disagree, but we have had this naming scheme like ... forever, so changing it will create some havoc in the wild. |
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 Maybe this request is more a bug report then a feature report 🙂 |
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:
This might create convenience for some people. It is obviously logical to name binaries like you mentioned. What can be done ?Maybe this can be introduced in Hugo v1.000 which denotes breaking changes as per conventional commit guidelines. |
But that would also mean gohugo should never ever introduce breaking changes in their codebase 🤔 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. |
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 |
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. |
But create aliases with old filenames for the 2 most downloaded archives (to avoid Netlify etc. breaking). Fixes #10073
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. |
Currently release artifacts are created eg:
It would be good if that would match eg
TARGETOS
andTARGETARCH
and/orTARGETVARIANT
(alsodpkg --print-architecture
) from docker so these variables could be used inside Dockerfiles.TARGETOS:
linux
,darwin
,windows
TARGETARCH:
amd64
,arm64
Currently
amd64
must be mapped to64bit
andarm64
toARM64
.Suggestion:
The text was updated successfully, but these errors were encountered: