a504aed54d
* Add warning handler callback function in shortcut expander Currently, errors in client-go are propagated back to the callers via function returns. However, there is no elegant way for just warning users. For example, when user wants to get a resource with it's short name format and if there are multiple resources belonging to this short name, we need to warn user about this ambugity which one is picked and which ones are discarded. Not only to overcome this particular case mentioned above, but also propose a way for the possible warnings in the future, this commit adds a warningHandler callback function in shortcutExpander. * Add warningPrinter functionality in ConfigFlags ConfigFlags has neither warning user in a standardized format functionality nor passing warning callback functions to other upper level libraries such as client-go. This commit adds an ability that user can set warningPrinters according to their IOStreams and this warningPrinters will be used to raise possible warnings happening not only in cli-runtime but also in client-go. * Pass warning callback function in ConfigFlags to shortcutExpander This commit passes warning callback function to print possible warnings happened in shortcut expander to warn user in a standardized format. * Add integration test for CRDs having ambiguous short names This commit adds integration test to assure that warning message related to this ambiguity is printed when resources are being retrieved via their short name representations in cases where multiple resources have same short names. This integration test also ensures that the logic behind which resource will be selected hasn't been changed which may cause disperancies in clusters. * Remove defaultConfigFlag global variable * Move default config flags initialization into function * Skip warning for versions of same group/resource * Run update-vendor * Warn only once when there are multiple versions registered for ambiguous resource * Apply gocritic review * Add multi-resource multi-version ambiguity unit test |
||
|---|---|---|
| .. | ||
| apply.sh | ||
| apps.sh | ||
| auth_whoami.sh | ||
| authentication.sh | ||
| authorization.sh | ||
| batch.sh | ||
| certificate.sh | ||
| convert.sh | ||
| core.sh | ||
| crd.sh | ||
| create.sh | ||
| debug.sh | ||
| delete.sh | ||
| diff.sh | ||
| discovery.sh | ||
| events.sh | ||
| exec.sh | ||
| generic-resources.sh | ||
| get.sh | ||
| help.sh | ||
| kubeconfig.sh | ||
| legacy-script.sh | ||
| node-management.sh | ||
| OWNERS | ||
| plugins.sh | ||
| proxy.sh | ||
| rbac.sh | ||
| README.md | ||
| request-timeout.sh | ||
| results.sh | ||
| run.sh | ||
| save-config.sh | ||
| storage.sh | ||
| template-output.sh | ||
| version.sh | ||
| wait.sh | ||
Kubernetes Command-Line Integration Test Suite
This document describes how you can use the Kubernetes command-line integration test-suite.
Running Tests
All Tests
To run this entire suite, execute make test-cmd from the top level. This will import each file containing tests functions
Specific Tests
To run a subset of tests (e.g. run_deployment_tests and run_impersonation_tests), execute make test-cmd WHAT="deployment impersonation". Running specific
tests will not try and validate any required resources are available on the server.
Adding Tests
Test functions need to have the format run_*_tests so they can be executed individually. Once a test has been added, insert a section in legacy-script.sh like
######################
# Replica Sets #
######################
if kube::test::if_supports_resource "${replicasets}" ; then
record_command run_rs_tests
fi
Be sure to validate any supported resources required for the test by using the kube::test::if_supports_resource function.
New File
If the test resides in a new file, source the file in the top of the legacy-script.sh file by adding a new line in
source "${KUBE_ROOT}/test/cmd/apply.sh"
source "${KUBE_ROOT}/test/cmd/apps.sh"
source "${KUBE_ROOT}/test/cmd/authorization.sh"
source "${KUBE_ROOT}/test/cmd/batch.sh"
...
Please keep the order of the source list alphabetical.