Build Triggers

As noted in the Yaml Spec, the .chipperci.yml file can define what actions trigger a build in the on: section.

# Decide what events trigger a build
on:
  # "push" is a regular, old commit.
  # This will build on push to any branch
  # Note that `.*` is a regex!
  push:
    branches: .*

  # This will build on PR open, re-open, and update
  # (Updates are when commits are pushed to a PR)
  # Here we say to only build when a PR is opened/reopened/updated 
  # and the branch being pushed to
  # is feature/.* or bug/.*
  pull_request:
    branches:
      - feature/.*
      - bug/.*

  # This will build on the (re)creation of any
  # tag that starts with `v`
  tags:
    - v.*

When using the .chipperci.yml file, these triggers are the only way to decide what actions trigger a build. The "Build Restrictions" settings are ignored.

Omitting the on: section within the .chipperci.yml file will build all commits, except for Pull Request actions (for backwards compatibility).

Build Restrictions

When not using a .chipperci.yml file, you can enable "Build Restrictions" within. a project's settings. This allows you to whitelist or blacklist which branches should (or should not) be built.

Tags

By default, Chipper CI will build when tags are pushed to your repository. This often means that the same commit sha will be built more than once.

This is useful if you want to perform certain actions on a tag build, such as kicking off a deployment (example here).

You can disable tags from generating a build here.

Regular Expressions

Regular expressions are supported. These are the same both in the .chipperci.yml file and the project settings Build Restrictions.

Here are some examples you may want to use:

• feature/.* - matches branches such as feature/my-feature
• dependabot/.* - matches branches such as dependabot/some-package/some-version
• foo[0-9]*-bar - matches branches such as foo012345-bar
• foobar - exact match for branch foobar

Note that all branches are normalized to regex /^your-input$/ and run through preg_match_all. For example, a branch feature/.* will be tested as preg_match_all('/^feature\/.*$/', $branch).

We do not use the i modifier, so regex is case-sensitive.

You can test your regex out here.

Skipping via Commit Messages

If the following are present in the commit message of a build, than the commit will be ignored, and the build will be silently skipped:

• --skip-ci
• --ci-skip
• [skip ci]
• [ci skip]

This helps with other CI/CD apps, such as StyleCI, which may create new commits and thus generating twice the builds within Chipper CI.

Forcing via Commit Messages

You can also force a commit to trigger a build. If the build triggers in the .chipperci.yml file would normally ignore a build, you can add the following to your commit message to force Chipper to run a build for the commit:

• [force ci]
• --force-ci