Fuci::Travis

Run Travis failures locally. A Fuci server extension.

Add this line to your application's Gemfile:

gem 'fuci-travis', '~> 0.4'

And then execute:

$ bundle

Bundling the binstub is highly recommended:

$ bundle binstubs fuci-travis

To configure itself, fuci-travis looks for a file called ".fuci-travis.rb" in your project's root directory. You should create that file and configure fuci-travis there. The configuration must include your Travis access token. Therefore, you should include ./.fuci-travis.rb in .gitignore.

That configuration file should include a call to Fuci::Travis.configure with a block that sets your access token and other configurations.

fuci-travis ships with the Travis CI Client which includes the Travis CLI. You'll use the Travis CLI to get your access token.

On the command line, log into Travis via Github OAuth:

$ travis login

Then get your token:

$ travis token
# Your access token is <access token>

Configure fuci-travis with your access token as a string in .fuci-travis.rb:

Fuci::Travis.configure do |fu|
  fu.access_token = '<access token>'
end

This is the same as above, but uses the Travis CLI --pro flag.

On the command line, log into Travis via Github OAuth:

$ travis login --pro

Then get your token:

$ travis token --pro
# Your access token is <access token>

Then, in .fuci-travis.rb, configure fuci-travis with your access token as a string and set pro to true:

Fuci::Travis.configure do |fu|
  fu.pro          = true
  fu.access_token = '<access token>'
end

If you push to a dedicated ci branch to check your changes before merging them into master, set that branch as the default in the configuration:

Fuci::Travis.configure do |fu|
  fu.default_branch = 'my-ci'
  fu.access_token   = '<access token>'
end

Fuci tester plugins should return two things: Whether a failed build has failed with a specific testing framework (e.g. RSpec, Cucumber) and the command-line command that runs those specific failures. As of now, Fuci ships with RSpec and Cucumber tester plugins. If you want to add custom testers, add them in the configuration:

Fuci::Travis.configure do |fu|
  fu.add_testers Fuci::Spec, Fuci::Jasmine
  fu.access_token = '<access token>'
end

See the base Fuci repo for more information on custom testers.

See the base Fuci repo for command-line options native to Fuci.

Run your latest ci failures locally:

$ fuci

fuci will fetch the CI failures from the default branch declared in your configuration. If no default branch is declared , fuci will fetch the CI failures from the branch of the same name as your current local branch.

Call fuci with a branch name to run a specific branch's failures branch. For example, this will run the failures from the latest master build on your local code:

$ fuci master

$ fuci --pull-request
$ # or
$ fuci -p

Those will find the latest build triggered by a pull request from the remote branch of the same name as your current local branch. Use a branch name as an argument to run failures specific branch's pull request:

$ git checkout another_branch
$ fuci -p my_feature_branch_that_breaks_things

• Build configurations with more than one job. Multiple jobs typically mean test runs in different environments. Switching between these environments locally and automatically can be tricky and may not even be desirable.

• Rake task that bootstraps project with gitignore'd config file, complete with access_token and pro flag
• Support for multiple jobs per build (?)

1. Fork it
2. Create your feature branch (git checkout -b my-new-feature)
3. Commit your changes (git commit -am 'Add some feature')
4. Push to the branch (git push origin my-new-feature)
5. Create new Pull Request