Creating a Docker image using a `go_binary` artifact causes a `CycleException`

[agoblet]

Describe the bug
In the past there were cyclic dependency issues when packaging a go_binary (#17236). This issue has been resolved now. But a similar problem is shown when using a docker_image target.

When COPYing a go_binary artifact into a docker_image, and running pants package, it will detect a cyclic dependency in some cases. This is highlighted in a minimal example in this repository: https://github.com/agoblet/pants-go-cyclic-dependency

I think that the problem is that the issue linked above works around the cyclic dependency. On a Pants-level, this cyclic dependency is still there, and the packaging of a docker_image does not know how to work around it.

Pants version
2.21.0

OS
MacOS (M3)

[tdyas]

From my initial investigation, this appears to be related to the fact that an external test (xtest) is being used here. The Pants Go backend does not currently model xtests as separate targets and so Pants treats the base package imports and the xtest imports as both generating edges in the dependency graph for the base package.

There would not be a dependency cycle if xtest packages were modeled as their own (automatically generated) targets because the logic_test xtest would rely on logic (which does not import utils) and also rely on utils (which does import logic but not the logic_test xtest part of logic).

The Go backend currently has workarounds for the fact that xtests are modeled as being associated with the same target as their base package. That is why you can build a go_binary target just fine. The Docker backend does not have those work arounds (nor should it, this needs to be solved in the Go backend).

[tdyas]

Relevant prior discussion is in #17236.

[tdyas]

I tried briefly experimenting again with adding a generated target for xtest packages, but ran into a rule graph cycle since the rule processing a go_package target to generate a target for the xtest needs the go_mod target to be fully processed first as a target generator. So the preferred solution is not easy to do since Pants does not currently have a concept of dependencies between different target generator's rules.

So I don't see this issue being solved any time soon, absent some fundamental rethink of how target generation works or finding another way to represent xtests affirmativly in the build graph.

[aleclerc-cio]

I think I'm hitting the same issue but specifically with golangci-lint, which i would have expected to use the same concept. I can compile/build packages, but if I add golangci-lint to the backends I start getting cyclical errors