controller-gen Does Not Respect GOFLAGS (-tags) During Build

[camilamacedo86]

controller-gen currently does not respect/support Go build tags (-tags) passed via the GOFLAGS environment variable. This creates issues when working with code that relies on build constraints.

When trying to build using:

export GOFLAGS="-tags=mymodule"
controller-gen object paths=./apis/...

For example, the tags provided are not passed to the build.
Therefore, failures might occur for projects that rely on C-based packages.

Expected Behavior

• controller-gen should respect the GOFLAGS environment variable.
• Build tags should be properly applied when processing Go files.

Also, it seems related to: #871

[sbueringer]

For example, the tags provided are not passed to the build.

Which build? :)

[camilamacedo86]

Hi @sbueringer

The issue arises when working with Go Build Cache Optimization (GCO) enabled, where the controller-gen command fails due to missing build tags. Specifically, it does not respect the GOFLAGS environment variable that includes -tags, which is matter for projects that rely on conditional compilation.

For example, when running:

/home/runner/go/bin/controller-gen-v0.17.2 object:headerFile="hack/boilerplate.go.txt" paths="./..."
It results in the following error:

-: build constraints exclude all Go files in /home/runner/go/pkg/mod/github.com/proglottis/[email protected]
Error: not all generators ran successfully
run `controller-gen object:headerFile=hack/boilerplate.go.txt paths=./... -w` to see all available markers, or `controller-gen object:headerFile=hack/boilerplate.go.txt paths=./... -h` for usage
make: *** [Makefile:151: generate] Error 1

This issue occurs because controller-gen does not propagate build tags to the Go toolchain when invoked. As a result, projects that depend on C-based dependencies, such as containers/image, fail to compile when required build constraints are not met.

To resolve this, I need to pass a specific build tag (GO_BUILD_TAGS), similar to how it can be done with golangci-lint:

golangci-lint run --build-tags $(GO_BUILD_TAGS)

Expected Behavior:

• controller-gen should respect the GOFLAGS environment variable and correctly apply build tags.
• It should function similarly to other tools like golangci-lint, which properly recognize and pass -tags to the Go compiler.

Let me know if any additional clarification is needed!

[sbueringer]

Thx for the context. If someone has an idea on how to fix it, feel free to open a PR

[perdasilva]

@sbueringer I think the way to fix it would be to pass configuration to LoadRootsWithConfig by modifying ForRoots around here. I'd be happy to put together the PR. What I'd like to know first is what would be the preferred way to instruct controller-gen to do that. Would something like what @camilamacedo86 suggested:

controller-gen --build-tags <values> ... be the right way?

Alternatives might be to consider GOFLAGS or take input from some env var like GO_BUILD_TAGS. But these options might have a large blast radius or sudden onset of unexpected behavior in some projects.

[sbueringer]

I think at this point of the project it would make sense that folks have to explicitly opt-in.

Regarding the exact way to do that, would be good in general to be consistent with how similar tools are doing that.

@JoelSpeed opinions from your side?

[JoelSpeed]

I think at this point of the project it would make sense that folks have to explicitly opt-in.

Agreed

Regarding the exact way to do that, would be good in general to be consistent with how similar tools are doing that.

As far as I can tell, you'd have exactly the same issue with any Gengo based generator. The Parser loads with build tags passed into it based on this configuration.

But if you check the way this is done in, for example, deepcopy-gen they just pass the standard ignore_autogenerated tag, and there's no way for you to override the build tags.

We may want to raise the issue with the gengo folks and get their opinion as well

I could see us following a build-tags pattern, but we probably want to explore getting the same into gengo based generators simultaneously. @camilamacedo86 Do you happen to have tried any of the other gengo based generators to see if this works for them?

[camilamacedo86]

Hi @JoelSpeed

That should occur with all. :(

/home/runner/go/bin/controller-gen-v0.17.2 crd paths="./api/v1/..." output:crd:artifacts:config=crd_work_dir
/home/runner/go/bin/controller-gen-v0.17.2 rbac:roleName=manager-role paths="./internal/operator-controller/..." output:rbac:artifacts:config=config/base/operator-controller/rbac
-: build constraints exclude all Go files in /home/runner/go/pkg/mod/github.com/proglottis/[email protected]
run `controller-gen rbac:roleName=manager-role paths=./internal/operator-controller/... output:rbac:artifacts:config=config/base/operator-controller/rbac -w` to see all available markers, or `controller-gen rbac:roleName=manager-role paths=./internal/operator-controller/... output:rbac:artifacts:config=config/base/operator-controller/rbac -h` for usage

In our case, we found two possible workarounds to overcome this issue:

• Isolate all markers into separate files so they do not cause issues.
  OR
• Downgrade [email protected] since it's related to our specific case, replacing it with an older version.

What about we just ensure that controller-gen supports GOFLAGS? Or if we do not use the GOFLAGS, allow the user to explicitly say it for controller-gen via a specific ENV VAR like GO_BUILD_CONTROLLER_TOOLS_FLAGS?

This would allow users to dynamically pass build tags like containers_image_openpgp without modifying code or structuring files differently. Something like:

        // Default build tags
	buildTags := []string{"ignore_autogenerated"}

	// Read GOFLAGS for additional tags
	if goFlags := os.Getenv("GOFLAGS"); goFlags != "" {
		for _, flag := range strings.Fields(goFlags) {
			if strings.HasPrefix(flag, "-tags=") {
				// Extract and append custom tags
				tags := strings.TrimPrefix(flag, "-tags=")
				buildTags = append(buildTags, strings.Split(tags, ",")...)
			}
		}
	}

	// Add "-tags" argument to BuildFlags
	l.cfg.BuildFlags = append(l.cfg.BuildFlags, "-tags", strings.Join(buildTags, ","))

[joelanford]

My first instinct if we want to preserve existing functionality would be to add a --build-tags flag (or whatever style suits controller-gen's semi-esoteric CLI structure).

Would we want it to be a global setting, or something passed individually to each generator? My feeling there is to make it a global setting only, which seems like it would cover basically all of the uses cases of this, especially given that controller-gen has been around for years with no one running into build tags issues before.

And if it turns out that we are asked to support per-generator build tags, that's always something that could be considered later.

[joelanford]

@tmshort and I put each put together PRs that add support in two different ways.

• An actual flag: ✨ Add --build-tags flag #1161
• Inline with the other controller-gen generate args: ✨ Add buildTag support #1160

Opinions?

[JoelSpeed]

I'm leaning towards a flagged approach.

Using a marker has the issue that the marker could itself, be excluded from the build process by virtue of being within a file that has a particular build tag, right? IIUC, we have to parse the environment first to find the files marked, and then re-parse to load the correct build tags? Does the default parse include all files, or only those without build tags?

If we were generating multiple different versions (which is the common use of build tags right?), I'm not sure how I would be able to say "generate this version and then generate this version" when the input is a file within the code being generated, where I could easily see how to vary the flag inputs

[joelanford]

@JoelSpeed I might be misunderstanding Todd's PR, but I think marker in that context is a command line marker, not a file-based comment marker.

So with my PR, one would invoke this way:

controller-gen --build-tags=tag1,tag2 crd ...

And Todd's PR, one would invoke something like this (@tmshort, correct me if I got the syntax wrong):

controller-gen crd ... buildTag=tag1,tag2

[tmshort]

@joelanford's invocation is correct, although there can be multiple buildTags supported:

controller-gen crd buildTag=tag1 buildTag=tag2 ...

Yes, code refers to these things as "markers", and are registered (code-wise) in the same way, AFAICT.

But it's probably best to think of it as a generic option closer to the path option than generators (e.g. crd) or additional "markers".