Allow use test utils outside of this repository

[toby3d]

Observed

I'm trying to set up an in-memory or localhost ClickHouse instance to autostart directly from Golang test code, so as not to require manual installation and running dependencies. As far as I understand from the examples in the repository, it's enough to create a test environment and connect to it just as if it were running in production.

But in the process I discovered some unpleasant features: dependencies in the form of docker and broken operation in the presence of vendor. The first I'm still able to ignore for the time being. But I can't give up on the latter because of the privacy of the repository and some of its dependencies, which are easier to vend together with the code than to try to set up special individual accesses in environments I don't control. Also, some dependencies can be moved or removed without my knowledge, which I have unfortunately already encountered and avoided by vendoring.

Expected behaviour

I expect the SDK to have tools to create and configure short-lived ClickHouse instances locally or directly in memory right from go-tests, without having to go online for dependencies. For example, by vendoring the SDK in a project.

Code example

package main_test

import (
	"database/sql"
	"fmt"
	"log"
	"os"
	"testing"

	"github.com/ClickHouse/clickhouse-go/v2"
	clickhousetest "github.com/ClickHouse/clickhouse-go/v2/tests"
)

var testDB *sql.DB

func TestMain(m *testing.M) {
	env, err := clickhousetest.CreateClickHouseTestEnvironment("sample.test")
	if err != nil {
		log.Fatalln("cannot create environment for testing clickhouse server:", err)
	}

	testDB = clickhouse.OpenDB(&clickhouse.Options{
		Addr: []string{fmt.Sprintf("%s:%d", env.Host, env.Port)},
		Auth: clickhouse.Auth{
			Database: env.Database,
			Username: env.Username,
			Password: env.Password,
		},
	})

	if err = testDB.Ping(); err != nil {
		log.Fatalln("failed ping of testing clickhouse database:", err)
	}

	os.Exit(m.Run())
}

// Use testDB in other tests...

Error log

2024/05/24 01:08:04 github.com/testcontainers/testcontainers-go - Connected to docker: 
  Server Version: 26.1.3
  API Version: 1.45
  Operating System: Arch Linux
  Total Memory: 15844 MB
  Resolved Docker Host: unix:///var/run/docker.sock
  Resolved Docker Socket Path: /var/run/docker.sock
  Test SessionID: 43088ad406089a9a6b8c842f193ac703c8489b4bbe18d000dee8176e5b327762
  Test ProcessID: 148a6eca-5316-4ad6-b2b7-9eae95102d2e
Using Docker for IT tests
2024/05/24 01:08:04 🐳 Creating container for image testcontainers/ryuk:0.6.0
2024/05/24 01:08:04 ✅ Container created: 8ee4b517b100
2024/05/24 01:08:04 🐳 Starting container: 8ee4b517b100
2024/05/24 01:08:04 ✅ Container started: 8ee4b517b100
2024/05/24 01:08:04 🚧 Waiting for container id 8ee4b517b100 image: testcontainers/ryuk:0.6.0. Waiting for: &{Port:8080/tcp timeout:<nil> PollInterval:100ms}
2024/05/24 01:08:04 🔔 Container is ready: 8ee4b517b100
2024/05/24 01:08:04 🐳 Creating container for image clickhouse/clickhouse-server:latest
2024/05/24 01:08:04 cannot create environment for testing clickhouse server: Error response from daemon: invalid mount config for type "bind": bind source path does not exist: /home/toby3d/go/src/source.toby3d.me/toby3d/playground/vendor/github.com/ClickHouse/clickhouse-go/v2/tests/resources/custom.xml: failed to create container
exit status 1
FAIL	source.toby3d.me/toby3d/playground	0.431s

Details

Environment

• clickhouse-go version: v2.24.0
• Interface: database/sql compatible driver
• Go version: 1.22.3
• Operating system: Arch linux/amd64
• ClickHouse version: local version 24.4.1.2088 (official build)
• Is it a ClickHouse Cloud? No
• ClickHouse Server non-default settings, if any: none
• CREATE TABLE statements for tables involved: none
• Sample data for all these tables, use clickhouse-obfuscator if necessary

[jkaflik]

Hi @toby3d

I am quite not sure what the problem is.

I expect the SDK to have tools to create and configure short-lived ClickHouse instances locally or directly in memory right from go-tests, without having to go online for dependencies.

clickhouse-go does exactly this thing. By default it runs ClickHouse instance in container (using Docker API). Your error says:

Error response from daemon: invalid mount config for type "bind": bind source path does not exist: /home/toby3d/go/src/source.toby3d.me/toby3d/playground/vendor/github.com/ClickHouse/clickhouse-go/v2/tests/resources/custom.xml

Did you check if /home/toby3d/go/src/source.toby3d.me/toby3d/playground/vendor/github.com/ClickHouse/clickhouse-go/v2/tests/resources/custom.xml exists in your vendor path?

Do I understand correctly you want to reuse clickhouse-go test utilities in your project?

[toby3d]

clickhouse-go does exactly this thing. By default it runs ClickHouse instance in container (using Docker API).

Not quite "exactly", since an external dependency in the form of a docker is used. This complicates running tests in CI/CD in "flat" images (like scratch) by requiring docker to be run in the docker from Go tests. As within images, the docker may not be present on end machines. Plus, even if the docker is exists, it still requires downloading the right image from the network, which is not always guaranteed either.

Did you check if /home/toby3d/go/src/source.toby3d.me/toby3d/playground/vendor/github.com/ClickHouse/clickhouse-go/v2/tests/resources/custom.xml exists in your vendor path?

No, go mod vendor does not copy those files:

[jkaflik]

@toby3d

This complicates running tests in CI/CD in "flat" images (like scratch) by requiring docker to be run in the docker from Go tests. As within images, the docker may not be present on end machines. Plus, even if the docker is exists, it still requires downloading the right image from the network, which is not always guaranteed either.

Docker runner is a cost we sacrifice on our side. Is there any reason you might want to run clickhouse-go tests in your CI?

[toby3d]

Is there any reason you might want to run clickhouse-go tests in your CI?

If we allow the sacrifice of running tests in CI, we are left with the requirement of local testing of ClickHouse related code on the developer's machine with a simple go test ./..., without the need to run the instance and clean up the data after running the tests manually, with support for running tests with t.Parallel().

Neither in the case of a local machine nor CI/CD, I can't afford to throw away a vendor that ClickHouse doesn't explicitly support right now.