clickhouse does not get built by Hydra

[nh2]

clickhouse fails to build on Hydra, but succeeds to build on my big machine on current commit 45fc7d4: https://hydra.nixos.org/build/147474186

• 2021-04-26 Last successful build
• 2021-05-08 First broken build
• 2021-07-09 This build

Because of this, the plausible NixOS cannot be easily used, as clickhouse is a large build.

It says there Status: Output limit exceeded, but I don't know yet what to do about that yet.

CC @Ma27 @happysalada

[roberth]

This means the log is too long, iirc.

[nh2]

The passing build is 3.6 MB uncompressed, 50 KB gzip-compressed as delivered by Hydra.

The failing build https://hydra.nixos.org/build/147474186 doesn't have any log file, not even a cut-off one.

If I buld the one from commit 45fc7d4 on my own machine, its log output is 3.1 MB uncompressed, so that's actually less than the passing build had.

[roberth]

I've restarted it, to check if the error can be reproduced.

[roberth]

Well, it is repeatable. Maybe someone familiar with hydra can help. @grahamc?

[grahamc]

According to Hydra, the issue is not the build itself, but fetching the source:

I tried building it, and I'm noticing it is fetching Many Git submodules, including grpc, llvm, icu, brotli, and ... well, dozens: https://github.com/ClickHouse/ClickHouse/tree/v21.3.11.5-lts/contrib

This source directory ends up being 2120237434 bytes (2.12024 gigabytes) which is above the 2 gigabyte maximum. Of this source result, almost all of it (1975922534 bytes) is the contrib directory.

I wonder if there is a way to reduce this somehow?

Also, side note the broken attribute should be moved to meta:

nixpkgs/pkgs/servers/clickhouse/default.nix

Line 12 in 5e94296

broken = stdenv.buildPlatform.is32bit; # not supposed to work on 32-bit https://github.com/ClickHouse/ClickHouse/pull/23959#issuecomment-835343685

[nh2]

I wonder if there is a way to reduce this somehow?

A big submodule of clickhouse is llvm, which according to their docs:

Allows to bundle LLVM inside ClickHouse repository. This is intended for reproducible builds, that continue to work regardless to changes of compile options and ABI changes.

The usage of this repository is not necessarily.

Not compiling llvm as part of clickhouse would also save a lot of build time.

[nh2]

How can we exclude an individual submodule from being cloned?

[roberth]

Looks like this will be the first use case for that. Might need to add a sort of "postClone" hook to the fetchgit script, where we can do all sorts of dirty stuff before fetching submodules, LFS or whatnot. Not sure if that's compatible with pre-fetch scripts but that's not a loss; just lacking a feature in a corner case.

[Ma27]

I self-host a Hydra anyways, so I can take a look today :)

[grahamc]

Note that it can use more than 2G of space during the build, but the result of the build must be below 2G at the end of the build.

[Ma27]

I'm very sorry, but I'm going to stop working on this. My main motivation was to get plausible building on Hydra again, but my knowledge on clickhouse internals is far too limited.

The thing is, with a system-llvm you have to set some additional flags (https://github.com/ClickHouse/ClickHouse/blob/v21.3.14.1-lts/cmake/find/llvm.cmake#L47-L53) which in turn cause some linking errors: https://gist.github.com/Ma27/d8ee175e8581286b75ca59198fa772af.

WIth the latest stable (v21.7.4.18-stable) we can't even use a third-party llvm anymore: https://github.com/ClickHouse/ClickHouse/blob/v21.7.4.18-stable/cmake/find/llvm.cmake#L12-L14

Of course, we could disable the features that require llvm, btu I don't think that this is a viable option.

My hackery can be found at https://git.mbosch.me/ma27/clickhouse-experiments in case someone's interested.

[vcunat]

Looks OK now on master/unstable and 21.11.