travis-ci/travis-ci — Issue #435: Allow patterns in branch specifications
Author: lloyd
Created: 2012-02-28 17:00:51+00:00
State: open

Currently in `.travis.yml` you can specify a whitelist of branches to build, like:

branches:
only:
- dev
- beta
- prod

This is good, however for projects that use branches for different types of activities, it's not always sufficiently expressive. For instance, [browserid](https://github.com/mozilla/browserid) has multiple different classes of branches:

* **development** - This is `dev` which is the current integration branch for new development - tests should always pass here
* **trains** - branches that have split off of dev, are in QA, and will roll into production once vetted. Tests must always pass here - they are named `/^train-\d{2}-\d{2}-\d{4}$/` (i.e. `train-2012.02.02`
* **bugfix/feature** - branches that are in progress snapshots of development to fix an issue or implement a new feature - they are named `/^issue-\d+$/` - tests must pass only when implementation is complete and a pull request is issued.
* **experimental/usertest** - branches that are exploring potential features, either in code or are sufficiently implemented to deploy and A/B test. tests may or may not pass at the discretion of the developer.

(you can [read a bunch more](http://lloyd.io/applying-gitflow) about our dev flow if you care)

If patterns were allows inside the `branches` specification, the following would support a branching model like this as it exists today:

branches:
only:
- dev
- /^train-.*/

Some alternatives to baking this feature directly into travis would involve changes to our development flow:

1. manually update `.travis.yml` every time a train is forked to include that train
2. institute a convention that only branches with passing tests are allowed in the repository - that is feature branches ready for merge, the main integration branch (`dev`), and trains. All other dev should occur in forks as a different user

For me, it seems like allowing patterns is a small and localized change that can make travis-ci work out of the box for more projects with different development flows. It makes the `branches:` configuration much more flexible.

Sorry for the novel, thanks for considering.