-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
✨ Add scaffolding for the webhook test suite (go/v3-alpha) #1710
Conversation
Hi @prafull01. Thanks for your PR. I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
aee67b1
to
1b7353e
Compare
pkg/plugin/v3/scaffolds/internal/templates/config/api/webhook_suite.go
Outdated
Show resolved
Hide resolved
/ok-to-test |
1b7353e
to
880f74a
Compare
/test pull-kubebuilder-e2e-k8s-1-15-3 |
pkg/plugin/v3/scaffolds/internal/templates/config/api/webhook_suite.go
Outdated
Show resolved
Hide resolved
pkg/plugin/v3/scaffolds/internal/templates/config/api/webhook_suite.go
Outdated
Show resolved
Hide resolved
pkg/plugin/v3/scaffolds/internal/templates/config/api/webhook_suite.go
Outdated
Show resolved
Hide resolved
pkg/plugin/v3/scaffolds/internal/templates/config/api/webhook_suite.go
Outdated
Show resolved
Hide resolved
pkg/plugin/v3/scaffolds/internal/templates/config/api/webhook_suite.go
Outdated
Show resolved
Hide resolved
pkg/plugin/v3/scaffolds/internal/templates/config/api/webhook_suite.go
Outdated
Show resolved
Hide resolved
pkg/plugin/v3/scaffolds/internal/templates/config/api/webhook_suite.go
Outdated
Show resolved
Hide resolved
9ad18c4
to
7f94799
Compare
7f94799
to
ea18f59
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @prafull01,
Really thank you for your contribution. It shows OK for me 👍
/approve
ea18f59
to
7698b1f
Compare
pkg/plugin/v3/scaffolds/internal/templates/config/api/webhook_suitetest.go
Outdated
Show resolved
Hide resolved
pkg/plugin/v3/scaffolds/internal/templates/config/api/webhook_suitetest.go
Outdated
Show resolved
Hide resolved
pkg/plugin/v3/scaffolds/internal/templates/config/api/webhook_suitetest.go
Outdated
Show resolved
Hide resolved
var err error | ||
cfg, err = testEnv.Start() | ||
Expect(err).ToNot(HaveOccurred()) | ||
Expect(cfg).ToNot(BeNil()) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why would this be nil? Potentially unnecessary bloat.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The cfg is nill in the failure cases. See: https://github.com/kubernetes-sigs/controller-runtime/blob/v0.6.3/pkg/envtest/server.go#L192
It is such as we have for the controllers. See: https://github.com/kubernetes-sigs/kubebuilder/blob/master/pkg/plugin/v3/scaffolds/internal/templates/config/controller/controller_suitetest.go#L154-L157
Theoretically, the error will not be nil so we would not need to test the cfg. However, it might have a scenario that is not properly handled so, in POV we should not change it and keep it as it is done in the suite_test for the controller.
pkg/plugin/v3/scaffolds/internal/templates/config/api/webhook_suitetest.go
Show resolved
Hide resolved
pkg/plugin/v3/scaffolds/internal/templates/config/api/webhook_suitetest.go
Show resolved
Hide resolved
pkg/plugin/v3/scaffolds/internal/templates/config/api/webhook_suitetest.go
Show resolved
Hide resolved
pkg/plugin/v3/scaffolds/internal/templates/config/api/webhook_suitetest.go
Show resolved
Hide resolved
[]Reporter{printer.NewlineReporter{}}) | ||
} | ||
|
||
var _ = BeforeSuite(func(done Done) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I might use the form without done given that done isn't being used.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree with that. However, the same is applied to https://github.com/kubernetes-sigs/kubebuilder/blob/master/pkg/plugin/v3/scaffolds/internal/templates/config/controller/controller_suitetest.go#L146. So, I think it might better be addressed in a follow up for both scenarios.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For reference, many of my comments here came from my thoughts when I was "cleaning up" the kb generated code that's setup elsewhere. Of course, everyone is entitled to their own code style and opinions. I thought I'd raise the bits I found to be awkward. I agree with consistent style. If you agree that it's awkward, a followup to address all cases sounds good.
}, | ||
} | ||
|
||
var err error |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Rather that mutating the same error every time, it's probably more idiomatic to use the form
foo, err := Func()
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- 1 for that 🥇
However, IMO it needs to be addressed in https://github.com/kubernetes-sigs/kubebuilder/blob/master/pkg/plugin/v3/scaffolds/internal/templates/config/controller/controller_suitetest.go#L154 as well. So, I think it would be better addressed in a follow up for both.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You are not mutating an error, you are re-assigning it. The current approach only allocates memory once while the other needs to allocate memory for every function so I don't think it is that good of an idea.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
HI @Adirio,
The community suggestion was :
Replace
var err error
cfg, err = testEnv.Start()
With
cfg, err := testEnv.Start()
In order to keep the simplicity in the code which shows totally fine for me.
However, the most important in my POV is to keep both suite tests for controller and webhook as closer as possible, so, in this way a new issue was tracked to address this nit in both : #1733
So, if you do not agree with the above change could you please add your inputs to #1733?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1 for not mutating the same error every time.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The proposed changed is more idiomatic but doesn't change the behavior you mentioned. You are still using the same err
variable and assigning different values to it. You are not actually mutating an error in any of the two cases. You just declare the variable the first time you use it instead of explicitly declaring the variable. So +1 for the change, but the explanation lead me to thinking the change you suggested was different.
overall a very useful example to help users get started testing webhooks. |
pkg/plugin/v3/scaffolds/internal/templates/config/api/webhook_suitetest.go
Show resolved
Hide resolved
7698b1f
to
309f134
Compare
// wait for the webhook server to get ready | ||
dialer := &net.Dialer{Timeout: time.Second} | ||
addrPort := fmt.Sprintf("%s:%s", webhookInstallOptions.LocalServingHost, webhookInstallOptions.LocalServingPort) | ||
Eventually(func() error { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Suggestion:
Consider relying on https://godoc.org/k8s.io/apimachinery/pkg/util/wait#ExponentialBackoff. In my controller, i extracted all this setup logic into a more fully featured "envtest+manager" abstraction. It would be nice to have this logic less reliant on gomega and instead rely on apimachinery. If KB were to ever make an abstraction like this (to avoid this code in every suite_test), you wouldn't want that code to rely on gomega.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Really thank you for your input. I think that the best way for it be addressed would be might via a follow-up PR. So, WDYT about after it gets merged you push a PR with your suggestion? Then, it might clarify better as well as your thoughts.
f899277
to
bbaf557
Compare
After spoke with @estroz, it might be better we use |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/lgtm
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: Adirio, camilamacedo86, prafull01 The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
bbaf557
to
c09442c
Compare
It was rebased with the master because of this loses the @Adirio lgtm /lgtm |
Description
Added the webhook suite generation while creating the webhooks using the envtest.
Motivation:
The webhook envtest suite setup requires setting up quite a things which would be useful for users to be programmatically generated as the envtest has supported webhook testing.
Fixes #1707