OVH CDS: pipelines chained into workflows on Postgres and Redis

The workflow sits above the pipeline, not beside it

CDS makes the pipeline a component you reuse rather than a thing you copy. A pipeline is sequential stages, and each stage holds one or several concurrent jobs that stay isolated from each other. A pipeline starts with a context of zero or one application and zero or one environment. The workflow is the layer above that: it chains pipelines and can connect them with joins or forks. The same pipeline can appear several times inside one workflow, bound to a different application or environment each time, so a build pipeline and a deployment pipeline stay two objects to maintain even when a company runs hundreds of applications. The idea is one workflow builder that covers a whole microservice stack rather than a separate CI job list per service.

One git repository maps to one CDS application

The integration with GitHub, GitLab and Bitbucket Server is described as two way, and the mapping rule is strict: one git repository equals one CDS application. A push starts a build, and CDS pushes the commit status back to the git host as Building, Success or Failed. A single workflow can also clone from several different repositories, and a workflow is allowed to reference no repository at all when nothing in it needs one. Branch patterns drive which pipelines run, so a pattern can send dev/* branches to staging and master to prod. The built in behaviour, though, is to launch the whole workflow on every git commit, and the README says this can be altered using run conditions. Teams migrating from a tool that builds a single pipeline per branch will get more work per push until they write those conditions.

Workflow templates standardise a company, and hide who changed what

A workflow template is a reusable workflow definition that any user can create and maintain, either as code or from the UI. The payoff for an organisation is bulk updating a set of workflows with a single action, which is how a predefined catalog of workflows standardises test and deployment practice across teams. The cost is a second layer of indirection: a template is not the workflow that runs, so a reader who opens a running workflow in the UI has to work out which template produced it and what the original author changed.

The stack needs three services before cdsctl is useful

Getting a local CDS up is a database, a cache and a search cluster, and the project's own compose file lays out what each one expects. Postgres gets the cds user, the cds password and the cds database, plus a separate cdn schema created by the init service. Redis is started with a password and with saving turned on. The migration service runs the engine binary twice, once against the public schema and once against cdn, so the schema layout matters to anyone restoring a copy. The README recommends regular database backups, but it also documents persisted build artifacts in Swift or a filesystem. Inventory and back up any configured artifact storage as well, and test restoration for the deployment. Expect the same three services in any environment you run yourself, including the ones you build out of this repository.

version: '3'

services:
  cds-db:
    image: postgres:${PG_VERSION:-14.0}
    environment:
      POSTGRES_PASSWORD: cds
      POSTGRES_USER: cds
      POSTGRES_DB: cds
    volumes:
      - cds-postgres-volume:/var/lib/postgresql

  cds-cache:
    image: redis:alpine
    command: redis-server --requirepass cds --save 60 1
    restart: always
    volumes:
      - cds-redis-volume:/data

The shipped compose file refuses production twice in its own header

The first lines of docker-compose.yml carry a warning that the configuration is for local development and testing and must not be used to deploy CDS in production. Reading further down shows why that warning is not just caution. The database password, the cache password and the OpenSearch initial admin password are all written into the file, the security plugin on the search node is disabled, and the search node runs single node discovery with a 512 megabyte heap. Anyone who copies this file outward inherits those defaults unless every one of them is changed. The compose file also pins OpenSearch to the latest tag, so two people starting it on different days can get different images.

Building from source means four target systems and a version string from git

The Makefile targets windows, darwin, linux and freebsd by default, and amd64 and arm64, and it builds the engine, the worker, cdsctl and the UI before packaging. The version is not stored in a file: it falls back to the word snapshot unless CDS_VERSION is set, and the more precise string comes from git describe with the leading v stripped. The Dockerfile that packages all of it runs on alpine, copies the engine, cdsctl and worker binaries plus the sql and ui tarballs into /app, untars the documentation next to the UI files, adds an unprivileged cds user and ends with the engine binary as the container command.

TARGET_OS = $(if ${OS},${OS},windows darwin linux freebsd)
TARGET_ARCH = $(if ${ARCH},${ARCH},amd64 arm64)
VERSION := $(if ${CDS_VERSION},${CDS_VERSION},snapshot)
GIT_DESCRIBE := $(shell git describe --tags)
GIT_VERSION := $(if ${GIT_DESCRIBE},${GIT_DESCRIBE:v%=%},0.0.0-0-snapshot)

A contributor therefore needs the Go version the module declares, which is 1.26.

Where CDS stops: no host for your jobs and a one line backup answer

Two boundaries are worth knowing before a team adopts it. First, the README recommends database backups, but also says build artifacts can persist in Swift storage or a filesystem. Include configured artifact storage in the recovery plan and verify the restore procedure for your deployment. Second, its jobs can start ephemeral Service Prerequisites, which is the mechanism for attaching a redis or a PostgreSQL container to a test job. The project reports being used in production at OVH since 2015 with more than 7M workers launched per year, and that scale belongs to the company running it, not to a fresh install. The latest tagged release listed on the repository is v0.54.1 from April 2024 while the default branch is still being pushed to, so pinning a tag and following the branch are two different things.

Editorial conclusion

CDS makes sense for teams that already think in workflows rather than single pipelines, and that want the yaml to live in the same git repository as the code. Before committing, check the version you would install against the compose file, because the stack it needs is three services and the file in the repository is explicitly not for production. Teams that only want hosted runners and a config file in their repository will find more setup than they get.

Frequently asked questions

Official sources

1. License: BSD-3-Clause
2. ovh/cds on GitHub
3. Project website
4. README
5. Releases