Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Assertions in scaffolded suite_test.go BeforeSuite are not caught #2328

Closed
armsnyder opened this issue Sep 6, 2021 · 1 comment · Fixed by #2345
Closed

Assertions in scaffolded suite_test.go BeforeSuite are not caught #2328

armsnyder opened this issue Sep 6, 2021 · 1 comment · Fixed by #2345
Labels
kind/bug Categorizes issue or PR as related to a bug. triage/accepted Indicates an issue or PR is ready to be actively worked on.

Comments

@armsnyder
Copy link
Contributor

armsnyder commented Sep 6, 2021

What broke? What's expected?

This code at the bottom of a scaffolded BeforeSuite function in controllers/suite_test.go has a bug:

go func() {
	err = k8sManager.Start(ctrl.SetupSignalHandler())
	Expect(err).ToNot(HaveOccurred())
}()

Ginkgo does not work in new goroutines without adding a defer GinkgoRecover() line. When this assertion fails you get this error:

panic: 
Your test failed.
Ginkgo panics to prevent subsequent assertions from running.
Normally Ginkgo rescues this panic so you shouldn't see it.

But, if you make an assertion in a goroutine, Ginkgo can't capture the panic.
To circumvent this, you should call

        defer GinkgoRecover()

at the top of the goroutine that caused this panic.

As a result the error message cannot be inspected.

Reproducing this issue

No response

KubeBuilder (CLI) Version

Version: main.version{KubeBuilderVersion:"3.1.0", KubernetesVendor:"unknown", GitCommit:"92e0349ca7334a0a8e5e499da4fb077eb524e94a", BuildDate:"2021-05-29T05:57:53+01:00", GoOs:"darwin", GoArch:"amd64"}

PROJECT version

3

Plugin versions

layout:
- go.kubebuilder.io/v3

Other versions

No response

Extra Labels

No response

@armsnyder armsnyder added the kind/bug Categorizes issue or PR as related to a bug. label Sep 6, 2021
@armsnyder
Copy link
Contributor Author

Seems to have been resolved by #2302, but there are still a couple places missing a defer GinkgoRecover() call. I'm getting a PR ready.

@camilamacedo86 camilamacedo86 added the triage/accepted Indicates an issue or PR is ready to be actively worked on. label Sep 21, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/bug Categorizes issue or PR as related to a bug. triage/accepted Indicates an issue or PR is ready to be actively worked on.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants