feat: egress e2e test #1289
Open
feat: egress e2e test #1289
+508
−6
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
kyma-bot
added
cla: yes
Ressetkk
force-pushed
the
feat/egress-e2e
branch
from
9e1a147 to
1979a40
Compare
Ressetkk
force-pushed
the
feat/egress-e2e
branch
from
1979a40 to
fa40087
Compare
kubicar
previously approved these changes
Feb 10, 2025
There was a problem hiding this comment.
I like your approach to e2e topic. This will simplify writing e2e tests, to not make a lot of abstraction without need to do that.
Spotted things to improve:
- during second implementation of e2e in this approach, generic for infrastructure management task functions should be divided to separate packages.
Ressetkk
force-pushed
the
feat/egress-e2e
branch
from
fa40087 to
3182397
Compare
|
New changes are detected. LGTM label has been removed. |
* add simple e2e test for egress TLS gateway This tests implements the official Istio egress tutorial with TLS passthrough. Note that this test will work only on a cluster that supports NetworkPolicy. For local cluster only kind supports NetworkPolicies.
Ressetkk
force-pushed
the
feat/egress-e2e
branch
from
3182397 to
f47f259
Compare
| @@ -0,0 +1,56 @@ | |||
| # End-to-end tests | |||
There was a problem hiding this comment.
Suggested change
| # End-to-end tests | |
| # End-to-End Tests |
Comment on lines
+3
to
+4
| This directory contains definitions and implementations of end-to-end tests for istio operator. | ||
| These tests are for testing the connectivity of istio components to external services, implementing user scenarios. |
There was a problem hiding this comment.
Suggested change
| This directory contains definitions and implementations of end-to-end tests for istio operator. | |
| These tests are for testing the connectivity of istio components to external services, implementing user scenarios. | |
| This directory contains definitions and implementations of end-to-end tests for Istio Operator. | |
| These tests verify the connectivity of Istio components to external services, implementing user scenarios. |
| This directory contains definitions and implementations of end-to-end tests for istio operator. | ||
| These tests are for testing the connectivity of istio components to external services, implementing user scenarios. | ||
|
|
||
| ## Running end-to-end tests |
There was a problem hiding this comment.
Suggested change
| ## Running end-to-end tests | |
| ## Running End-to-End Tests |
|
|
||
| ## Running end-to-end tests | ||
|
|
||
| E2E tests run against cluster that is set up as active in your `KUBECONFIG` file. If you want to change the target, |
There was a problem hiding this comment.
Suggested change
| E2E tests run against cluster that is set up as active in your `KUBECONFIG` file. If you want to change the target, | |
| E2E tests run against a cluster that is set up as active in your `KUBECONFIG` file. If you want to change the target, |
| export an environment vairable `KUBECONFIG` to specific kubeconfig file. Make sure you have admin permission on a | ||
| cluster. | ||
|
|
||
| To run the E2E tests, use `make test-e2e` command in project root directory. |
There was a problem hiding this comment.
Suggested change
| To run the E2E tests, use `make test-e2e` command in project root directory. | |
| To run the E2E tests, use the `make test-e2e` command in the project's root directory. |
| Put libraries used in tests under `pkg` directory, just as in standard Go project scheme. | ||
|
|
||
| Function body does not follow a strict methodology. Just keep it simple. Usually they are written as procedural functions. | ||
| If you need to implement more advanced logic, remember to not leak the implementation outside the package/function. |
There was a problem hiding this comment.
Suggested change
| If you need to implement more advanced logic, remember to not leak the implementation outside the package/function. | |
| If you need to implement more advanced logic, remember not to leak the implementation outside the package/function. |
| Function body does not follow a strict methodology. Just keep it simple. Usually they are written as procedural functions. | ||
| If you need to implement more advanced logic, remember to not leak the implementation outside the package/function. | ||
|
|
||
| Start name of each function with prefix `TestE2E`. |
There was a problem hiding this comment.
Suggested change
| Start name of each function with prefix `TestE2E`. | |
| Start each function's name with the prefix `TestE2E`. |
| If you need to implement more advanced logic, remember to not leak the implementation outside the package/function. | ||
|
|
||
| Start name of each function with prefix `TestE2E`. | ||
| When running `go test`, we set up pattern for running tests that only start with this prefix. |
There was a problem hiding this comment.
Suggested change
| When running `go test`, we set up pattern for running tests that only start with this prefix. | |
| When running `go test`, we set up a pattern for running tests that only start with this prefix. |
|
|
||
| When you want to conditionally run specific test, use environment variables. | ||
| Those environment variables must be set in the environment before running `go test`. Do not set the variable in the test file. | ||
| For example, when the test should run only on gardener, add the simple if statement at the beginning of your test function: |
There was a problem hiding this comment.
Suggested change
| For example, when the test should run only on gardener, add the simple if statement at the beginning of your test function: | |
| For example, when the test should run only on Gardener, add the simple `if` statement at the beginning of your test function: |
| } | ||
| ``` | ||
|
|
||
| When you need to test multiple options in single configuration of a cluster, consider using table-driven tests. |
There was a problem hiding this comment.
Suggested change
| When you need to test multiple options in single configuration of a cluster, consider using table-driven tests. | |
| When you need to test multiple options in a single configuration of a cluster, consider using table-driven tests. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
test-e2eto Matrixes of gardener tests on post and release workflows.This tests implements the official Istio egress tutorial with TLS passthrough.
Note that this test will work only on a cluster that supports NetworkPolicy.
K3s/K3d uses flannel as CNI. Flannel does not support NetworkPolicies very well!
For local cluster only kind supports NetworkPolicies. If we don't want to spend a lot of money on gardener clusters, we should invest in using kind locally and in CI one day.
#1201