Configuration Files

There are three main configuration files that are needed to build a Docker image and set up ContinuousPipe deployments:

.
├── Dockerfile
├── continuous-pipe.yml
└── docker-compose.yml

Docker Build Configuration

The Dockerfile contains a series of commands that are combined to build a Docker image. See https://docs.docker.com/engine/reference/builder/ for full documentation.

Docker Compose Configuration

The file docker-compose.yml contains YAML configuration for the services, networks and volumes of a Docker image. See https://docs.docker.com/compose/compose-file/ for full documentation.

ContinuousPipe Configuration

The ContinuousPipe configuration is represented as a YAML file. The final configuration is the result of a merger of these different optional configuration sources:

  • The YAML stored on CP when configuring a flow
  • The YAML file named continuous-pipe.yml in your code repository
  • The YAML file named continuous-pipe.[branch].yml in your code repository

Tasks

The main objects of this configuration file are the tasks.

Each task has a name, so will sometimes be referred to as a “named task”. Tasks will run sequentially in the order they are defined.

Warning

It is recommended that all tasks are named as some features rely on this to make task information available to other tasks.

In the following example, you can see that we define build, deploy, and run tasks named images, deployment, and migrations respectively. They will operate in this order when a tide is run.

tasks:
    images:
        build:
            # ...

    deployment:
        deploy:
            # ...

    migrations:
        run:
            # ...

You will learn more about each task in the tasks overview section.

Variables

You can avoid copying and pasting by using variables inside your configuration files. The following example shows you how to prevent putting values inside your continuous-pipe.yml by using variables that are defined in the configuration stored in ContinuousPipe when configuring a flow.

# configuration in ContinuousPipe
environment_variables:
    - { name: CLUSTER, value: my-production-cluster }

# configuration in continuous-pipe.yml
tasks:
    # ...
    deployment:
        deploy:
            cluster: ${CLUSTER}

            # ...

Once the configuration files are merged, the variables are resolved. That means that the final configuration will contain the my-production-cluster value at the cluster key of the deployment task.

Conditional Variables

Reference

Conditions use the Symfony expression language.

If you need to change the value of the cluster, for instance depending on the branch name, you can use conditions:

environment_variables:
    - { name: CLUSTER, condition: 'code_reference.branch in ["production", "uat"]', value: my-production-cluster }
    - { name: CLUSTER, condition: 'code_reference.branch not in ["production", "uat"]', value: my-development-cluster }

The condition value is an expression. It has access to the tide related context object code_reference.

The code_reference context object contains the following properties:

Property Type Description
branch string The name of the branch
sha1 string The SHA1 of the given commit

Default Variables

You can use a defaults section to avoid variable duplication across tasks.

The following example shows a cluster variable being defined in two separate tasks:

tasks:
    initialise:
        run:
            cluster: my-cluster
            # ...
   deployments:
        deploy:
            cluster: my-cluster
            # ...

This can be rewritten using a defaults section as follows:

defaults:
     cluster: my-cluster

tasks:
    initialise:
        run:
            # ...
    deployments:
        deploy:
            # ...

The default cluster variable will now be used for both tasks instead.