-
Notifications
You must be signed in to change notification settings - Fork 8.3k
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
Rework Ginkgo usage #9522
Rework Ginkgo usage #9522
Conversation
@dud225: This issue is currently awaiting triage. If Ingress contributors determines this is a relevant issue, they will accept it by applying the The 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. |
Hi @dud225. Thanks for your PR. I'm waiting for a kubernetes 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. |
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.
Thanks, I'm going to trigger the test, but I haven't looked at the specific changes yet.
/ok-to-test
@@ -19,12 +20,7 @@ controller: | |||
periodSeconds: 1 | |||
service: | |||
type: NodePort | |||
electionID: ingress-controller-leader | |||
ingressClassResource: |
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.
any reason to remove this? IIRC on tests this may generate some conflict as multiple ingresses may try to reconcile it :)
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.
Ok I see you remove the charts after it. Maybe we should always remove charts and add this as part of AfterEach :)
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.
any reason to remove this?
as this chart is expected to run alone (Serial), there is no need to disable the non-namespaced objects
Maybe we should always remove charts and add this as part of AfterEach :)
TBH I was thinking about it but finally forgo because that would slightly increase the execution time of the general case where the removal of the ns is enough.
But I'm still leaning towards this idea as this would help to not fall into the trap when the removal of the chart deployment is necessary. Let me know what you think.
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 just read your other comment where you approve the idea ;)
@dud225 this is an amazing change, thank you very much!! We really need a bunch on improvements on how we use ginkgo. This one is approved to me, as soon as you can just answer about the uninstallChart as part of the AfterEach, if it does make sense, and if it does, push a new commit we can merge it. /approve |
Thanks for the compliment. |
Hello
In addition there are different flavour of this particular job targetting the last Kubernetes versions which all running fine. So I think that this PR can be merged. |
Currently Ginkgo is launched multiple times with different options to accomodate various use-cases. In particular, some specs needs to be run sequentially because non-namespaced objects are created that conflicts with concurent Helm deployments. However Ginkgo is able to handle such cases natively, in particular specs that needs to be run sequentially are supported (Serial spec). This commit marks the specs that needs to be run sequentially as Serial specs and runs the whole test suite from a single Ginkgo invocation. As a result, a single JUnit report is now generated. Signed-off-by: Hervé Werner <[email protected]>
Error getting ConfigMap "$NAMESPACE/tcp-services": no object matching key "$NAMESPACE/tcp-services" in local store Signed-off-by: Hervé Werner <[email protected]>
Executing "go get" changes the go.mod & go.sum files which is not the case of "go install". Signed-off-by: Hervé Werner <[email protected]>
Signed-off-by: Hervé Werner <[email protected]>
…an update Signed-off-by: Hervé Werner <[email protected]>
/lgtm |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: dud225, rikatz 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 |
Currently Ginkgo is launched multiple times with different options to
accomodate various use-cases. In particular, some specs needs to be run
sequentially because non-namespaced objects are created that conflicts with
concurent Helm deployments. However Ginkgo is able to handle such cases
natively, in particular specs that needs to be run sequentially are
supported (Serial spec).
This change marks the specs that needs to be run sequentially as Serial
specs and runs the whole test suite from a single Ginkgo invocation. As a
result, a single JUnit report is now generated.
As part of this change, the following controller error in the TopologyHints
test is fixed:
In addition, "go get" invocations are being replaced by "go install" because
the former performs changes in the go.sum and go.mod files.