thoughtbot--factory_bot/.travis.yml

rvm:
  - 2.5
  - 2.6
  - 2.7
  - jruby-9.2.8.0
  - ruby-head
before_install:
  - gem update --system
  - gem update bundler
  - gem cleanup bundler
install: "bundle install --jobs 8"
script: "bundle exec rake"
gemfile:
  - gemfiles/5.0.gemfile
  - gemfiles/5.1.gemfile
  - gemfiles/5.2.gemfile
  - gemfiles/6.0.gemfile
  - gemfiles/master.gemfile
matrix:
  fast_finish: true
  allow_failures:
    - rvm: ruby-head
    - gemfile: gemfiles/master.gemfile
branches:
  only:
    - master

sudo: false
cache: bundler
Bring back travis and try their gemfile option 2011-07-29 18:19:30 -04:00			`rvm:`
Test with Rails 5.2 (#1146) * Appraise with Rails 5.2 * Drop specific tiny versions for Ruby This will reduce churn on this file as we try to keep up to date with TEENY Ruby releases. Travis installs Ruby via rvm with the --fuzzy flag. They also keep up to date with the latest releases, so --fuzzy will likely always give us the latest TEENY release. 2018-06-17 09:08:17 -04:00			`- 2.5`
Run CI on Ruby 2.6 2019-01-04 22:26:58 -05:00			`- 2.6`
Test with Ruby 2.7 2020-01-17 15:05:35 -05:00			`- 2.7`
Get default strategy registration working on JRuby fixes #1331 The commit avoids a bug in JRuby, and adds JRuby back to the test matrix so we can catch regressions in the future. 2019-10-02 18:55:51 -04:00			`- jruby-9.2.8.0`
Update travis config 2016-10-01 17:44:34 -04:00			`- ruby-head`
Update rubygems on travis-ci.org before running dependency installation REE will fail to install Rails 3.2 gems w/o rubygems update. 2012-01-29 10:56:37 -05:00			`before_install:`
			`- gem update --system`
Update bundler before in Travis CI builds Builds are broken because the `bundler` version that Travis CI automatically uses at this time (`1.7.6`) is coming across an error that was fixed in a later version/release. Having an outdated version of `bundler` in the Travis CI builds is an ongoing issue and this is currently the easiest work-around. See: * https://github.com/bundler/bundler/issues/3558 * https://github.com/travis-ci/travis-ci/issues/3531 [fixes #846] 2015-12-07 19:26:04 -05:00			`- gem update bundler`
Run against Ruby 2.3 on Travis 2016-03-30 16:50:36 -04:00			`- gem cleanup bundler`
Bundle install with jobs 2016-04-01 05:19:46 -04:00			`install: "bundle install --jobs 8"`
Improve default rake task by removing appraisal 2016-02-05 10:09:50 -05:00			`script: "bundle exec rake"`
Bring back travis and try their gemfile option 2011-07-29 18:19:30 -04:00			`gemfile:`
Appraise against Rails 5.0.0.beta Why? With Rails' upcoming release, test against the latest beta of Rails 5. 2016-02-05 15:04:57 -05:00			`- gemfiles/5.0.gemfile`
Update Ruby and Rails versions tested (#1088) Add Ruby 2.4.2 and Rails 5.1, and update Ruby 2.2 and 2.3 patches. 2018-02-01 09:37:48 -05:00			`- gemfiles/5.1.gemfile`
Test with Rails 5.2 (#1146) * Appraise with Rails 5.2 * Drop specific tiny versions for Ruby This will reduce churn on this file as we try to keep up to date with TEENY Ruby releases. Travis installs Ruby via rvm with the --fuzzy flag. They also keep up to date with the latest releases, so --fuzzy will likely always give us the latest TEENY release. 2018-06-17 09:08:17 -04:00			`- gemfiles/5.2.gemfile`
Test against activerecord 6.0 2019-01-30 21:19:05 -05:00			`- gemfiles/6.0.gemfile`
Run travis against Rails master (#1388) This will allow us to address any deprecations and incompatibilities before new versions of Rails are released, making it easier for folks to upgrade their applications. I am ignoring the gemfile.lock here because I want CI to always run against the latest master, not a specific commit. I am allowing failures on Travis because I don't want these failures to block people's PRs (like what we do with ruby-head). 2020-04-29 19:09:11 -04:00			`- gemfiles/master.gemfile`
Appraise against Rails 5.0.0.beta Why? With Rails' upcoming release, test against the latest beta of Rails 5. 2016-02-05 15:04:57 -05:00			`matrix:`
			`fast_finish: true`
Update travis config 2016-10-01 17:44:34 -04:00			`allow_failures:`
			`- rvm: ruby-head`
Run travis against Rails master (#1388) This will allow us to address any deprecations and incompatibilities before new versions of Rails are released, making it easier for folks to upgrade their applications. I am ignoring the gemfile.lock here because I want CI to always run against the latest master, not a specific commit. I am allowing failures on Travis because I don't want these failures to block people's PRs (like what we do with ruby-head). 2020-04-29 19:09:11 -04:00			`- gemfile: gemfiles/master.gemfile`
Only build master in travis 2011-09-12 15:58:03 -04:00			`branches:`
			`only:`
			`- master`
Cache Bundler on Travis http://docs.travis-ci.com/user/workers/container-based-infrastructure/ With Container based CI, public projects can cache the results of bundle install 2015-02-20 13:18:00 -05:00
			`sudo: false`
			`cache: bundler`