Conditional Build Handling Based on OS Running goreleaser

[bflad]

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

We have a goreleaser configuration that is setup with a single cross-compilation build section. We are in the process of trying to conditionally enable CGO/netcgo if the goreleaser process is running on the same OS that is being built (or very particularly in our case, if it is running on darwin). Builds for other OS should not try to enable that additional configuration as the cross-compilation will fail.

Describe the solution you'd like

Initial proposal:

goreleaser could potentially expose the runtime.GOOS of the goreleaser process as a field in the templating engine, such as .CurrentOS, then I think we could theoretically setup our configuration like:

builds:
  - id: darwin
    flags:
      - -trimpath
    goos:
      - darwin
    goarch:
      - amd64
      - arm64  
    ldflags:
      - '-s -w -X main.version={{.Version}} -X main.commit={{.Commit}}'
    mod_timestamp: '{{ .CommitTimestamp }}'
    tags:
      - {{ if eq .CurrentOS "darwin" }}netcgo{{ end }}
  - id: default
    flags:
      - -trimpath
    goos:
      - freebsd
      - linux
      - windows
    goarch:
      - '386'
      - amd64
      - arm
      - arm64
    ldflags:
      - '-s -w -X main.version={{.Version}} -X main.commit={{.Commit}}'
    mod_timestamp: '{{ .CommitTimestamp }}'

Other thoughts:

Supporting special build configuration that is per os/arch/target within a build would then allow the configuration to be DRY, e.g.

builds:
  -
    flags:
      - -trimpath
    goos:
      - darwin
      - freebsd
      - linux
      - windows
    goarch:
      - '386'
      - amd64
      - arm
      - arm64
    ldflags:
      - '-s -w -X main.version={{.Version}} -X main.commit={{.Commit}}'
    mod_timestamp: '{{ .CommitTimestamp }}'
    target_specific: # or os_specific or arch_specific or something allowing os/arch/target configuration
      darwin_amd64:
        tags:
          - {{ if eq .CurrentOS "darwin" }}netcgo{{ end }}
      darwin_amd64:
        tags:
          - {{ if eq .CurrentOS "darwin" }}netcgo{{ end }}

I'm also not sure if there might be a better way to expose "configuration that should apply when the current os/arch/target matches the running goreleaser process", e.g. very roughly

builds:
  -
    current_os_only:
      env:
        CGO_ENABLED=1
      tags:
        - netcgo # in our case, we'd probably still use {{ if .CurrentOS == "darwin" }} here to prevent the behavior on other OS
    flags:
      - -trimpath
    goos:
      - darwin
      - freebsd
      - linux
      - windows
    goarch:
      - '386'
      - amd64
      - arm
      - arm64
    ldflags:
      - '-s -w -X main.version={{.Version}} -X main.commit={{.Commit}}'
    mod_timestamp: '{{ .CommitTimestamp }}'

I think the os/arch/target specific configuration would be more clear than this last one.

Describe alternatives you've considered

Hardcoding some special environment variable flag in the CI configuration, which could then apply a goreleaser template with {{ if index .Env "EXAMPLE" }}netcgo{{ end }}. This only fixes the issue for CI builds though, not local builds using goreleaser without extra documentation (or a specific Makefile target) that can be easily missed. Also, it can fail if incorrectly used.

Having separate goreleaser configurations for CI versus local or configurations that are OS specific depending on where goreleaser is running.

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

In our particular situation, this would be a viable workaround for #2320 since we only need CGO/netcgo on one OS (darwin) because of golang/go#12524.

Thanks for such as great project and happy to contribute.

[caarlos0]

goreleaser could potentially expose the runtime.GOOS of the goreleaser process as a field in the templating engine, such as .CurrentOS, then I think we could theoretically setup our configuration like:

this seems reasonable to me, will work on it.

Supporting special build configuration that is per os/arch/target within a build would then allow the configuration to be DRY, e.g.

this is also a good idea IMHO, will work on it as well.

[caarlos0]

can you take a look at #2859 and #2860

[caarlos0]

TODO: see if we can do the same for environment variables

[caarlos0]

TODO: see if we can do the same for environment variables

unfortunately, its not possible... we use the env for templates and thing that happen before we even get to the build line stuff... so, we'd had to break compatibility or do something else that would also be probably confusing.

refs #2583

---

that said, as the other things were implement, will close this one for now.

if we eventually find out we really really really need the env stuff, we can try to find a way to do it in another issue.

Thanks!