HammerDB v6.0 includes CI and pipeline automation for repeatable database build and benchmark workflows. This functionality is intended for both beginners and advanced users who want HammerDB to clone, build, install and test a database branch, tag or commit in a controlled environment.
The CI and pipeline functionality is currently focused on MariaDB, MySQL and PostgreSQL. The workflow can be used to test a database branch, tag or commit, build and install the database software, create the HammerDB benchmark schema, run a benchmark workload and generate a detailed benchmark report with profiling and statistics enabled automatically.
You can install the CI environment anywhere on your system with a default installation under /opt/hammerdb-ci. The directory contains the HammerDB installation and you should create a TMP directory used for the jobs database, CI logs and temporary working files.
ubuntu@ubuntu24:/opt/hammerdb-ci$ ls HammerDB-6.0 TMP ubuntu@ubuntu24:/opt/hammerdb-ci$ ls HammerDB-6.0 agent hammerdb hammerdbws pylib scripts config hammerdbcli LICENSE README.md
The TMP directory should be placed on storage with sufficient free space for database builds, installations and benchmark data. At least 100GB of free space is recommended for a standard CPU-intensive test environment in /opt/hammerdb-ci. I/O-intensive tests can require much more space, and may need installations and database storage sized up to approximately 1TB depending on the selected database, workload and profile.
ubuntu@ubuntu24:/opt/hammerdb-ci$ df -h /opt/hammerdb-ci/ Filesystem Size Used Avail Use% Mounted on /dev/sdb1 98G 44M 93G 1% /opt/hammerdb-ci
Before starting HammerDB for CI use, set TMP to the CI TMP directory. This ensures that the HammerDB jobs database and CI state are written to the intended location.
ubuntu@ubuntu24:/opt/hammerdb-ci/HammerDB-6.0$ export TMP=/opt/hammerdb-ci/TMP
The HammerDB CLI includes CI and pipeline commands for initialising the CI environment, checking the active TMP and jobs database, starting and stopping the listener, reviewing pipeline state, updating CI configuration and simulating webhook events from the command line. CI commands are supported on Linux/Unix in this release.
Table 1.3. HammerDB CI Commands
| Command | Usage | Description |
|---|---|---|
| pipes | pipes | pipes <pipeid> | Shows the CI pipeline summary table. With a pipeid, shows detailed CI pipeline output and linked jobs. |
| pipe | pipe | pipe <pipeid> | Alias for pipes. |
| ci | ci | ci <pipeid> | Alias for pipes. |
| citmp | citmp | Shows the TMP directory and jobs database path used by CI. |
| cifix | cifix | Initialises or repairs the HammerDB CI environment, creates required directories under the configured CI base directory, downloads provider configuration files and validates the setup. TMP mismatch is reported as a warning only. |
| ciset | ciset top section key value | Updates a CI configuration entry and persists it in ci.db. For example, ciset can update a provider repository URL or the common listener port. |
| cilisten | cilisten | Starts the CI GitHub webhook listener and job watcher on Linux/Unix. At startup cilisten runs cireset to clear stale blocking CI rows. |
| cistatus | cistatus | Shows whether the CI listener and watcher are running. |
| cistop | cistop | Stops the CI webhook listener and job watcher. |
| cireset | cireset | Marks incomplete CI pipeline rows as FAILED. This can be used to clear stale PENDING, INIT, BUILDING or RUNNING rows that block a new CI pipeline. CI history is preserved. |
| cipush | cipush refname ?pipeline? ?workload? ?dbprefix? ?io_intensive? | Simulates a GitHub webhook push for a ref. This command is useful for local testing of CI events without sending an external webhook. The refname must be refs/tags/name, refs/heads/name or a commit SHA. Pipeline is commonly single, profile or compare. Workload is C or H. Dbprefix is maria, mysql or pg. The io_intensive flag is 0 or 1. |
Start the HammerDB CLI from the HammerDB installation directory. When TMP has been set to /opt/hammerdb-ci/TMP, HammerDB creates or opens the jobs database in that location.
ubuntu@ubuntu24:/opt/hammerdb-ci/HammerDB-6.0$ ./hammerdbcli HammerDB CLI v6.0 Copyright © HammerDB Ltd hosted by tpc.org 2019-2026 Type "help" for a list of commands Initialized new Jobs on-disk database /opt/hammerdb-ci/TMP/hammer.DB
Run cifix to initialise and validate the CI environment. This checks the configured providers, creates the required provider directories, downloads database configuration files and validates the setup.
hammerdb>cifix Running cifix... CI FIX: starting CI FIX: provider MariaDB CI FIX: provider PostgreSQL CI FIX: provider MySQL CI FIX: directory exists /opt/hammerdb-ci CI FIX: directory exists /opt/hammerdb-ci/TMP CI FIX: creating directory /opt/hammerdb-ci/providers/mariadb CI FIX: creating directory /opt/hammerdb-ci/providers/mariadb/builds CI FIX: creating directory /opt/hammerdb-ci/providers/mariadb/config CI FIX: creating directory /opt/hammerdb-ci/providers/mariadb/installs CI FIX: creating directory /opt/hammerdb-ci/providers/mysql CI FIX: creating directory /opt/hammerdb-ci/providers/mysql/builds CI FIX: creating directory /opt/hammerdb-ci/providers/mysql/config CI FIX: creating directory /opt/hammerdb-ci/providers/mysql/installs CI FIX: creating directory /opt/hammerdb-ci/providers/postgresql CI FIX: creating directory /opt/hammerdb-ci/providers/postgresql/builds CI FIX: creating directory /opt/hammerdb-ci/providers/postgresql/config CI FIX: creating directory /opt/hammerdb-ci/providers/postgresql/installs CI FIX WARNING: less than 100GB free under /opt/hammerdb-ci (92GB) CI FIX: downloading and validating provider configuration files CI VALIDATE: provider MariaDB CI VALIDATE: provider PostgreSQL CI VALIDATE: provider MySQL CI VALIDATE: PASSED CI FIX: COMPLETE
After cifix has completed, the providers directory is created under /opt/hammerdb-ci. Each provider has directories for builds, configuration and installs.
ubuntu@ubuntu24:/opt/hammerdb-ci$ ls HammerDB-6.0 providers TMP
Before starting the listener, review the CI configuration for the database provider and pipeline that will be tested. The configuration controls the source repository, clone command, build command, install location, database configuration files and workload profile.
The ciset command can be used to update CI configuration values from the HammerDB CLI. For example, the repository URL for a provider can be updated, and the common listener port can be changed if the default port is already in use.
hammerdb>ciset MariaDB build repo_url https://github.com/MariaDB/server.git hammerdb>ciset common listen_port 5000
Use citmp to confirm the TMP directory and jobs database path used by CI.
hammerdb>citmp
Start the CI listener with cilisten. The listener validates the CI setup, resets any stale blocking rows, reports the TMP directory and listener port, and starts the CI watcher.
ubuntu@ubuntu24:/opt/hammerdb-ci/HammerDB-6.0$ ./hammerdbcli HammerDB CLI v6.0 Copyright © HammerDB Ltd hosted by tpc.org 2019-2026 Type "help" for a list of commands Initialized Jobs on-disk database /opt/hammerdb-ci/TMP/hammer.DB using existing tables (86,016 bytes) hammerdb>cilisten CI validation passed CI reset: no blocked CI pipeline rows found CI TMP: /opt/hammerdb-ci/TMP CI listener: port 5000 CI log: /opt/hammerdb-ci/TMP/hammerdbci.log CI watcher: initializing CI watcher started.
The listener remains active while HammerDB is running. Use cistatus to confirm whether the listener and watcher are running, and cistop to stop them.
hammerdb>cistatus hammerdb>cistop
In a second terminal, set the same TMP environment variable and start the HammerDB web service. The web service uses the same hammer.DB jobs database and provides browser views for jobs, pipeline activity and CI output.
ubuntu@ubuntu24:/opt/hammerdb-ci/HammerDB-6.0$ export TMP=/opt/hammerdb-ci/TMP ubuntu@ubuntu24:/opt/hammerdb-ci/HammerDB-6.0$ ./hammerdbws HammerDB Web Service v6.0 Copyright © HammerDB Ltd hosted by tpc.org 2019-2026 Type "help" for a list of commands Web Service using /opt/hammerdb-ci/TMP/hammer.DB database Listening for HTTP requests on TCP port 8080
Open the HammerDB web service in a browser. The Jobs and Pipelines pages provide the main browser views for automation. The CI details page shows detailed CI pipeline information including build, install and linked job output.
http://localhost:8080/jobs http://localhost:8080/pipelines http://localhost:8080/ci?ci_id=INTEGER
Click on the Pipelines link on the main menu. This shows the option to choose a database and run a desired test.
The Pipelines page can be used to start a configured CI benchmark run. The form allows a database provider, reference and pipeline type to be selected. A reference can be a tag, branch or commit, depending on the source repository and provider configuration. The example shown is for a single test.
When a benchmark is started from the Pipelines page, HammerDB uses the configured provider pipeline to clone the database source, build and install the database, configure the database, create the HammerDB schema and run the selected workload. HammerDB also enables timing profile and statistics collection so that a detailed benchmark report can be generated for the completed run.
The Pipelines page supports single benchmark runs and profile comparison workflows. The default benchmark mode is CPU-intensive. The I/O-intensive option should only be selected when the test environment has sufficient storage capacity, because I/O-intensive tests can require much larger database installations and benchmark data volumes.
The following example shows pipeline activity after a benchmark has been started. The detailed CI page records the configured reference, pipeline stage activity and command output.
Completed CI runs create HammerDB jobs in the same jobs repository used by normal HammerDB benchmark runs. The Jobs page can be used to view the benchmark jobs created by a CI pipeline, inspect the result, review timing and metrics data, and open the generated report views using the Benchmark report link.
Pipelines also support running automated performance profiles and comparisons whereby a profile on any chosen tag, branch or commit is automatically run on the preceding tag, branch or commit for comparison. This allows you to monitor new open source database builds for performance and stability.
CI pipelines can also be started and inspected from the HammerDB CLI. This is useful when validating a new CI environment, testing a provider configuration, or running a pipeline manually without using the browser Pipelines page.
Before starting a pipeline from the CLI, set TMP to the same directory used by the HammerDB web service and run cifix to validate the provider configuration. The listener can then be started with cilisten. If cipush is used before the listener is running, HammerDB will attempt to start the listener automatically.
ubuntu@ubuntu24:/opt/hammerdb-ci/HammerDB-6.0$ export TMP=/opt/hammerdb-ci/TMP ubuntu@ubuntu24:/opt/hammerdb-ci/HammerDB-6.0$ ./hammerdbcli hammerdb>cifix hammerdb>citmp hammerdb>cilisten hammerdb>cistatus
The cipush command simulates the GitHub webhook event that would normally be received by the CI listener. The command syntax is:
cipush refname ?pipeline? ?workload? ?dbprefix? ?io_intensive?
The refname must identify a branch, tag or commit SHA. Branches use refs/heads/name, tags use refs/tags/name, and commit references can be supplied as a 7 to 40 character SHA. The pipeline is normally single, profile or compare. The workload is C for TPROC-C or H for TPROC-H. The dbprefix selects the database provider, for example maria, mysql or pg. The final io_intensive argument is 0 for the standard CPU-intensive profile or 1 for an I/O-intensive profile.
The following examples show typical manual pipeline requests for MariaDB. The same pattern can be used for MySQL by using mysql as the dbprefix, or for PostgreSQL by using pg.
hammerdb>cipush refs/heads/11.8 single C maria 0 hammerdb>cipush refs/tags/mariadb-12.3.2 profile C maria 0 hammerdb>cipush refs/heads/11.8 compare C maria 0 hammerdb>cipush d33f879aec858063edd17aa2daa46db03abb2bae profile C maria 0
When a pipeline request is accepted, it is inserted into the CI pipeline table and picked up by the watcher. The watcher runs one pipeline at a time. If another pipeline is already pending or running, the listener rejects the new request until the active pipeline has completed or has been cleared.
The pipes command shows the latest pipeline runs. pipe and ci are aliases for pipes.
hammerdb>pipes Pipeid DB Ref Pipeline Date Status ------------------------------------------------------------------------------------------------ 12 MariaDB refs/heads/11.8 Profile 2026-06-24 10:15:34 COMPLETE 11 MariaDB refs/tags/mariadb-12.3.2 Single 2026-06-24 09:03:12 COMPLETE
Use pipes with a pipeid to show detailed pipeline output. The detailed view shows the pipeline status, start and end timestamps, commit message, clone command and output, build command and output, install command and output, package command, configuration file, database start command, CI dictionary and any HammerDB jobs created between the CI start and end timestamps.
hammerdb>pipes 12 Pipeline 12: refs/heads/11.8 ======================================================================== Status: COMPLETE Start time: 2026-06-24 10:15:34 End time: 2026-06-24 11:02:18 Commit message: Latest commit message for the tested ref Clone command: git clone --branch 11.8 https://github.com/MariaDB/server.git . Build command: cmake ... Build output: ... Install command: ... Start command: ... Jobs between CI start/end (2026-06-24 10:15:34 -> 2026-06-24 11:02:18): 1. 67FD3C792EF803E253533323
The detailed pipes output truncates long command output in the CLI so that it remains readable. Use the HammerDB web service Pipelines page for the full pipeline output when a build or install log is large.
The CI listener accepts webhook-style HTTP requests so that an external system can trigger a HammerDB pipeline. This is the mechanism used when a GitHub workflow or repository webhook notifies HammerDB that a branch, tag or commit should be tested.
The listener expects a GitHub create-style event and a JSON body containing the ref, database, pipeline, workload and io_intensive fields. The following curl command demonstrates the same request that cipush generates locally.
curl -i -X POST http://localhost:5000/ \
-H "X-GitHub-Event: create" \
-H "Content-Type: application/json" \
-d '{"ref":"refs/heads/11.8","database":"maria","pipeline":"profile","workload":"C","io_intensive":0}'If the CI listener is published through a reverse proxy such as NGINX, the external path can be different from the listener root path. For example, a reverse proxy can expose /cihook and forward the request to the local listener on port 5000. In that case the curl command should use the external URL and any authentication or token header configured in the proxy.
curl -i -X POST https://example.com/cihook \
-H "X-GitHub-Event: create" \
-H "Content-Type: application/json" \
-H "Authorization: Bearer YOUR_PROXY_TOKEN" \
-d '{"ref":"refs/tags/mariadb-12.3.2","database":"maria","pipeline":"single","workload":"C","io_intensive":0}'A successful request returns OK and creates a pending CI pipeline row. If a pipeline is already pending or running, the listener rejects the new request because HammerDB runs one CI pipeline at a time in the local CI environment.
HTTP/1.1 200 OK Content-Type: text/plain OK
After sending the webhook request, use pipes, pipe or ci from the HammerDB CLI, or open the Pipelines page in the HammerDB web service, to monitor the pipeline status and review the command output.