gorqlite tests run against an rqlite container in CircleCI

A database client can compile while no longer understanding its server's responses. gorqlite needs more than a SQL string and a decoded row. It discovers cluster information through the rqlite API, so its basic functionality also depends on those responses remaining intelligible. Philip O'Toole's 9 September announcement describes adding CircleCI testing to the Go client. The completed testing commit on 10 September UTC runs that work with a real rqlite container.

The announcement credits raindog308 as the library's original author and describes the goal as maintaining basic functionality as use grows. That is an appropriately limited claim. A CI job establishes a repeatable way to execute the checked-in tests. Its meaning depends on the server version, configuration and assertions those tests actually use.

I value rqlite's relatively small operational footprint. A language client should preserve that usefulness by making ordinary access reliable, including the discovery needed to find the database's leader. Exercising the client against a server is useful evidence at that integration point.

The server is part of the test environment

The configuration at the completed commit declares a CircleCI version 2 job. It uses a Go 1.12 image and an rqlite/rqlite:4.5.0 image. Its steps check out the source, run go vet . and execute the package tests with a sixty-second timeout.

docker:
  - image: circleci/golang:1.12
  - image: rqlite/rqlite:4.5.0

The server version is explicit in this job. That makes the configuration a concrete compatibility target for the client tests. It does not establish behavior against every historical or future rqlite release. Changing the container tag would change part of the tested environment, even if no client source changed.

The historical README says the tests require a running cluster. It documents the default server endpoint as localhost on port 4001 and a default test table. Environment variables can override the endpoint and table. The container supplies the server dependency expected by that existing testing model.

Opening a connection includes discovery

The client deliberately provides its own interface rather than a database/sql driver. Its README describes familiar operations such as Open, QueryOne and result iteration, while retaining rqlite-specific access to leader and peer information. Similar method names do not make the connection lifecycle identical to the standard database interface.

In particular, the documented Open operation obtains cluster information immediately. The README also requires the status permission when access control is enabled because discovery uses server status. An application can consequently have permission to query data yet still lack a permission required by the client's discovery process. A test of opening the connection exercises an API relationship beyond query execution alone.

The cluster initialization test makes that behavior observable. It opens a connection, requests the leader and requests peers. Errors fail the test, and empty leader or peer results fail it as well. These checks can expose a client that connects to HTTP successfully but misinterprets the cluster metadata it receives.

Familiar iteration has a different transport

The README explains that rqlite results reach the client as JSON and that the client presents iteration methods over them. It also states that results enter memory immediately because the server does not support iterative fetching. Calling Next therefore does not imply that every step retrieves another row from the server.

This is a useful example of why a client needs its own behavioral tests. An iterator must still move through decoded results correctly and expose values using the promised API. Its familiar appearance cannot substitute for verifying that behavior. The HTTP response, JSON conversion and iteration logic all participate in what an application eventually reads.

Transaction behavior also differs from a conversational transaction API. The README explains that rqlite accepts transaction statements together as one batch. A caller cannot start a transaction, send statements in separate later requests and finally commit it through this client model. The library's dedicated interface reflects those server constraints.

Interpret the job's evidence narrowly

The configuration names one server container. That is enough to support the basic integration exercised by the job, but the file alone does not demonstrate a multi-node partition or leadership-failure scenario. Claims about those cases require corresponding setup and assertions. Likewise, the historical README explicitly lists HTTPS as not yet tested, so this change should not be presented as complete transport qualification.

I prefer this concrete testing step to an unsupported claim of general compatibility. The CI job fixes a Go environment and server image, then runs the client's existing tests against them. Successful cluster initialization checks that the client can obtain nonempty leader and peer information from the server used by that job, which is a specific and useful condition for ordinary database access.