Bumping the version of Ginkgo gives go conflicting package error

[Ankitasw]

We are currently using ginkgo version 2.8.1 in the Cluster API Provider for AWS project, but tried bumping the version to 2.8.3 and got the below error

"Running error: context loading failed: failed to load packages: failed to load with go/packages: internal error: go list gives conflicting information for package sigs.k8s.io/cluster-api-provider-aws/v2/api/v1beta2 [sigs.k8s.io/cluster-api-provider-aws/v2/api/v1beta2.test]"

Surprisingly this error comes only when we try to bump the version. Otherwise we never get this error in our codebase.
Refer this PR for more details.

I see no dependencies changed recently for ginkgo. Has anyone else come across this issue?
Or maybe it's a golang issue?

[Ankitasw]

We are also getting similar error when bumping Gingko to v2.8.3 in Cluster API project. kubernetes-sigs/cluster-api#8143

[onsi]

hey @Ankitasw - can you try bumping to 2.8.2 to see if the same issue occurs? 2.8.2 introduced a tools.go file to force go to also fetch ginkgo's cli dependencies. 2.8.3 then bumped some other dependencies - i'd like to figure out which change is potentially causing this.

[Ankitasw]

Thanks for the quick response @onsi
I tried with 2.8.2, and getting same error. We add ginkgo dependency in our own repo's tools.go but with this bump I even tried to remove it, but still getting the same error.

[onsi]

weird ☹️ - my mental model for go modules is not very strong so i'm not sure why this is happening t. i can try to reproduce this over the weekend to debug it.

for now, some things to explore:

• can you run go mod tidy after updating to 2.8.2 and remind ginkgo from your tools.go file? can you share the go.mod and go.sum before you bump to 2.8.2/fix tools and after?
• is there more to the error you can share?
• does go mod list show anything interesting?

[Ankitasw]

weird ☹️ - my mental model for go modules is not very strong so i'm not sure why this is happening.

I understand, even I don't understand much around it.

i can try to reproduce this over the weekend to debug it.

Thankyou so much 🙇‍♀️

So there are two go.mod file in our repo. One is at the root project level, and another one at /hack/tools where tools.go recide.

can you run go mod tidy after updating to 2.8.2 and remind ginkgo from your tools.go file? can you share the go.mod and go.sum before you bump to 2.8.2/fix tools and after?

This is the root go.mod and go.sum files with v2.8.1. This is the go.mod and go.sum for tools.go.
This is the root go.mod and go.sum files with v2.8.2. This is the go.mod and go.sum for tools.go after removing ginkgo from tools.go.
I did run go mod tidy on both levels.

is there more to the error you can share?

There is no more to the error unfortunately 😞 but this error if thrown by golangci-lint only, and not while go build.

does go mod list show anything interesting?

Uhmm.. do you mean go list to check the deps? It gave this output from which I am not able to make out anything 😕 . Let me know if you suspect something there.

Please let me know if you need any other info.

[Skarlso]

It's ginkgo's new way of being imported. It messed up the tools package chain. An "easy" fix is for golangci-lint not to lint tools. So remove the tools build tag.

[Skarlso]

Oh, I see, I'm tired so I thought this is the cluster-api issue

Okay, so ginkgo folks, the move to tools magic broke the link chain in tools. Maybe it's okay, and we just remove the tools build tag from golangci-lint to not lint stuff. But since this is a breaking change in downward products, we would prefer it to happen in a major version instead of a patch version. :)

[onsi]

is there anything i can do on my end to unbreak it? i'd sooner roll this back than bump to 3.0!

or to put it differently: do you understand (and can you explain) why this is breaking?

is it because i'm using a tools build tag? if i renamed it to something else (say... cheesecake) would this magically work?

[onsi]

(which i'd be happy to do if you're up for bumping to a sha so we can see if it helps)

[onsi]

in case y'all want to try this - i've dropped the tools build tag in favor of ginkgoclidependencies

this is on the latest sha:
a8bb39a

please give it at ry and let me know if it fixes this weird linter issue...

[Skarlso]

Sorry @onsi it was super late so I went to bad. Most likely the break comes from a circular dependency appearing if both things use the same build tag somehow. I'm not a 100% sure yet why but I suspect it's a combination of things. It would be enough if you dropped it or used a different tag. Something like #ginkgo which is more specific to this library. However it's also a question if we should lint tools at all maybe.

I have to figure out some more approaches. Also I'm super thankful for your support! :)

[onsi]

no worries and happy to help!

the latest commit sha uses ginkgoclidependencies instead of tools - if y'all can give it a try next week and confirm that it works i'll cut a new release

[Skarlso]

Thanks, great! Will do that!

[Ankitasw]

@onsi The changes works fine with above commit sha.
cc @Skarlso

[Skarlso]

Fantastic! :)

[Ankitasw]

Thanks for pointing in right direction @Skarlso 🙂

[Skarlso]

My pleasure. 😊 and thanks @onsi for the rapid responses on this issue. 🙂

[Ankitasw]

@onsi Thanks for the quick look at this issue, so could there be a possibility to make a new release with this change by this week?
I would close this issue post release.

[sbueringer]

Thx folks for investigating this issue!

[onsi]

😮‍💨 glad that worked! should cut a release at some point today.

[onsi]

2.8.4 is out now - please take a look and let me know if y'all are set :)

[Ankitasw]

Thanks for being so proactive @onsi 🙂

[sbueringer]

Look good: kubernetes-sigs/cluster-api#8143

Thx for the quick fix!

[onsi]

woot! 🎉