Need a way to pass flags to `go build` other than GOFLAGS

[thockin]

xref #69

I know this issue is YEARS old but I was dismayed today to realize that this does not work if you have more than one flag in GOFLAGS. In my case I want to pass 2 or 3 ldflags, depending on the user and context. I can build up a string of those, put since their are spaces in the string, GOFLAGS does not work.

Editing YAML on the fly is janky to the max.

[imjasonh]

wdyt about

ko build ./cmd/foo \
  -goflag="-ldflags=-X=main.version=1.2.3" \
  -goflag="-ldflags=-X=main.commit=abcdef" \
  ...

?

I don't love it, but I also don't love making folks edit YAML (ever) and I don't love only being able to pass one goflag otherwise.

Out of curiosity, what multiple ldflags are you passing? If you're using them to set consts at build time, can you get by without doing that?

[imjasonh]

fwiw this also works (and is also gross):

GOFLAGS="-ldflags=-X=main.version=1.2.3 -ldflags=-X=main.commit=abcdef" \
  ko build ./cmd/foo

[imjasonh]

#1676 demonstrates this works and updates the docs which incorrectly said it didn't.

edit: looking closer, it actually demonstrates this doesn't work, my bad

This is a limitation of how Go handles GOFLAGS:

$ GOFLAGS="-ldflags=-X=main.version=foo -ldflags=-X=main.anotherThing=blah" go run ./test                             
2026/06/03 12:48:14 version = version
2026/06/03 12:48:14 anotherThing = blah

[thockin]

There's a subtle and weird quoted-string parser for GOFLAGS, I have discovered.

This fails for good reason:
GOFLAGS="-ldflags=-X=foo=foo -X=bar=bar"
...becomes:
[ "go", "build", "-ldflags=-X=foo=foo", "-X=bar=bar" ]
...where -X is passed to go build

We can try:
GOFLAGS="-ldflags='-X=foo=foo -X=bar=bar'"
...but that becomes
[ "go", "build", "-ldflags='-X=foo=foo", "-X=bar=bar'" ]
...which is unfortunate.

Go does some quote handling, but:
GOFLAGS='-ldflags="-X=foo=foo -X=bar=bar"'
...still becomes:
[ "go", "build", "-ldflags="-X=foo=foo", "-X=bar=bar"" ]
...which is surprising.

We can try what you wrote:
GOFLAGS="-ldflags=-X=foo=foo -ldflags=-X=bar=bar"
...but go just takes the last value of that flag rather than the accumulation.

What does work is:
GOFLAGS='"-ldflags=-X=foo=foo -X=bar=bar"'
...with the WHOLE flag quoted.

[thockin]

So I have a workaround. IMO ko build should be a flag-compatible drop-in for (or superset of) go build. Or it should handle something like ko build <koflags> -- <go build flags>

[imjasonh]

IMO ko build should be a flag-compatible drop-in for (or superset of) go build.

I don't agree, but I can see where you're coming from.

go has a bunch of flags, and most of them aren't commonly used. Some already conflict with ko build flags that mean different things (-v, -tags).

The YAML config (for better or worse) was meant to be the place to configure all these options, away from the CLI surface, which gets to stay minimal as a result. That strategy may not work in practice, but that was the intention at least.

Or it should handle something like ko build <koflags> -- <go build flags>

We do that today for ko apply (e.g., ko apply <koflags> -- <kubectl flags>) and it works ...okay, but then what do we do when we want to compose ko flags, kubectl flags, and go flags all together? What if they collide? This gets messy fast.

Ultimately, the goal of ko is to support the simplest ~60% of uses really well, and make some portion of the remaining 40% doable. Some things aren't possible at all in ko, and when that happens you can fallback to a Dockerfile, bash script, etc.

The use case for setting arbitrary Go flags is complicated enough to sit outside the 60% IMO.

[thockin]

I can buy the argument that many/most static flags should be in YAML for UX (even if it obscures them). The trouble is for flags which might vary based on something more dynamic than that. For example, setting an ldflags based on git tags or based on make variables. E.g. make release VERSION=v1.2.3" will use a handful of flags that are different from make debug` - adding a version, stripping symbols etc.

Please don't make me edit YAML on the fly :)

[imjasonh]

setting an ldflags based on git tags

can you get by without doing that?

:)

Please don't make me edit YAML on the fly :)

If I could I'd undo the whole goreleaser-inspired YAML thing entirely, believe me. 😆

Maybe I should step back and ask what you're trying to achieve? Is there a specific example of where you're calling ko today that we can improve?

[thockin]

can you get by without doing that?

Not unless you have a simpler way to inject a version string into a binary at compile time?

But also debug/vs prod builds (from k8s):

  if [[ "${DBG:-}" == 1 ]]; then                                                                                                                                                       
      # Debugging - disable optimizations and inlining and trimPath
      gogcflags="${gogcflags} all=-N -l" 
  else
      # Not debugging - disable symbols and DWARF, trim embedded paths
      goldflags="${goldflags} -s -w"
      goflags+=("-trimpath")
      # build non-debug binaries with "grpcnotrace" tag to avoid x/net trace usage and enable dead code elimination
      grpcnotrace=",grpcnotrace"
  fi

[imjasonh]

Not unless you have a simpler way to inject a version string into a binary at compile time?

If your .git is available and git is available, go build will embed your commit(+dirty) and the module version (v1.2.3), without having to go through the ldflags backdoor.

[thockin]

Commit and module version != release version

Actually as I write that - what is module version? "v2"? If not, where is it getting some other version?

[imjasonh]

It's v1.2.3 according to Go, or the pseudoversion (v0.0.0-<date>-<commit>)

[thockin]

I meant: how do I tell it "v1.2.3" - I tried adding a tag and it did not use it.

[imjasonh]

It seems to only populate that when you do something like go install example.com/cmd/foo@v1.2.3, and not, for example, when you're in a local clone of the source. In those cases the main version string will be (devel) :(

I can think of a couple terrible hacks to make it work, but ldflags is probably the easiest way to do what (I assume) you're trying to do, unfortunately.

Back on topic, it sounds like you've found a workaround, and maybe this just means we should add support for ko build -ldflags at least. Would that be sufficient for your case?

[thockin]

An ldflags flag would be the most natural, IMO. Or just document the trick with double quotes in GOFLAGS?