go/goreleaser
go/goreleaser
1
0
Fork 0
mirror of https://github.com/goreleaser/goreleaser.git synced 2025-03-17 20:47:50 +02:00
Code Issues Releases Activity

docs: clarify dist folder names

Browse Source 
refs https://github.com/goreleaser/goreleaser/discussions/3183

Signed-off-by: Carlos A Becker <caarlos0@users.noreply.github.com>
This commit is contained in:
Carlos A Becker 2022-06-22 23:55:46 -03:00
parent 4162772819
commit 8424c92102
No known key found for this signature in database
GPG Key ID: E61E2F7DC14AB940
1 changed files with 20 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

23
www/docs/customization/build.md
View File

@ -165,11 +165,11 @@ builds:
# Default is false
skip: false
# By default, GoRelaser will create your binaries inside `dist/${BuildID}_${BuildTarget}`, which is an unique directory per build target in the matrix.
# You are able to set subdirs within that folder using the `binary` property.
# By default, GoReleaser will create your binaries inside `dist/${BuildID}_${BuildTarget}`, which is an unique directory per build target in the matrix.
# You can set subdirs within that folder using the `binary` property.
#
# However, if for some reason you don't want that unique directory to be created, you can set this property.
# If you do, you are responsible of keeping different builds from overriding each other.
# If you do, you are responsible for keeping different builds from overriding each other.
#
# Defaults to `false`.
no_unique_dist_dir: true
@ -443,3 +443,20 @@ There is no difference in how the binaries are handled.
You'll need to either provide them or the final `targets` matrix.
If you'd like to see this in action, check [this example on GitHub](https://github.com/caarlos0/goreleaser-pro-prebuilt-example).
## A note about folder names inside `dist`
By default, GoReleaser will create your binaries inside `dist/${BuildID}_${BuildTarget}`, which is an unique directory per build target in the matrix.
Those names have no guarantees of remaining the same from one version to another.
If you really need to access them from outside GoReleaser, you should be able to consistently get the path of a binary by parsing `dist/artifacts.json`.
You can also set `builds.no_unique_dist_dir` (as documented earlier in this page), but in that case you are responsible for preventing name conflicts.
### Why is there a `_v1` suffix on `amd64` builds?
Go 1.18 introduced the `GOAMD64` option, and `v1` is the default value for that option.
Since you can have GoReleaser build for multiple different `GOAMD64` targets, it adds that suffix to prevent name conflicts.
The same thing happens for `arm` and `GOARM`, `mips` and `GOMIPS` and others.