New feature: YAML patterns for pipelines

Two years ago we introduced configuration-by-code to Buddy. The feature allows you to change pipeline configuration simply by updating a YAML file and commmitting it to the repository.

Today, in response to numerous requests from our users, we're adding the option to define multiple pipelines with one definition.

How it works

So far, if you wanted to have 2 same pipelines for 2 separate branches, you had to configure it individually for each branch:

yaml
- pipeline: "test"
  trigger_mode: "MANUAL"
  ref_name: "master"
  ref_type: "BRANCH"
  trigger_condition: "ALWAYS"
  actions:
...
- pipeline: "test"
  trigger_mode: "MANUAL"
  ref_name: "stage"
  ref_type: "BRANCH"
  trigger_condition: "ALWAYS"
  actions:
...

Now you can do it with one definition by replacing ref_name with the variable $BUDDY_REF:

yaml
- pipeline: "test ${BUDDY_REF}"
  trigger_mode: "MANUAL"
  ref_name: "${BUDDY_REF}"
  ref_type: "BRANCH"
  trigger_condition: "ALWAYS"
  actions:
...

Once defined, the YAML will create a separate pipeline for each branch, tag or pull request to which it's been pushed.

Advantages of YAML patterns

Creating a single pattern for the whole setup is especially useful for testing pipelines, allowing you to run exactly the same tests for every branch in the repository. Until now, it was only possible by creating a single pipeline with a wildcard.

The difference between the wildcard and the YAML pattern, however, is that the first one is limited to one pipeline (executions for each branch/pull request are queued and run one be one), whereas the second one creates multiple pipelines that can be run in parallel which drastically shortens the testing time.

Another use case are deployment pipelines and pipelines using trigger conditions based on changesets. Since every branch/pull request has its own pipeline, the changesets are counted between executions for the specific ref.

What's next

We are currently working on master pipelines that could be inherited by other pipelines in the project.

Since Buddy is 100% customer driven, feel free to share your suggestions on implementing this feature, as well as any other feature or improvement you'd like to see in our service – a single use case from our client is worth more than hours of "how-to" discussions within our team :)