Complex Pipeline Triggers

Features Requests
1

Hi,

Buildkite is very awesome. However, I think it has one key area that it is quite limited compared to some alternatives like GitHub actions.

GitHub Actions has a wealth configuration options that determine when a pipeline will run. See https://docs.github.com/en/actions/reference/workflow-syntax-for-github-actions#on

This includes:

  • Pull Request vs push
  • Branch wildcard matching
  • Branch wildcard ignoring
  • Changed path wildcard matching
  • Changed path wildcard ignoring
  • Tag wildcard matching
  • Tag wildcard ignoring

In particular the path aspect is extremely useful. For example, I only want to push an updated buildkite agent docker image in the case that dockerfiles/Buildkite has changed. Or I only want to redeploy my project infrastructure if terraform/project/** has changed.

Buildkite works perfectly when you have lots of small microservice repos, however these days there is a continual movement towards monorepos which buildkite seems less geared towards.

What about plugins? Currently the most stared plugin (showing this is a common issue) is https://github.com/chronotc/monorepo-diff-buildkite-plugin .

It has the following limitations compared to GitHub actions first party support.

  • Only supports simple path matching.
  • It is tricky to compare all the commits pushed / merged. It has some solutions though https://github.com/chronotc/monorepo-diff-buildkite-plugin#diff-optional
  • Similarly, ideally you probably want to run a build if the path has changed since the last successful build, not just in the current push. The above link has a solution, but it is clunky and manual. Actually I’m not sure if github actions supports this.
  • It requires having a ‘Triggering pipelines’ build.
  • It is very boilerplatey.

What would buildkite support look like?

I would suggest adding a section to pipeline.yml eg.

triggers:
  push:
    paths:
      - '**.js'
    branches-ignore:
      - 'releases/**-alpha'  
    tags-ignore:
      - v1.*           # Push events to tags v1.0, v1.1, and v1.9

The agent would evaluate and apply this on every webhook event before deciding to initiate a run.

Thanks for listening :slight_smile: