extract ldflags only à la govvv?

[Sylvain303]

Hello,

I'm new to goreleaser, I may have missed some behavior. Please gently point me to the correct sample.

On a daily building process, I would do make with a default target that will fetch and prepare the ldflags:

get_ldflags.sh was using govvv to extract / generate ldflags strings.

outputs:

-X main.BuildDate=2022-09-13T05:24:21Z -X main.GitCommit=2b51559 -X main.GitBranch=master -X main.GitState=dirty -X main.GitSummary=v0.6.4-with-no-mangle-double-dash-11-g2b51559 -X main.Version=v0.6.4-with-no-mangle-double-dash -X 'main.GoBuildVersion=go version go1.19.1 linux/amd64' -X 'main.ByUser=sylvain'

BUILD_FLAGS=$(shell ./get_ldflags.sh)
docopts: docopts.go Makefile VERSION
	go build -o $@ -ldflags "${BUILD_FLAGS} ${LDFLAGS}

On dirty not committed, code, etc.

We are moving from hand crafted hacky shell script to goreleaser for go cross-compling and publishing release on github. Most of my hacking seems provided out of the box by goreleaser. 😉

$ goreleaser --version
goreleaser version dev
goos: linux
goarch: amd64
module version: v1.11.2, checksum: h1:LqKj+63p60dRF3PA15+y+DN9jP6IMrxvyOpZ40YLJ5E=

$ go version
go version go1.19.1 linux/amd64

https://github.com/agilgur5/docopts/blob/014280cd3be84399f532e3b8e3ff7fefb4e32600/.goreleaser.yaml

builds:
  - env:
      - CGO_ENABLED=0
    targets:
      - darwin_amd64
      - darwin_arm64
      - freebsd_amd64
      - linux_386
      - linux_amd64
      - linux_arm
      - windows_amd64
    # https://goreleaser.com/customization/templates/
    # defaults: https://goreleaser.com/cookbooks/using-main.version
    ldflags:
      - -X "main.Version={{.Version}}"
      - -X "main.BuildDate={{.Date}}"
      - -X "main.GitCommit={{.ShortCommit}}"
      - -X "main.GoBuildVersion={{.Env.GOVERSION}}" # https://goreleaser.com/customization/build/#passing-environment-variables-to-ldflags

But reproducing go build -ldflags may be a bit tricky, though.

I tried:

GOVERSION=$(GOVERSION) goreleaser build --single-target --rm-dist --snapshot -o docopts

Which randomly does the trick, it still creates all other cross-compiled binaries in dist/ tree. And copy a random version to ./docopts:

here 32bits version: (go env gives: GOARCH="amd64")

sylvain@lap43: ~/code/go/src/github.com/docopt/docopts$ file ./docopts
./docopts: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, Go BuildID=QCFoLzZ6kg2SWglIU0Tz/tpQbTHlRfJtOLyBFBNQW/lQqLU94jSl6sG5ErrU08/TYx4lSAird9SLswk855s, with debug_info, not stripped

make clean; make also gives: ARM one, crazy

sylvain@lap43: ~/code/go/src/github.com/docopt/docopts$ ./docopts --version
bash: ./docopts: cannot execute binary file: Exec format error
sylvain@lap43: ~/code/go/src/github.com/docopt/docopts$ file ./docopts
./docopts: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), statically linked, Go BuildID=pffSydBRpgCHYh2-wQKL/kgJTxf_23TB26BdS8XzU/JZzHUoTqy3JuOlaMWEu3/aaJPVqbQMPSOV3LxnoiX, with debug_info, not stripped

Is it a normal behavior? Or --single-target should only build linux_amd64 in my case?

Another alternative would to ask gorelaser the generated value for ldflags. Then pass the ldflags value to go build -ldflags as I did previously.

Do you know if there's way do grab evaluated ldflags?

Or should I parse .goreleaser.yaml and rebuild it myself?

Regards,
Sylvain.

[caarlos0]

no that I'm aware of, but some of the vars that govvv provides, goreleaser provides as well:

https://goreleaser.com/cookbooks/using-main.version

[agilgur5]

@caarlos0 thanks for your response! If that's the case, maybe you could answer the second question that Sylvain had?

make also gives: ARM one, crazy

sylvain@lap43: ~/code/go/src/github.com/docopt/docopts$ ./docopts --version
bash: ./docopts: cannot execute binary file: Exec format error
sylvain@lap43: ~/code/go/src/github.com/docopt/docopts$ file ./docopts
./docopts: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), statically linked, Go BuildID=pffSydBRpgCHYh2-wQKL/kg

Is it a normal behavior? Or --single-target should only build linux_amd64 in my case?

I was confused by this as well -- not sure if we've found a bug here or if this is intentional behavior?

If I remove --snapshot and add some skips instead:

❯ make snapshot
GOVERSION=$(go version) goreleaser build --rm-dist --skip-before --skip-validate --single-target -o docopts
  • starting build...
  • loading config file                              file=.goreleaser.yaml
  • building only for darwin/amd64                   reason=single target is enabled
  • loading environment variables
  • getting and validating git state
    • building...                                    commit=014280cd3be84399f532e3b8e3ff7fefb4e32600 latest tag=v0.6.4-with-no-mangle-double-dash
    • pipe skipped                                   reason=validation is disabled
  • parsing tag
  • setting defaults
  • checking distribution directory
  • loading go mod information
  • build prerequisites
  • writing effective config file
    • writing                                        config=dist/config.yaml
  • generating changelog
    • writing                                        changelog=dist/CHANGELOG.md
  • building binaries
    • building                                       binary=dist/docopts_darwin_amd64_v1/docopts
    • building                                       binary=dist/docopts_freebsd_amd64_v1/docopts
    • building                                       binary=dist/docopts_windows_amd64_v1/docopts.exe
    • building                                       binary=dist/docopts_linux_386/docopts
    • building                                       binary=dist/docopts_linux_arm_6/docopts
    • building                                       binary=dist/docopts_linux_amd64_v1/docopts
    • building                                       binary=dist/docopts_darwin_arm64/docopts
    • took: 1s
  • storing release metadata
    • writing                                        file=dist/artifacts.json
    • writing                                        file=dist/metadata.json
  • copying binary to "docopts"
  • build succeeded after 0s

It still builds binaries for all architectures and even generates a changelog, despite this using goreleaser build --single-target

We'd like to just build one binary for quick local usage, as --single-target implies it does, but doesn't seem to actually do.
Also don't need a changelog as this is just goreleaser build not goreleaser release (and we use --release-notes anyway, but --release-notes isn't supported by goreleaser build).

---

(For reference, I'm the person who's migrating docopts to goreleaser to handle all build/publishing logic -- the code reference above is to my fork for docopt/docopts#65)

[caarlos0]

that might be a bug, probably because your amd64 targets are not properly formatted, they need the _GOAMD64 bit too, which in your case probably is _v1:

builds:
  - env:
      - CGO_ENABLED=0
    targets:
      - darwin_amd64_v1
      - darwin_arm64
      - freebsd_amd64_v1
      - linux_386
      - linux_amd64_v1
      - linux_arm
      - windows_amd64_v1
    # https://goreleaser.com/customization/templates/
    # defaults: https://goreleaser.com/cookbooks/using-main.version
    ldflags:
      - -X "main.Version={{.Version}}"
      - -X "main.BuildDate={{.Date}}"
      - -X "main.GitCommit={{.ShortCommit}}"
      - -X "main.GoBuildVersion={{.Env.GOVERSION}}" # https://goreleaser.com/customization/build/#passing-environment-variables-to-ldflags

fwiw those target names might change depending on new Go versions, so I would suggest using the goos and goarch matrix instead...

[caarlos0]

anyway, this should fix it: #3381

[Sylvain303]

@caarlos0 Thanks to the fix. It worked as expected with:

goreleaser version dev v1.11.3

👍

docopts: docopts.go Makefile
  GOVERSION=$(GOVERSION) goreleaser build --single-target --rm-dist --snapshot -o docopts

Gives only one version now and compiles only one.

My .goreleaser.yaml is still without _v1 suffix

builds:
  - env:
      - CGO_ENABLED=0
    targets:
      - darwin_amd64
      - darwin_arm64
      - freebsd_amd64
      - linux_386
      - linux_amd64
      - linux_arm
      - windows_amd64

You said:

amd64 targets are not properly formatted, they need the _GOAMD64 bit too

Would it means that linux_amd64 is an invalid target name?

I've found https://goreleaser.com/customization/build/?h=targets#why-is-there-a-_v1-suffix-on-amd64-builds
Would it means it's go >=1.18 only?

Also found: https://goreleaser.com/customization/build/?h=targets in the yaml.
But I don't fully understand what it means, they are optional, right?

    # Optionally override the matrix generation and specify only the final list of targets.
    # Format is `{goos}_{goarch}` with optionally a suffix with `_{goarm}`, `_{goamd64}` or `_{gomips}`.
    #
    # Special values:
    # - go_118_first_class: evaluates to the first-class targets of go1.18. Since GoReleaser v1.9.
    # - go_first_class: evaluates to latest stable go first-class targets, currently same as 1.18. Since GoReleaser v1.9.

[caarlos0]

Would it means that linux_amd64 is an invalid target name?

yes, its usually better to use the goos etc properties instead to build the targets matrix.

optional

they are optional based on which goos/goarch they are targetting, docs should be clearer probably..

the special values there (first class stuff) comes from here: https://github.com/golang/go/wiki/PortingPolicy#first-class-ports