Using containers in Bitrise Workflows

This example shows a simple use of the container property to enable Workflows to use different execution environments.

We test our application using two different versions of Node.js, using the public node images from Docker Hub. We also run a custom Python script to validate our changes before testing them.

trigger_map:
- push_branch: "master"
  workflow: ci
- pull_request_target_branch: "master"
  workflow: ci

workflows:
  _clone:
    steps:
      - git-clone@8: {}

  test_node_21_6:
    container:
      image: node:21.6
    steps:
    - script:
      title: NPM install
      inputs:
      - content: npm ci
    - script:
      title: NPM test
      inputs:
      - content: npm test
      
  test_node_18_19:
    container:
      image: node:18.19
    steps:
    - script:
      title: NPM install
      inputs:
      - content: npm ci
    - script:
      title: NPM test
      inputs:
      - content: npm test
      
  ci:
    container:
      image: python:3.13
    before_run:
    - _clone
    steps:
    - script:
      title: Validate our changes using a custom python script
      inputs:
      - content: python3 validate.py
    after_run:
    - test_node_21_6
    - test_node_18_19

In this example, the ci Workflow is triggered on push or pull request events against the master branch. When a build is triggered:

workflows:  
  e2e-tests:
    container:
      image: node:21.6
    services:
      postgres:
        image: postgres:16
        envs:
        - POSTGRES_USER: postgres
        - POSTGRES_DB: bitrise
        # You can reference Bitrise secrets here, e.g: $POSTGRES_PASSWORD
        - POSTGRES_PASSWORD: password
        ports:
        - 5432:5432
        options: >-
          --health-cmd pg_isready
          --health-interval 10s
          --health-timeout 5s
          --health-retries 5
      redis:
        image: redis:7
        ports:
        - 6379:6379
        options: >-
          --health-cmd "redis-cli ping"
          --health-interval 10s
          --health-timeout 5s
          --health-retries 5
    envs:
    - POSTGRES_DSN: "postgres://postgres:password@postgres:5432/bitrise"
    - REDIS_DSN: "redis://redis:6379/1"
    steps:
    - script:
        title: e2e tests
        inputs:
        - content: |
            npm run e2e-tests

The example configuration defines a Workflow called e2e-tests.

This Workflow uses service containers to enable a more advanced integration test scenario using postgres and redis. It also utilizes the Workflow container to run the tests in a Node environment.

There are two services defined: postgres and redis. Each service is configured to have healthchecks using the options parameter. The CLI will respect those options and only start the execution of the Workflow’s Steps once every service reports healthy.

Each service is exposed on a port, but as we are utilizing Workflow containers, they will be accessible using their name postgres:5432 and redis:6379, respectively.

Once the services are ready, the Workflow will execute the npm run e2e-tests command, which can utilize the environment variables POSTGRES_DSN and REDIS_DSN defined by the Workflow to connect to services.