<commit_before># Fuci::Travis
[![Build Status](https://travis-ci.org/davejachimiak/fuci-travis.png?branch=master)](https://travis-ci.org/davejachimiak/fuci-travis)

Run Travis failures locally. A [Fuci](https://github.com/davejachimiak/fuci) server extension.

## Installation

Add this line to your application's Gemfile:

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

And then execute:

    $ bundle

Bundling the binstub is highly recommended:

    $ bundle binstubs fuci-travis

## Configuration
### Configuration file

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.

### Access tokens

fuci-travis ships with the
[Travis CI Client](https://github.com/travis-ci/travis) which includes
the Travis CLI. You'll use the Travis CLI to get your access token.

#### Travis for public repositories

On the command line, log into Travis via Github OAuth:
```sh
$ travis login
```

Then get your token:
```sh
$ travis token
# Your access token is <access token>
```

Configure fuci-travis with your access token as a string in
.fuci-travis.rb:
```ruby
Fuci::Travis.configure do |fu|
  fu.access_token = '<access token>'
end
```

#### Travis for private repositories

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

On the command line, log into Travis via Github OAuth:
```sh
$ travis login --pro
```

Then get your token:
```sh
$ 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**:
```ruby
Fuci::Travis.configure do |fu|
  fu.pro          = true
  fu.access_token = '<access token>'
end
```

### Default branch

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:
```ruby
Fuci::Travis.configure do |fu|
  fu.default_branch = 'my-ci'
  fu.access_token   = '<access token>'
end
```

### Adding custom tester plugins

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 only an RSpec tester plugin. If you want to add custom
testers, add them in the configuration:
```ruby
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.

## Usage

See the
[base Fuci repo](https://github.com/davejachimiak/fuci#native-command-line-options)
for command-line options native to Fuci.

Run your latest ci failures locally:
```sh
$ fuci
```
`fuci` will fetch the CI failures from the default branch declared in
your configuration. If no default branch is declared in the
configuration, `fuci` will fetch the CI failures from the branch of the
same name as your current local branch.

To run a specific branch's failures branch, call `fuci` with the branch.
For example, this will run the failures from the latest master build
on your local code:
```sh
$ fuci master
```

## Known incompatibilities/weirdnesses
* 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.

## TODO
* Run failed tests from last pull request with some command-line option.
* Rake task that bootstraps project with gitignore'd config file,
complete with access_token and pro flag
* Support for multiple jobs per build (?)

## Contributing

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<commit_msg>RDD pull request option<commit_after># Fuci::Travis
[![Build Status](https://travis-ci.org/davejachimiak/fuci-travis.png?branch=master)](https://travis-ci.org/davejachimiak/fuci-travis)

Run Travis failures locally. A [Fuci](https://github.com/davejachimiak/fuci) server extension.

## Installation

Add this line to your application's Gemfile:

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

And then execute:

    $ bundle

Bundling the binstub is highly recommended:

    $ bundle binstubs fuci-travis

## Configuration
### Configuration file

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.

### Access tokens

fuci-travis ships with the
[Travis CI Client](https://github.com/travis-ci/travis) which includes
the Travis CLI. You'll use the Travis CLI to get your access token.

#### Travis for public repositories

On the command line, log into Travis via Github OAuth:
```sh
$ travis login
```

Then get your token:
```sh
$ travis token
# Your access token is <access token>
```

Configure fuci-travis with your access token as a string in
.fuci-travis.rb:
```ruby
Fuci::Travis.configure do |fu|
  fu.access_token = '<access token>'
end
```

#### Travis for private repositories

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

On the command line, log into Travis via Github OAuth:
```sh
$ travis login --pro
```

Then get your token:
```sh
$ 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**:
```ruby
Fuci::Travis.configure do |fu|
  fu.pro          = true
  fu.access_token = '<access token>'
end
```

### Default branch

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:
```ruby
Fuci::Travis.configure do |fu|
  fu.default_branch = 'my-ci'
  fu.access_token   = '<access token>'
end
```

### Adding custom tester plugins

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 only an RSpec tester plugin. If you want to add custom
testers, add them in the configuration:
```ruby
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.

## Usage

See the
[base Fuci repo](https://github.com/davejachimiak/fuci#native-command-line-options)
for command-line options native to Fuci.

Run your latest ci failures locally:
```sh
$ 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:
```sh
$ fuci master
```

Run failures from your last build triggered by a pull request:
```sh
$ fuci --pull-request
```
or
```sh
$ fuci -pr
```

## Known incompatibilities/weirdnesses
* 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.

## TODO
* Run failed tests from last pull request with some command-line option.
* Rake task that bootstraps project with gitignore'd config file,
complete with access_token and pro flag
* Support for multiple jobs per build (?)

## Contributing

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
{'fraction_non_alphanumeric': 0.09328007518796992, 'fraction_numerical': 0.001644736842105263, 'mean_word_length': 4.320625, 'pattern_counts': {'":': 0, '<': 15, '<?xml version=': 0, '>': 17, 'https://': 10, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '431417', 'n_tokens_mistral': 2624, 'n_tokens_neox': 2583, 'n_words': 1130}