Add Bazel unit test target and Windows (MSVC) support

[BYVoid]

Summary

Follow-up to #501, in two parts:

1. Unit tests under Bazel — a cc_test target covering the server-independent subset of the existing googletest suite in ut/, wired into the Bazel CI workflow.
2. Windows (MSVC) support — the Bazel build now links on Windows for all three TLS modes, and windows-latest is added to the CI matrix. MSVC is the toolchain here because it is what Bazel supports on Windows — Bazel has no MinGW support (unlike the CMake build, which has a separate MinGW CI workflow), so the existing Windows mingw coverage remains CMake-only.

Part 1: Unit tests

File	Change
ut/BUILD.bazel	New //ut:unit_tests cc_test target
MODULE.bazel	googletest 1.17.0.bcr.2 from BCR, marked dev_dependency = True so library consumers never pull it in
.github/workflows/bazel.yml	New bazel test //ut:unit_tests step on the matrix

Test selection — only tests that run hermetically, i.e. no running ClickHouse server required:

• Included: types_ut, type_parser_ut, columns_ut, column_array_ut, block_ut, itemview_ut, stream_ut, utils_ut, CreateColumnByType_ut, plus socket_ut (spins up its own LocalTcpServer on localhost, which works inside the Bazel test sandbox), together with the shared support code (utils.cpp, value_generators.cpp, tcp_server.cpp) and the gtest main.cpp.
• Excluded (CMake-only for now): everything that connects to $CLICKHOUSE_HOST — client_ut, roundtrip_tests, Column_ut, low_cardinality_nullable_tests, array_of_low_cardinality_tests, abnormal_column_names_test, readonly_client_test, connection_failed_client_test, performance_tests, ssl_ut. These keep running in the CMake CI, which provides a server via docker-compose. Running them under Bazel (e.g. with a dockerized server fixture) could be a future follow-up.

The split is documented in a comment at the top of ut/BUILD.bazel. googletest is a dev_dependency, so it does not participate in version resolution for downstream consumers — it only exists when this module is the root.

Part 2: Windows support

Adding windows-latest to the matrix surfaced that the Bazel build didn't link on Windows except by luck:

• tls=no and tls=openssl failed with LNK2019: unresolved external symbol __imp_ntohl / __imp_socket / ... — the Winsock library was never declared.
• tls=boringssl only worked because BoringSSL's own BUILD file propagates ws2_32 to its dependents.

Fixes, mirroring what the CMake build already does:

File	Change	CMake counterpart
BUILD.bazel	linkopts: -DEFAULTLIB:ws2_32.lib on Windows	IF (WIN32 OR MINGW) TARGET_LINK_LIBRARIES(... wsock32 ws2_32)
ut/BUILD.bazel	/bigobj on Windows	IF (MSVC) TARGET_COMPILE_OPTIONS(... /bigobj)
MODULE.bazel	platforms 1.1.0 (for @platforms//os:windows in select())	—

Notably, the BCR openssl module itself compiled cleanly under MSVC — the failure was purely the missing Winsock declaration in this repo's BUILD file.

CI

The Bazel workflow matrix is now 3 OS × 3 TLS modes = 9 combinations (Linux, macOS, Windows × boringssl, openssl, no), each running build + unit tests. All 9 are green on this branch.

Test plan

• bazel test //ut:unit_tests passes locally on darwin-arm64 for all three TLS modes: 192 tests, 191 passed, 1 skipped by design (Socketcase.connecttimeout), 1 pre-existing DISABLED test.
• All 9 CI matrix combinations pass, including Windows/MSVC.

[slabko]

@BYVoid,

This is a very good addition, thank you for taking care of that.

There is one issue that I didn't notice at first. I tried importing clickhouse-cpp from an external project. The setup is similar to the one I had before.

bazel_dep(name = "clickhouse_cpp", version = "2.6.1")
git_override(
    module_name = "clickhouse_cpp",
    remote = "https://github.com/BYVoid/clickhouse-cpp.git",
    branch = "bazel-unit-tests",
)

This works fine as long as I don't use OpenSSL. However, when I enable OpenSSL, I get linker errors. I managed to solve the problem by linking against the libraries that provide the missing functions: user32 and crypt32.

load("@rules_cc//cc:cc_binary.bzl", "cc_binary")

cc_binary(
    name = "main",
    srcs = ["main.cpp"],
    deps = ["@clickhouse_cpp//:clickhouse"],
    linkopts = select({
        "@bazel_tools//src/conditions:host_windows": [
            "-DEFAULTLIB:user32.lib",
            "-DEFAULTLIB:crypt32.lib",
        ],
        "//conditions:default": [],
    }),
)

I was wondering what the proper solution to this problem would be. I feel like it makes sense to link these libraries in clickhouse-cpp whenever users set the tls=openssl option on Windows.

[slabko]

I also noticed that you included some unit tests that can run in the test environment. What would be the recommended approach for handling non-hermetic E2E tests?

Do you think we should split them into a separate executable and run it directly with bazel run instead of bazel test? I think that would also help us catch the issues I mentioned in my comment above.