dist directories for amd64: ddev_darwin_amd64_v1, ddev_linux_amd64_v1 etc

[rfay]

Am I doing something wrong in my trivial .goreleaser-build.yaml with goreleaser build --snapshot --rm-dist -f .goreleaser-build.yaml? - I just want directories for darwin_arm64, darwin_amd64, etc. and instead in dist I get

$ ls dist | cat
artifacts.json
completions_darwin_amd64_v1
completions_darwin_arm64
completions_linux_amd64_v1
completions_linux_arm64
completions_windows_amd64_v1
config.yaml
ddev_darwin_amd64_v1
ddev_darwin_arm64
ddev_linux_amd64_v1
ddev_linux_arm64
ddev_windows_amd64_v1
metadata.json

Why are all the amd64's amd64_v1?

[caarlos0]

v1 is the GOAMD64 version (v1 is the default). Similar things happen on arm/mips, in which GOARM/GOMIPS are appended to the folder name.

Those folders inside dist are considered "internal", there are no guarantees they would not change.

You can inspect artifacts in a more proper manner by parsing dist/artifacts.json.

[rfay]

Thanks... I sure would expect a predictable naming mechanism, and I wouldn't expect to have to parse a json file to find my artifacts. I guess your assumption is that a release is about to happen, and the release procedure will use the json to find its way to what it needs. But in my case, I can't use the all-in-one process because I have to do things like signing and notarizing after the build, which means I have to stop with the build (and come back later for the release). So this ends up being pretty awkward. Should I be doing something different to generate build artifacts?

[rfay]

Hmm, you say in commit

The same thing happens for arm and GOARM, mips and GOMIPS and others

But clearly the arm64 folders do not have _v1

[rfay]

I guess in my traditional builds I always have GOOS=darwin GOARCH=amd64 and then go build -o $(GOTMP)/bin/$$TARGET -installsuffix static -ldflags " $(LDFLAGS) so I'm forcing the output to a named directory, but still, in the traditional GOOS+GOARCH approach there's no v1 going on or even entering the arena.

[rfay]

I see a good description of GOAMD64 in https://utcc.utoronto.ca/~cks/space/blog/programming/GoAmd64ArchitectureLevels - but it doesn't seem like very many of us would want to build/ship for anything other than v1 because the world would blow up with people having a binary they couldn't use... after all these years of being able to trust that amd64/x86-64 meant "I'm your friendly always the same instruction set".

I'd encourage you, since the targets are things like darwin_amd64, to not clutter with directory names that are different from the targets, and to assume that people will in fact use the dist directories directly. If you'd like an issue saying that I'll do it...

[caarlos0]

But clearly the arm64 folders do not have _v1

arm64 != arm, and even on arm, there is no v1, the allowed values for GOARM, GOMIPS and GOAMD64 are different from each other.

GOOS+GOARCH approach there's no v1 going on or even entering the arena

even if you don't specify GOAMD64, its there, set as v1 by default, since go 1.18.

many of us would want to build/ship for anything other than v1

there's a lot of features in goreleaser that many of us don't need... including constant build folder names :)

I sure would expect a predictable naming mechanism

it is predictable within the same version, it might change from one version to another, specially if Go adds more build options.

Should I be doing something different to generate build artifacts?

if you need to notarize in different OS's unfortunately, there isn't anything much different to do.

You can check https://github.com/caarlos0/goreleaser-pro-prebuilt-example and also there's an upcoming feature on goreleaser pro 1.10 that might help, here's a sneak peek: https://www.youtube.com/watch?v=G0MF0R_LD1g