ci

Diagram

The Gate

The Gate acts as the primary entry point for project verification, orchestrating various checks to ensure the codebase is stable. It is designed to be language-agnostic, allowing different clients to define their own requirements via gate.sh (as seen in the loop starting at gate.sh:109). A critical distinction is made between a failure and a skip: if a required toolchain is missing, the part is marked as skipped using exit code 77 (gate.sh:24), ensuring that a machine without a Go toolchain does not report a broken Go client (gate.sh:133).

More: The Gate

The Gatekeeper

To prevent shipping stale or broken code, the build process follows a strict order: first, the code must pass the gate, and only then is a distribution created and packaged into a Docker image (docker-build.sh:5-7). This prevents the common error of building an image from a local build/install directory that might contain unverified or old artifacts (docker-build.sh:6). The script explicitly tracks whether the image was built from a "gated" distribution or from "unchecked code" via the BOOBLIK_SKIP_GATE environment variable (docker-build.sh:20).

More: The Gatekeeper

The Smoke Test

The smoke test verifies the actual delivery of the software by running the distribution in a container and performing end-to-end socket communication (smoke.sh:4). It validates several runtime properties:

• Connectivity: The broker must listen on the configured port (smoke.sh:41).
• Configuration: Environment variables like BOOBLIK_TOPICS must be applied to the process (smoke.sh:65).
• JVM Profile: The process must run with specific flags like -Xmx64M and -XX:+UseSerialGC to ensure the measured profile matches the intended one (docker-smoke.sh:76).
• Persistence: Data must land on the volume and maintain sparseness (docker-smoke.sh:104).

More: The Smoke Test

The Performance Floor

Rather than detecting fine-grained regressions which are unreliable on shared CI runners, this module implements a "floor" to catch catastrophic collapses in performance (benchmark-floor.sh:11). It compares measured throughput against a threshold that is an order of magnitude below the slowest known hardware (benchmark-floor.sh:24). This ensures that if a change makes writes a hundred times slower, it is caught, while ignoring the 37% variance caused by different machines (benchmark-floor.sh:6).

Remote Execution

For high-fidelity measurements, tasks can be executed on remote Linux hosts via remote-run.sh:4. To ensure the integrity of performance measurements, the script performs a storage probe to verify the filesystem type (remote-run.sh:48) and refuses to run if the directory sits on network storage like nfs or cifs (remote-run.sh:62). It also warns the user if the disk is rotational, as such hardware cannot be compared to NVMe runs (remote-run.sh:68).

Key files

Behaviour that surprise

• The part function in gate.sh:54 uses a specific logic where it avoids reporting a failure as a success by checking the exit code after the command execution, preventing "successful failures" from being reported as exit 0.
• In docker-smoke.sh:40, the script avoids using grep -q in a pipeline because set -o pipefail would cause a successful match to return a non-zero exit code due to the SIGPIPE sent to the writer.
• The remote-run.sh script uses printf ' %q' "${TASKS[@]}" (remote-run.sh:76) to ensure that complex arguments are correctly escaped when passed through the SSH transport to the remote shell.