Tasks

As you’ve seen in the configuration files, most ContinuousPipe configuration is about tasks. By breaking down the configuration into smaller tasks, they can be composed together to create a flexible workflow.

Inbuilt Tasks

ContinuousPipe has several inbuilt tasks that can be included in your workflow:

  • build: Will build and push your Docker image
  • deploy: Will deploy your service(s) to a cluster
  • run: Will run some commands inside a deployed context
  • wait: Will wait for some other GitHub statuses
  • manual_approval: Will suspend the task sequence until manual approval is given to the tide in the ContinuousPipe console
  • webhook: Will trigger a webhook for use by a third party service

Conditional Tasks

Reference

Filter expressions use the Symfony expression language.

You can filter the execution of each task by using the filter configuration in the YAML file. This can be done with an expression, as you can see in the following sample configuration:

tasks:
    images:
        build:
            # ...

        filter:
            expression: code_reference.branch == 'master'

The expression has access to the tide related context objects code_reference and pull_request.

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

The pull_request context object contains the following properties:

Property Type Description
labels array An array of the labels on the pull request
title string The title of the pull request
number number The number of pull requests

Retrieving Task Information

Within a tasks section, you can get access to information that comes from previous tasks. You need to use named tasks to expose the task information.

The deploy task exposes a services context object which is an array of objects indexed by key. The key is the name of the deployed service. Each object will contain the following properties:

Property Type Description
created boolean If the service was created
updated boolean If the service was updated
deleted boolean If the service was deleted

For example, if you want to run a setup script, but only when the database is created, you can use the following configuration:

tasks:
    deployment:
        deploy:
            cluster: my-cluster

            services:
                mysql:
                    specification:
                        source:
                            image: mysql

    fixtures:
        run:
            # ...

        filter:
            expression: tasks.deployment.services.mysql.created