override env getting ignored?

[thediveo]

When a not-too-often run CI/CD goreleaser stage "suddenly" failed I looked into my previously working .goreleaser.yaml, running it locally in order to figure out what is wrong. While I can work around for the moment, I wonder what I'm doing wrong for the override applied, but not its env var.

I'm using goreleaser 2.6.1, but also tried with 2.5.1 with the same effects. OS is Linux, distro is Ubuntu 24.04.1LTS, go is 1.23.5.

That's what my .goreleaser.yaml basically looks like, with some private details removed:

version: 2
project_name: xxx
dist: ./dist

builds:
  - id: default
    main: ./cmd/xxx
    binary: xxx
    targets:
      - linux_amd64_v1
      - linux_arm64
    tags:
      - netgo
      - osusergo
    ldflags:
      - '-s -w -X main.version={{.Version}} -X main.commit={{.Commit}} -X main.date={{.Date}} -X main.builtBy=goreleaser'
    env:
      - CGO_ENABLED=1
    overrides:
      - goos: linux
        goarch: arm64
        goarm: "v8.0" # not strictly necessary anymore, thanks for the bug fix months ago!
        env:
          - CC=aarch64-linux-gnu-gcc

Please notice the arm64-specific CC env var override. Now (please scroll to the right in order to not miss the override debug output stating that CC is now set for arm64):

goreleaser release --snapshot --clean --verbose

...

  • building binaries
    • building                                       build={default [] [] [] [] [] [] [] [] [] [linux_arm64_v8.0 linux_amd64_v1] [] . ./cmd/xxx xxx {[] []} go    go build  false   { [-s -w -X main.version={{.Version}} -X main.commit={{.Commit}} -X main.date={{.Date}} -X main.builtBy=goreleaser] [netgo osusergo] [] [] [] [CGO_ENABLED=1]} [{linux arm64    v8.0    { [] [] [] [] [] [CC=aarch64-linux-gnu-gcc]}}]}
    • building                                       binary=dist/default_linux_amd64_v1/xxx
    • building                                       binary=dist/default_linux_arm64_v8.0/xxx
    • targets don't match: linux_amd64_v1 != linux_arm64_v8.0
    • env "CGO_ENABLED=1" evaluated to "CGO_ENABLED=1"
    • executing                                      cmd=go
    • overridden build details for linux_arm64_v8.0  details={ [-s -w -X main.version={{.Version}} -X main.commit={{.Commit}} -X main.date={{.Date}} -X main.builtBy=goreleaser] [netgo osusergo] [] [] [] [CGO_ENABLED=1 CC=aarch64-linux-gnu-gcc]}
    • env "CGO_ENABLED=1" evaluated to "CGO_ENABLED=1"
    • executing                                      cmd=go
    • added new artifact                             name=xxx type=Binary path=dist/default_linux_amd64_v1/xxx
  ⨯ release failed after 1s                 
    error=
    │ build failed: failed to build for linux_arm64_v8.0: exit status 1: # runtime/cgo
    │ gcc_arm64.S: Assembler messages:
    │ gcc_arm64.S:30: Error: no such instruction: `stp x29,x30,[sp,'

Changing the CC env override to some non-existing nonsense, such as CC=xxxx does not trigger an error that the C compiler cannot be found. The debug shows the overridden CC env var, but it obviously does not get applied, as with an invalid env var setting, the build does still fail with the wrong compiler chain instead of a missing C compiler binary.

When unrolling the builds as follows, the build for arm64 now succeeds.

builds:
  - id: amd64
    main: ./cmd/xxx
    binary: xxx
    goos:
      - linux
    goarch:
      - amd64
    tags:
      - netgo
      - osusergo
    ldflags:
      - '-s -w -X main.version={{.Version}} -X main.commit={{.Commit}} -X main.date={{.Date}} -X main.builtBy=goreleaser'
    env:
      - CGO_ENABLED=1

  - id: arm64
    main: ./cmd/xxx
    binary: x
    goos:
      - linux
    goarch:
      - arm64
    tags:
      - netgo
      - osusergo
    ldflags:
      - '-s -w -X main.version={{.Version}} -X main.commit={{.Commit}} -X main.date={{.Date}} -X main.builtBy=goreleaser'
    env:
      - CGO_ENABLED=1
      - CC=aarch64-linux-gnu-gcc

What stupid mistake did I manage to put into my goreleaser configuration -- bonus: and why did my pipeline previously succeeded a few weeks ago on golang:1.23.4?

[caarlos0]

Seems like this is the same bug fixed in #5492

Will release the fix soon-ish.

[thediveo]

seems like this bug is stalking me... I need to change my, erm, environment ... oh, wait...