With the release of GitLab 8.0, the previously separated products GitLab and GitLab CI merged and GitLab now ships with continuous integration. That allows developers to host their code and also run tests within a single application and ultimately trigger a deployment process.
When developing applications, you might write tests that save objects to a database. Using GitLab, you can certainly benefit from databases in test environments. GitLab handles databases as services and this guide will walk you through the setup to leverage RethinkDB within your tests.
RethinkDB Service for GitLab CI
GitLab automatically starts a build for every push to the project’s repository. It searches for a .gitlab-ci.yml file that contains the specifications and requirements for your test environment. Once your test environment is set up and available, the tests will be executed. The following snippet outlines a basic .gitlab-ci.yml for a Node.js project that makes use of RethinkDB during test runs:
image: node:4.4.4
services:
- rethinkdb:2.3.3
before_script:
- npm install
test:
script:
- npm test
As you can see, we’re pulling in an image of Node.js 4.4.4 and additionally use a RethinkDB service. Within GitLab, requirements besides the base image that contains the programming language runtime are defined as services and RethinkDB as a database counts into the services group. To run the tests, we’re benefiting from NPM’s scripts to install the required dependencies before running the actual tests.
The defined version for RethinkDB is an optional parameter. You can just specify the service like this:
service:
- rethinkdb
You’re also allowed to use the latest keyword or a specific version. Using latest will pull the currently latest available version of your service. Defining a specific version is important if you’re developing against a certain version and can’t update the database dependency due to whatever constraints.
service:
- rethinkdb:latest
# or
service:
- rethinkdb:2.3.2
Defining the RethinkDB service is half the battle. The other important piece is to know how to connect to the database from your application. The following section will walk you through the setup on how to connect to the RethinkDB instance within your tests.
Connect to RethinkDB for Testing
While spinning up your test environment, GitLab pulls the service containers and assigns hostnames following these rules:
- lowercase the service’s name
- everything after
:is stripped away - forward slashes get replaced by doubled underscores:
/will be__
That means, the RethinkDB service receives the hostname rethinkdb. You don’t need any further username or password. The database will listen for client connections on the default port 28015.
Depending what package you’re using to connect with RethinkDB, just pass rethinkdb and 28015 as the host and port.
var r = require('rethinkdb')
var config
if (env === 'test') {
config = {
host: 'rethinkdb',
port: 28015
}
}
r.connect(config, function(err, conn) {
if(err) throw err
// proceed with table creation or whatever :)
}
Adjust your configuration if you’re leveraging another RethinkDB client package, like the Thinky ORM.
Knowing the hostname for RethinkDB within the test environment does the trick to test your applications code properly backed by a database.
Outlook
This guide showed you how to use RethinkDB while testing your application in GitLab. GitLab’s build in support for services like MySQL, PostgreSQL, RethinkDB, Redis and any other services allows you to benefit from datastores within test environments. You’ve learned how to define RethinkDB as a service and how to define connection settings for test runs.
We appreciate feedback and love to help you if there’s a question in your mind. Let us know in the comments or on twitter @futurestud_io.
Make it rock & enjoy coding!
Additional Resources
- How to use other image services in GitLab
- How to access GitLab Services
- Thinky tutorials on Future Studio
- RethinkDB tutorials on Future Studio