Concourse pipelines allow for use of YAML anchors and aliases. They find application in eliminating repetition of structured parameters, such as supplying a set of credentials to tasks, like in the boto3 example

Reusing AWS credentials for use in boto3

aws_credentials: &common_params
  AWS_ACCESS_KEY_ID: ((aws_access))
  AWS_SECRET_ACCESS_KEY: ((aws_secret))
  AWS_DEFAULT_REGION: ((aws_region))
  AWS_SECURITY_GROUP:

jobs:
  - name: deploy-elasticbeanstalk
    plan:
    - task: deploy-eb
      file: code-repo/ci/tasks/elasticbeanstalk/deploy/task.yml
      params:
        TASK_SPECIFIC_PARAM1: one
        TASK_SPECIFIC_PARAM2: another
        <<: *common_params
    - task: update-cloudfront
      file: code-repo/ci/tasks/cloudfront/update/task.yml
      params:
        TASK_SPECIFIC_PARAM1: asdf
        <<: *common_params

Structured data in env variables

A very useful feature in concourse is the serialization of YAML passed to an env variable into JSON. It's a very convenient way to pass structurd data as parameters to tasks.

Running the job in the pipeline from the following example results in a jq-formatted config output:

cluster_config: &cluster_config
  elasticsearch_ips:
  - 192.168.1.11
  - 192.168.1.22
  application_ips:
  - 192.168.1.33
  - 192.168.1.44

jobs:
  - name: display-config
    plan:
    - task: display-json
      privileged: true
      config:
        platform: linux
        image_resource:
          type: registry-image
          source:
            repository: oozie/vmware-aws
        params:
          CONFIG:
            <<: *cluster_config
        run:
          path: bash
          args:
          - -c
          - |
            echo "${CONFIG}" | jq .

Task output:

selected worker: e8d1e7e3b3b4
{
  "application_ips": [
    "192.168.1.33",
    "192.168.1.44"
  ],
  "elasticsearch_ips": [
    "192.168.1.11",
    "192.168.1.22"
  ]
}