Skip to main content

Using Buildkite for Pull Request verification

Pull request verification pipelines, or “verify pipelines,” are a form of general purpose pipelines that are triggered automatically as a response to a pull request that is opened, synchronized, or merged against a GitHub repository. They are intended to replace the usage of services like TravisCI and AppVeyor in validating whether or not a pull request is safe to merge. Like general purpose pipelines, but unlike most other pipelines managed by Expeditor, verify pipelines consist primarily of steps composed by the project maintainers. This means that individual project maintainers are responsible for ensuring that their pipelines continue to function as expected.

What differentiates verify pipelines from other general purpose pipelines is they are a named pipeline. When you name your pipeline verify or prefix the pipeline with verify/ (e.g. verify/public or verify/private) that triggers special conditions in Expeditor that configure that pipeline in a certain way.

  • Builds on your verify pipelines are triggered directly from GitHub. Expeditor leverages special Buildkite configuration that allows verify pipelines to behave in a manner similar to services like TravisCI.
  • Build results are shared on the pull request as a status check. This mirrors the behavior seen with other tools like TravisCI.

There are three common patterns for creating verify pipelines:

  • Public Verify Pipelines. For open source projects, unless you need access to resources behind Chef's VPN like Vault, we recommend that you use a single public verify pipeline.
    ---
    pipelines:
      - verify:
          definition: .expeditor/verify.pipeline.yml
          public: true
  • Private Verify Pipelines. For closed source projects hosted on a private GitHub repository, we recommend using the default private visibility for your verify pipeline.
    ---
    pipelines:
      - verify:
          definition: .expeditor/verify.pipeline.yml
  • Public and Private Verify Pipelines. For some open source projects, like chef/automate, you may find it beneficial (or sometimes necessary) to have both a public and a private verify pipeline. Something to keep in mind however is that, for security purposes, builds triggered by pull requests from non-Chef employees to private pipelines are blocked by default. If an open source contributor creates a pull request on a project with a private pipeline, Expeditor will block the execution of the verify pipeline until a Chef employee validates the contents of the change and unblocks the pipeline via the Buildkite UI.
    ---
    pipelines:
      - verify/public:
          definition: .expeditor/verify_public.pipeline.yml
          public: true
      - verify/private:
          definition: .expeditor/verify_private.pipeline.yml

Please refer to the general purpose pipelines document for guidance on how to iterate on your verify pipeline.