.github

What this module is responsible for

The .github module contains the Continuous Integration (CI) and Continuous Deployment (CD) workflows for the booblik repository. It manages the automated verification of the broker's logic, the correctness of its Docker distribution, and the compliance of various language clients against the core protocol.

Diagram

Benchmark execution and reporting

The benchmark suite is designed to detect catastrophic performance collapses rather than subtle regressions. As noted in benchmark.yml:10-12, a hosted runner is a different machine every time, meaning a 20% swing between runs is considered noise rather than a regression. To avoid measuring noise, the workflow runs mainCiBenchmark instead of mainBenchmark to exclude disk-bound operations like GroupCommitBenchmark (benchmark.yml:22-25). The suite runs weekly on a schedule (benchmark.yml:36) and uses a "floor" mechanism to fail only if performance drops by an order of magnitude (benchmark.yml:74-75).

More: Benchmark execution and reporting

The build gate and smoke testing

The build.yml workflow implements a multi-stage gate to ensure the stability of the JVM implementation. It first executes a check job that includes ktlint and unit tests via ./ci/gate.sh jvm (build.yml:35-36). Crucially, benchmarks are compiled but never executed during this stage to prevent silent rot (build.yml:42-43). Once the JVM logic is verified, the workflow performs a smoke test on the packaged broker using ./ci/smoke.sh (build.yml:47-48) to ensure the distribution is functional.

Docker image verification and conformance

To ensure the broker can be shipped as a container, the image job in build.yml:65-68 builds a Docker image and runs ./ci/docker-smoke.sh (build.yml:89). This is followed by a conformance check where the image is tested against a reference client (build.yml:99-102). This process is repeated for each client workflow to ensure that the published image and the client implementations remain in sync with the protocol.

More: Docker image verification and conformance

Client-specific gate and conformance workflows

Each client has a dedicated workflow to manage its specific toolchain and platform requirements:

The Kotlin/Native client is unique because it must run on both ubuntu-24.04 and macos-15 to execute the native binaries (client-kotlin-native.yml:38-39), whereas the conformance check for this client is restricted to Linux because GitHub's macOS runners lack a Docker daemon (client-kotlin-native.yml:69-72).

Key files

Behaviour that surprises

• The build.yml workflow compiles benchmarks using :booblik-benchmark:assembleBenchmarks (build.yml:43) but explicitly refuses to run them to avoid noise from shared runners.
• The client-kotlin-native.yml workflow uses a matrix to run the gate job on both ubuntu-24.04 and macos-15 because native binaries are platform-specific (client-kotlin-native.yml:38-39).
• In client-java.yml, the setup-java action is configured to provide two different versions of the JDK simultaneously (client-java.yml:56-58).