## What this PR does / why we need it:
In https://github.com/kubernetes/ingress-nginx/issues/5651 there was a
request to throw an error when there are two ingresses defining the same
host and path, which was implemented as part of the validation webhook.
Despite of this there are clear rules on the ingress controller that
describes what the controller would do in [such situation (the oldest
rule wins)](https://github.com/kubernetes/ingress-nginx/blob/main/docs/how-it-works.md?plain=1#L27)
Some users are relying on this validation behaviour to prevent
misconfigurations, but there are use cases where allowing it, maybe
temporarily, is helpful. Those use cases includes:
- Splitting large ingresses objects in smaller ones https://github.com/kubernetes/ingress-nginx/issues/10820
- Moving ingress objects between namespaces without downtime (like when you transfer an ingress from team A that owns namespace A to team B that owns namespace B) https://github.com/kubernetes/ingress-nginx/issues/10090
<!--- What types of changes does your code introduce? Put an `x` in all the boxes that apply: -->
## Types of changes
- [ ] Bug fix (non-breaking change which fixes an issue)
- [X] New feature (non-breaking change which adds functionality)
- [ ] CVE Report (Scanner found CVE and adding report)
- [ ] Breaking change (fix or feature that would cause existing functionality to change)
- [ ] Documentation only
## Which issue/s this PR fixes
It might help with #10820
<!--- Please describe in detail how you tested your changes. -->
<!--- Include details of your testing environment, and the tests you ran to -->
<!--- see how your change affects other areas of the code, etc. -->
## How Has This Been Tested?
building an image and testing it in a local cluster, will update later
with some real life scenarios
<!--- Go over all the following points, and put an `x` in all the boxes that apply. -->
<!--- If you're unsure about any of these, don't hesitate to ask. We're here to help! -->
## Checklist:
- [X] My change requires a change to the documentation.
- [ ] I have updated the documentation accordingly.
- [X] I've read the [CONTRIBUTION](https://github.com/kubernetes/ingress-nginx/blob/main/CONTRIBUTING.md) guide
- [X] I have added unit and/or e2e tests to cover my changes.
- [X] All new and existing tests passed.
Change-Id: I9d4124d1c36876b06d63100cd10988eaf2f41db9
* Rework Ginkgo usage
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 <dud225@hotmail.com>
* Fix controller error in test
Error getting ConfigMap "$NAMESPACE/tcp-services": no object matching key "$NAMESPACE/tcp-services" in local store
Signed-off-by: Hervé Werner <dud225@hotmail.com>
* Replace "go get" invocations by "go install"
Executing "go get" changes the go.mod & go.sum files which is not the
case of "go install".
Signed-off-by: Hervé Werner <dud225@hotmail.com>
* Always clean out the Helm deployment
Signed-off-by: Hervé Werner <dud225@hotmail.com>
* Add E2E test to verify that changes to one or more configmap trigger an update
Signed-off-by: Hervé Werner <dud225@hotmail.com>
---------
Signed-off-by: Hervé Werner <dud225@hotmail.com>
* update path type validation to be false and update e2e test scripts
Signed-off-by: James Strong <strong.james.e@gmail.com>
* update to make tests clear
Signed-off-by: James Strong <strong.james.e@gmail.com>
* update test params
Signed-off-by: James Strong <strong.james.e@gmail.com>
* Adding else per pr comments
Signed-off-by: James Strong <james.strong@chainguard.dev>
---------
Signed-off-by: James Strong <strong.james.e@gmail.com>
Signed-off-by: James Strong <james.strong@chainguard.dev>
