All template YAML files and YAML files containing resource quotas and limits are located in environment/templates/ directory.
Every template uses the same versioning system - the version is stored as a label called version
and is equal to a short version of SHA
of the latest commit that changes the particular file.
To be able to use the in-production testing feature, you need to have the Internal Experimental Features
toggle activated. To do that:
-
visit http://openshift.io/ and login
-
go to https://openshift.io/_profile/_settings/feature-opt-in
-
check
Internal Experimental Features
option
When a PR is made on one of the YAML files you can test in production in your tenant via the following:
-
http://openshift.io/ and login
-
enter the
SHA
of the latest commit in your PR as the "Repository blob SHA" -
check
Auto-update your tenant
-
click
Save and Update Tenant
- your tenant should now be updating/running namespaces using the files from your PR -
the version (label) inside of the updated tenant namespaces is set to the blob
SHA
that was set in the form
If it is needed to test templates without submitting a PR, you can do in a similar way as in case of PR, but on the https://openshift.io/_profile/_tenant page, you have to also specify the name of the repository and path to the directory where the templates are stored. The blob SHA is mandatory even if it should be taken from the master branch.
To go back to using the default YAML:
-
go back to your tenant page like https://openshift.io/_profile/_tenant
-
click
Clear Values
-
check
Auto-update your tenant
-
click
Save and Update Tenant
- and you should be back to the default versions
Get the project:
$ git clone https://github.com/fabric8-services/fabric8-tenant $GOPATH/src/github.com/fabric8-services/fabric8-tenant
$ cd $GOPATH/src/github.com/fabric8-services/fabric8-tenant
Build the project:
$ make
Clean and generate objects (to have the latest version of the generated files in case of any changes since the last run):
$ make clean && make generate
Check any dependency changes:
$ make deps
Run tests (without code coverage):
$ make test-unit-no-coverage
You can do the same clean, generate and fetch the dependencies as it is suggested for unit tests:
$ make clean && make generate && make deps
Start the DB:
$ make integration-test-env-prepare
Run all integration tests (without code coverage):
$ make test-migration && make test-integration-no-coverage && make test-remote-no-coverage
To stop DB:
$ make integration-test-env-tear-down
Follow the instruction from Run integration tests to make sure you have DB running Start Minishift (if it is not running already):
$ minishift start
Install and apply the admin-user Minishift addon. The reason is that we need to use a user (admin) with cluster-admin rights for creating/updating/deleting namespaces.
$ minishift addons apply admin-user
Run Minishift integration tests. Some of the tests may take a longer time to finish
$ make test-with-minishift
Note
|
These minishift integration tests create a new user for every run using a format tenant.minishift.test.$(date +'%H.%M.%S') . It is possible to use a specific already created one by setting a variable MINISHIFT_USER_NAME to the name of the intended user.
The test-cases then create,update and delete namespaces, but it can happen that the proper cleanup is not correctly performed at the end of each test.
To remove all namespaces starting with tenant-minishift-test-* please use $ make clean-minishift-namespaces . To remove all users starting with tenant.minishift.test.* please use $ make clean-minishift-users . To remove both users and namespaces use $ make clean-minishift .
|
Expecting that the DB is running (see Run integration tests) you can trigger all tests by a command:
make test-all