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)
BUILD.bazel	linkopts: crypt32.lib + user32.lib when OpenSSL + Windows (gated via selects.config_setting_group)	IF (MSVC) TARGET_LINK_LIBRARIES(... Crypt32)
ut/BUILD.bazel	/bigobj on Windows	IF (MSVC) TARGET_COMPILE_OPTIONS(... /bigobj)
MODULE.bazel	platforms 1.1.0 (for @platforms//os:windows in select())	—

The OpenSSL backend pulls in the Win32 cert store (crypt32) and user32; BoringSSL bundles its own system-lib deps, which is why only the OpenSSL backend needed this. These are attached to the //:clickhouse library so downstream executables link transitively, without each consumer repeating it. Notably, the BCR openssl module itself compiled cleanly under MSVC — the failures were purely missing system-lib declarations in this repo's BUILD file.

Part 3: SSL link guard

A library-only bazel build //:clickhouse produces a static archive and never invokes the linker, and the hermetic unit_tests binary deliberately excludes every SSL source — so static-library linking never pulled sslsocket.obj (and its crypt32/user32 deps) into any executable. That's exactly why the OpenSSL/Windows link failure above didn't surface in CI; it only broke in a downstream consumer that links the SSL code path.

To close the gap, ut/ssl_link_ut.cpp adds a single test that constructs an SSLContext. This drags sslsocket.obj and its transitive system-lib dependencies into the test binary's link step, so a missing crypt32/user32 now fails in CI rather than downstream. It uses default params (no CA loading, no socket), so it stays hermetic, and it is select()-ed out under tls=no, where the SSL sources aren't part of the library.

Full end-to-end SSL connection testing (which needs a server and bazel run + runfiles) is left to a follow-up PR.

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.
• SSLLink.ConstructContext runs under tls=boringssl/openssl and is excluded under tls=no.
• All 9 CI matrix combinations pass, including Windows/MSVC + OpenSSL.

[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.

[BYVoid]

Thanks @slabko, both are great catches. I've pushed fixes addressing your first point and the testing-gap behind it.

1. OpenSSL on Windows needs crypt32/user32. You're right that this belongs in clickhouse-cpp, not in each consumer's linkopts. Same class of issue as the ws2_32 fix earlier — a dependency the library uses should be declared by the library and propagate transitively. The difference is scope: ws2_32 is needed by our own socket code in every configuration, whereas crypt32/user32 are pulled in by OpenSSL specifically (BoringSSL bundles its own system-lib deps, which is why the BoringSSL backend never hit this). So I gated them on "OpenSSL and Windows" via a selects.config_setting_group, and attached them to the //:clickhouse library's linkopts so downstream executables link cleanly with no extra setup on their side. This mirrors CMake's MSVC Crypt32 link.

Why CI didn't catch it. This is the interesting part and it ties directly into your second comment. Two things combined:

• bazel build //:clickhouse produces a static archive and never invokes the linker, so unresolved externals simply don't surface there.
• The only executable in our CI, //ut:unit_tests, is the hermetic subset — and it deliberately excludes every SSL source. Static-library linking only pulls in the .obj members that are actually referenced, so sslsocket.obj (and its crypt32/user32 dependencies) was never linked. ws2_32 was caught only by luck, because the socket unit tests happen to reference Winsock symbols.

In other words, we had no executable that links the OpenSSL code path — exactly the blind spot your consumer binary exposed.

Fix for the blind spot: I added a small link/compile guard, ut/ssl_link_ut.cpp — a single test that constructs an SSLContext. That drags sslsocket.obj and its transitive system-lib deps into the test binary's link step, so a missing crypt32/user32 now fails in CI instead of in a downstream project. It uses default params (no CA loading, no socket), so it stays hermetic; and it's select()-ed out under tls=no, where the SSL sources aren't part of the library. The Bazel matrix (3 OS × 3 TLS = 9 jobs) is green with this in place, including windows-latest + openssl.

2. Non-hermetic E2E tests. Agreed — the server-dependent tests (client_ut, roundtrip_tests, Column_ut, ssl_ut, …) shouldn't be cc_test under the sandbox. The right shape is a separate cc_binary (or a cc_test tagged manual/external + local) driven by bazel run, since bazel test enforces sandboxing and no network by default. Doing that properly involves runfiles plumbing — packaging the test's data/fixtures and resolving them at runtime via the runfiles library so the binary finds them regardless of cwd — plus a way to point it at a $CLICKHOUSE_HOST (a docker-compose service, like the CMake CI uses). I'd prefer to keep this PR focused on the hermetic suite + the Windows fixes, and tackle the E2E bazel run target with its runfiles setup in a dedicated follow-up PR. That follow-up would also naturally exercise the full SSL connect path, complementing the link guard added here.

Does that split sound reasonable to you?

[slabko]

Agreed!