support Go first class ports as targets

[mvdan]

Is your feature request related to a problem? Please describe.

Go has a notion of first class ports; it's the GOOS/GOARCH combinations for which upstream Go publishes binary releases. Since golang/go#38874, this information is also provided by cmd/go itself:

$ go version
go version go1.18.1 linux/amd64
$ go tool dist list -json | jq -r '.[] | select(.FirstClass) | [.GOOS, .GOARCH] | @tsv'
darwin	amd64
darwin	arm64
linux	386
linux	amd64
linux	arm
linux	arm64
windows	386
windows	amd64

I can manually copy this table over to the builsd.targets section as follows:

builds:
- targets:
  - darwin_amd64
  - darwin_arm64
  - linux_386
  - linux_amd64
  - linux_arm
  - linux_arm64
  - windows_386
  - windows_amd64

However, this is verbose and cumbersome - especially as Go's first-class ports can change with each Go version. I wouldn't be surprised if windows_arm64 was added in a future Go release, for example. Hard-coding a list is also not great, as a first class port might be added in e.g. Go 1.19 but isn't yet ready in e.g. Go 1.18.x.

It's worth noting that first class ports are a bit of a fuzzy concept, but as described in https://github.com/golang/go/wiki/PortingPolicy#first-class-ports, they are a good starting point for Go projects to release binaries. If upstream Go treats these ports as important and well tested, then they are less likely to break and more likely to be popular among users.

Describe the solution you'd like

Some way to ask goreleaser to build with the first class GOOS/GOARCH targets. I'm not very experienced with YAML or how goreleaser configs work, so I'll leave the design a bit vague in that respect. As a strawman proposal, one could imagine:

builds:
- targets:
  - go_first_class
  - windows_arm64 # Windows on ARM64 isn't first class yet, but we think it's important

Describe alternatives you've considered

Manually listing the targets, as described; too verbose and can easily get stale over the years.

A GOOS/GOARCH matrix doesn't work either, because the first class ports are not a simple product of GOOS and GOARCH values. For example, darwin and linux have arm64 but windows does not, and linux and windows have 386 but darwin does not.

Search

• I did search for other open and closed issues before opening this.

Code of Conduct

• I agree to follow this project's Code of Conduct

Additional context

The catalyst here is the goreleaser config used in CUE: https://github.com/cue-lang/cue/blob/5127136cfc8c6b695c9d663bee8cb89f4c5df6ad/.goreleaser.yml#L13-L19

Note how it lacks multiple first class ports, which is unfortunate. linux/386 is still popular, for example.

[caarlos0]

I think this would be nice indeed, not sure of the UI for it yet, but will think about something.

[mvdan]

Yep, I agree that the UI isn't super clear. I'm not sure that there is an established pattern in YAML for a default list value that also allows adding (or removing?) custom elements.

Perhaps a YAML object would be easier than a list, given that it behaves more like a set in terms of duplicate elements.

[caarlos0]

@mvdan ended up going with your suggestion... #3062

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