github
/
k3s
mirror of https://github.com/k3s-io/k3s
1
0
Fork 0
Code Issues Projects Releases Wiki Activity
k3s/test/e2e/e2e_test.go

79 lines
2.8 KiB
Go
Raw Normal View History

Revert "Revert "Use native Ginkgo test runner instead of cmd/e2e (attempt N)"" This reverts commit f4bb6aa37d6dc3f244ad22204812255c6ecb148b.
2015-05-19 16:13:08 +00:00
/*
Remove "All rights reserved" from all the headers.
2016-06-03 00:25:58 +00:00
Copyright 2015 The Kubernetes Authors.
Revert "Revert "Use native Ginkgo test runner instead of cmd/e2e (attempt N)"" This reverts commit f4bb6aa37d6dc3f244ad22204812255c6ecb148b.
2015-05-19 16:13:08 +00:00
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
*/
package e2e
import (
e2e: clarify and enhance configuration support Storing settings in the framework's TestContext is not something that out-of-tree test authors can do because for them the framework is a read-only upstream component. Conceptually the same is true for in-tree tests, so the recommended approach is to define configuration settings in the code that uses them. How to do that is a bit uncertain. Viper has several drawbacks (maintenance status uncertain, cannot list supported options, cannot validate the configuration file). How to handle configuration files is currently getting discussed for kubeadm, with similar concerns about Viper (https://github.com/kubernetes/kubeadm/issues/1040). Instead of making a choice now for E2E, the recommendation is that test authors continue to define command line flags as before, except that they should do it in their own code and with better flag names. But the ability to read options also from a file is useful, so several enhancements get added: - all settings defined via flags can also be read from a configuration file, without extra work for test authors - framework/config makes it possible to populate a struct directly and define flags with a single function call - a path and file suffix can be given to --viper-config (as in "--viper-config /tmp/e2e.json") instead of expecting the file in the current directory; as before, just plain "--viper-config e2e" still works - if "--viper-config" is set, the file must exist; otherwise the "e2e" config is optional (as before) - errors from Viper are no longer silently ignored, so syntax errors are detected early - Viper support is optional: test suite authors who don't want it are not forced to use it by the e2e/framework
2018-07-27 11:53:59 +00:00
"flag"
"fmt"
"os"
Revert "Revert "Use native Ginkgo test runner instead of cmd/e2e (attempt N)"" This reverts commit f4bb6aa37d6dc3f244ad22204812255c6ecb148b.
2015-05-19 16:13:08 +00:00
"testing"
Update test/e2e for test/e2e/framework refactoring
2016-04-07 17:21:31 +00:00
Add blank import for node tests
2017-08-08 15:32:27 +00:00
"k8s.io/kubernetes/test/e2e/framework"
e2e: abstract access to additional files The new test/e2e/framework/testfiles package makes it possible to write tests that do not depend on a specific way of providing additional test files at runtime. Such tests and the framework are then more easily reused in other test suites. In the test/e2e suite file access is enabled based on the existing "repo-root" command line parameter and the built-in bindata. Tests using the new API will first check for files under "repo-root" and then fall back to the builtin data. This way, users of a test binary can modify those files without having to rebuild the binary. "repo-root" is still needed because at least some tests check for additional files (secret.yaml, via ingress_utils.go) that are not part of the upstream source code and thus may or may not be built into a test binary. Tests using bindata or repo-root directly get modified to use the new API, or removed when they are obsolete: test/e2e/examples.go depended on files that were removed in https://github.com/kubernetes/kubernetes/pull/61246 and thus can no longer be run in Kubernetes. Moving the tests to kubernetes/examples is tracked in https://github.com/kubernetes/examples/issues/214. The file removal did not break the automated E2E testing probably because the tests are under the Feature:Example tag and thus not enabled during normal CI runs. Removing also the obsolete tests makes it simpler to rework the "repo-root" setting because less code uses it. Related-to: #66649 and #23987
2018-08-31 14:43:15 +00:00
"k8s.io/kubernetes/test/e2e/framework/testfiles"
e2e: clarify and enhance configuration support Storing settings in the framework's TestContext is not something that out-of-tree test authors can do because for them the framework is a read-only upstream component. Conceptually the same is true for in-tree tests, so the recommended approach is to define configuration settings in the code that uses them. How to do that is a bit uncertain. Viper has several drawbacks (maintenance status uncertain, cannot list supported options, cannot validate the configuration file). How to handle configuration files is currently getting discussed for kubeadm, with similar concerns about Viper (https://github.com/kubernetes/kubeadm/issues/1040). Instead of making a choice now for E2E, the recommendation is that test authors continue to define command line flags as before, except that they should do it in their own code and with better flag names. But the ability to read options also from a file is useful, so several enhancements get added: - all settings defined via flags can also be read from a configuration file, without extra work for test authors - framework/config makes it possible to populate a struct directly and define flags with a single function call - a path and file suffix can be given to --viper-config (as in "--viper-config /tmp/e2e.json") instead of expecting the file in the current directory; as before, just plain "--viper-config e2e" still works - if "--viper-config" is set, the file must exist; otherwise the "e2e" config is optional (as before) - errors from Viper are no longer silently ignored, so syntax errors are detected early - Viper support is optional: test suite authors who don't want it are not forced to use it by the e2e/framework
2018-07-27 11:53:59 +00:00
"k8s.io/kubernetes/test/e2e/framework/viperconfig"
e2e: abstract access to additional files The new test/e2e/framework/testfiles package makes it possible to write tests that do not depend on a specific way of providing additional test files at runtime. Such tests and the framework are then more easily reused in other test suites. In the test/e2e suite file access is enabled based on the existing "repo-root" command line parameter and the built-in bindata. Tests using the new API will first check for files under "repo-root" and then fall back to the builtin data. This way, users of a test binary can modify those files without having to rebuild the binary. "repo-root" is still needed because at least some tests check for additional files (secret.yaml, via ingress_utils.go) that are not part of the upstream source code and thus may or may not be built into a test binary. Tests using bindata or repo-root directly get modified to use the new API, or removed when they are obsolete: test/e2e/examples.go depended on files that were removed in https://github.com/kubernetes/kubernetes/pull/61246 and thus can no longer be run in Kubernetes. Moving the tests to kubernetes/examples is tracked in https://github.com/kubernetes/examples/issues/214. The file removal did not break the automated E2E testing probably because the tests are under the Feature:Example tag and thus not enabled during normal CI runs. Removing also the obsolete tests makes it simpler to rework the "repo-root" setting because less code uses it. Related-to: #66649 and #23987
2018-08-31 14:43:15 +00:00
"k8s.io/kubernetes/test/e2e/generated"
Add blank import for node tests
2017-08-08 15:32:27 +00:00
// test sources
Move api-machinery related e2e tests to a 'api-machinery' e2e test subdirectory.
2017-07-12 17:00:58 +00:00
_ "k8s.io/kubernetes/test/e2e/apimachinery"
Rename test dir to allude sig-apps ownership Signed-off-by: Michail Kargakis <mkargaki@redhat.com>
2017-07-20 10:22:11 +00:00
_ "k8s.io/kubernetes/test/e2e/apps"
Migrate sig-auth e2e tests. **What this PR does / why we need it:** This PR adds [sig-auth] prefix to workload e2e tests in accord to requirements of adding a SIG dashboard to testgrid. Refer PR #48781 for guidelines.
2017-07-14 21:21:06 +00:00
_ "k8s.io/kubernetes/test/e2e/auth"
Move autoscaling e2e tests to a separate directory
2017-04-03 13:42:15 +00:00
_ "k8s.io/kubernetes/test/e2e/autoscaling"
Add blank import for node tests
2017-08-08 15:32:27 +00:00
_ "k8s.io/kubernetes/test/e2e/common"
Refactor logging e2e tests, add new checks
2017-07-31 17:21:48 +00:00
_ "k8s.io/kubernetes/test/e2e/instrumentation"
Import kubectl tests in e2e_test.go so they start running. Also rename the Describe function
2017-07-13 20:16:43 +00:00
_ "k8s.io/kubernetes/test/e2e/kubectl"
fixit: break sig-cluster-lifecycle tests into subpackage
2017-07-18 20:04:46 +00:00
_ "k8s.io/kubernetes/test/e2e/lifecycle"
add integration testing for bootstrap token auth
2017-07-17 11:35:27 +00:00
_ "k8s.io/kubernetes/test/e2e/lifecycle/bootstrap"
Moves networking e2e tests to test/e2e/network This also adds sig-network-{approvers,reviewers} alias
2017-07-11 06:44:46 +00:00
_ "k8s.io/kubernetes/test/e2e/network"
Add blank import for node tests
2017-08-08 15:32:27 +00:00
_ "k8s.io/kubernetes/test/e2e/node"
Move performance tests to test/e2e/scalability subdirectory
2017-07-10 20:41:52 +00:00
_ "k8s.io/kubernetes/test/e2e/scalability"
Initial breakout of scheduling e2es to help assist in both assignment and refactoring.
2017-03-12 21:49:33 +00:00
_ "k8s.io/kubernetes/test/e2e/scheduling"
move some e2e tests to SIG respectively fix typo include the servicecatalog package add framework file update golint failures
2017-08-16 04:34:56 +00:00
_ "k8s.io/kubernetes/test/e2e/servicecatalog"
Segregate storage e2es for easier assignment. Further work is needed to isolate dependencies on shared tooling.
2017-03-19 19:25:40 +00:00
_ "k8s.io/kubernetes/test/e2e/storage"
migrate sig-ui e2e test rebase
2017-08-16 07:07:12 +00:00
_ "k8s.io/kubernetes/test/e2e/ui"
Revert "Revert "Use native Ginkgo test runner instead of cmd/e2e (attempt N)"" This reverts commit f4bb6aa37d6dc3f244ad22204812255c6ecb148b.
2015-05-19 16:13:08 +00:00
)
e2e: clarify and enhance configuration support Storing settings in the framework's TestContext is not something that out-of-tree test authors can do because for them the framework is a read-only upstream component. Conceptually the same is true for in-tree tests, so the recommended approach is to define configuration settings in the code that uses them. How to do that is a bit uncertain. Viper has several drawbacks (maintenance status uncertain, cannot list supported options, cannot validate the configuration file). How to handle configuration files is currently getting discussed for kubeadm, with similar concerns about Viper (https://github.com/kubernetes/kubeadm/issues/1040). Instead of making a choice now for E2E, the recommendation is that test authors continue to define command line flags as before, except that they should do it in their own code and with better flag names. But the ability to read options also from a file is useful, so several enhancements get added: - all settings defined via flags can also be read from a configuration file, without extra work for test authors - framework/config makes it possible to populate a struct directly and define flags with a single function call - a path and file suffix can be given to --viper-config (as in "--viper-config /tmp/e2e.json") instead of expecting the file in the current directory; as before, just plain "--viper-config e2e" still works - if "--viper-config" is set, the file must exist; otherwise the "e2e" config is optional (as before) - errors from Viper are no longer silently ignored, so syntax errors are detected early - Viper support is optional: test suite authors who don't want it are not forced to use it by the e2e/framework
2018-07-27 11:53:59 +00:00
var viperConfig = flag.String("viper-config", "", "The name of a viper config file (https://github.com/spf13/viper#what-is-viper). All e2e command line parameters can also be configured in such a file. May contain a path and may or may not contain the file suffix. The default is to look for an optional file with `e2e` as base name. If a file is specified explicitly, it must be present.")
Revert "Revert "Use native Ginkgo test runner instead of cmd/e2e (attempt N)"" This reverts commit f4bb6aa37d6dc3f244ad22204812255c6ecb148b.
2015-05-19 16:13:08 +00:00
func init() {
e2e: clarify and enhance configuration support Storing settings in the framework's TestContext is not something that out-of-tree test authors can do because for them the framework is a read-only upstream component. Conceptually the same is true for in-tree tests, so the recommended approach is to define configuration settings in the code that uses them. How to do that is a bit uncertain. Viper has several drawbacks (maintenance status uncertain, cannot list supported options, cannot validate the configuration file). How to handle configuration files is currently getting discussed for kubeadm, with similar concerns about Viper (https://github.com/kubernetes/kubeadm/issues/1040). Instead of making a choice now for E2E, the recommendation is that test authors continue to define command line flags as before, except that they should do it in their own code and with better flag names. But the ability to read options also from a file is useful, so several enhancements get added: - all settings defined via flags can also be read from a configuration file, without extra work for test authors - framework/config makes it possible to populate a struct directly and define flags with a single function call - a path and file suffix can be given to --viper-config (as in "--viper-config /tmp/e2e.json") instead of expecting the file in the current directory; as before, just plain "--viper-config e2e" still works - if "--viper-config" is set, the file must exist; otherwise the "e2e" config is optional (as before) - errors from Viper are no longer silently ignored, so syntax errors are detected early - Viper support is optional: test suite authors who don't want it are not forced to use it by the e2e/framework
2018-07-27 11:53:59 +00:00
// Register framework flags, then handle flags and Viper config.
framework.HandleFlags()
if err := viperconfig.ViperizeFlags(*viperConfig, "e2e"); err != nil {
fmt.Fprintln(os.Stderr, err)
os.Exit(1)
}
framework.AfterReadingAllFlags(&framework.TestContext)
e2e: abstract access to additional files The new test/e2e/framework/testfiles package makes it possible to write tests that do not depend on a specific way of providing additional test files at runtime. Such tests and the framework are then more easily reused in other test suites. In the test/e2e suite file access is enabled based on the existing "repo-root" command line parameter and the built-in bindata. Tests using the new API will first check for files under "repo-root" and then fall back to the builtin data. This way, users of a test binary can modify those files without having to rebuild the binary. "repo-root" is still needed because at least some tests check for additional files (secret.yaml, via ingress_utils.go) that are not part of the upstream source code and thus may or may not be built into a test binary. Tests using bindata or repo-root directly get modified to use the new API, or removed when they are obsolete: test/e2e/examples.go depended on files that were removed in https://github.com/kubernetes/kubernetes/pull/61246 and thus can no longer be run in Kubernetes. Moving the tests to kubernetes/examples is tracked in https://github.com/kubernetes/examples/issues/214. The file removal did not break the automated E2E testing probably because the tests are under the Feature:Example tag and thus not enabled during normal CI runs. Removing also the obsolete tests makes it simpler to rework the "repo-root" setting because less code uses it. Related-to: #66649 and #23987
2018-08-31 14:43:15 +00:00
// TODO: Deprecating repo-root over time... instead just use gobindata_util.go , see #23987.
// Right now it is still needed, for example by
// test/e2e/framework/ingress/ingress_utils.go
// for providing the optional secret.yaml file and by
// test/e2e/framework/util.go for cluster/log-dump.
if framework.TestContext.RepoRoot != "" {
testfiles.AddFileSource(testfiles.RootFileSource{Root: framework.TestContext.RepoRoot})
}
// Enable bindata file lookup as fallback.
testfiles.AddFileSource(testfiles.BindataFileSource{
Asset: generated.Asset,
AssetNames: generated.AssetNames,
})
Refactor TestE2E to work correctly in parallel mode The TestE2E function is run on every Ginkgo parallel node. The cluster cleanup, sanity checking, and log dump operations are only intended to be called once, however, so these have been moved out into SynchronizedBeforeSuite and SynchronizedAfterSuite blocks.
2016-01-23 02:16:41 +00:00
}
func TestE2E(t *testing.T) {
E2E Libification rebased (3).
2016-01-21 22:33:14 +00:00
RunE2ETests(t)
Revert "Revert "Use native Ginkgo test runner instead of cmd/e2e (attempt N)"" This reverts commit f4bb6aa37d6dc3f244ad22204812255c6ecb148b.
2015-05-19 16:13:08 +00:00
}