vitess-gh/test
Shlomi Noach 5e9de1f9fe
resolve conflict (#12591)
Signed-off-by: Shlomi Noach <2607934+shlomi-noach@users.noreply.github.com>
2023-03-09 19:40:35 +05:30
..
bin
client
templates Make upgrade downgrade job names unique (#12498) 2023-03-01 10:12:10 +02:00
vttest_schema
README.md
TestingStrategy.md
ci_workflow_gen.go [15.0] CI: remove pitrtls test (#12064) 2023-01-12 16:17:47 -08:00
client_java.sh
client_jdbc.sh
client_test.sh
config.json resolve conflict (#12591) 2023-03-09 19:40:35 +05:30
config_partial_keyspace.json Fix: DML engine multiequal support (#11395) 2022-09-29 18:58:15 +05:30
local_example.sh
region_example.sh
vthook-make_mycnf
vthook-test.sh
vthook-test_backup_error
vthook-test_backup_transform
vtop_example.sh

README.md

##Github CI Workflows

This document has a short outline of how tests are run in CI, how to add new tests and where these are configured.

Adding a new test

Unit tests are run by the unit test runner, one per platform, currently mysql57, mysql80, mariadb101, mariadb102, mariadb103. The workflow first installs the required database server before calling make unit_test.

To add a new end-to-end (e2e) test (also called cluster end to end tests):

  • Add a new object to test/config.json
  • If you are creating a new test shard:
    • update clusterList in ci_workflow_gen.go
    • make generate_ci_workflows
  • If you are adding a new database platform, update the templates\unit_test.tpl to add the platform specific packages and update unitTestDatabases

Vitess test runner

The .github/workflows directory contains one yaml file per workflow. e2e tests are run using the test.go script in the repository root.

This script invokes the vitess e2e test framework using a json configuration file test/config.json which has one object per test. Each test is of the form:

"vtgate": {
			"File": "unused.go",
			"Args": ["vitess.io/vitess/go/test/endtoend/vtgate"],
			"Command": [],
			"Manual": false,
			"Shard": 17,
			"RetryMax": 0,
			"Tags": []
		},

The important parameters here are Args which define the arguments to go test and the Shard which says which Test VM should run this test. All tests which have a common Shard value are run in the same test vm.

Known Issue

  • Each VM does not seem to be able to create a lot of vttablets. For this reason we have had to split a few VReplication e2e tests across Shards. We need to identify and if possible fix this limitation so that we can reduce the number of test Shards