mirror of
https://github.com/ClickHouse/ClickHouse.git
synced 2024-12-12 09:22:05 +00:00
dbfb448290
There is logic regarding which keeper binary use to start keeper cluster in an integration test There 2 options: (1) standalone keeper binary (expected binary name clickhouse-keeper) (2) clickhouse binary with keeper inside Fixed: - option (1) didn't work since docker_compose_keeper.yaml didn't create target clickhouse-keeper at all - if clickhouse-keeper existed, option (1) was taken but clickhouse-keeper could be just a link to clickhouse binary (the link is created always during build if cmake option BUILD_STANDALONE_KEEPER is OFF) |
||
---|---|---|
.. | ||
base | ||
dotnet_client | ||
helper_container | ||
hive_server | ||
kerberized_hadoop | ||
kerberos_kdc | ||
mysql_golang_client | ||
mysql_java_client | ||
mysql_js_client | ||
mysql_php_client | ||
postgresql_java_client | ||
resolver | ||
runner | ||
s3_proxy | ||
README.md |
Docker containers for integration tests
base
container with required packagesrunner
container with that runs integration tests in dockerrunnner/compose
contains docker_compose YaML files that are used in tests
How to run integration tests is described in tests/integration/README.md