# Continuous integration checks

An automated integration job should establish the executable and configuration it uses, start an isolated server and wait for readiness before running assertions. A delay alone does not prove that startup succeeded.

## Check readiness and SQL separately

For a configuration with HTTP enabled, these commands check the listener and an authenticated query:

```sh
curl --fail --silent http://127.0.0.1:7401/ping
curl --fail --silent --user default: --data-binary 'SELECT 1 FORMAT csv' \
  'http://127.0.0.1:7401/?database=data'
```

Expect `Ok.` from the health check and `1` from SQL. Use a bounded readiness loop in your own job and fail if the server exits. The health response alone does not verify database selection or credentials.

## Keep each job independent

Give each job its own database, configuration directory and listener ports. Capture the exact SQL, response status and non-sensitive diagnostics on failure. Stop the process the job started and remove only its own temporary data during cleanup.

Run both successful and rejected requests for an adapter that interprets [HTTP status codes](https://coordinatordb.com/docs/concepts/features/interfaces/http). For native applications, add an equivalent query with the [supplied client](https://coordinatordb.com/docs/concepts/features/interfaces/client). Preserve target-machine details when a job validates a distribution on another architecture.