This commit gets the Travis build passing by:
- Removing Rails 4.2 so we don't have to deal with bundler < 2 anymore
- Bumping to latest Rails versions
- Explicitly listing all gems that appear in the default Rails Gemfile
- Avoiding bootsnap and javascript, since they aren't relevant to these tests
Co-authored-by: alex <alexandr1golubenko@gmail.com>
We removed the call to `FactoryBot.load_definitions` in the
`after_initialize` hook in dcfc9f6 because the other changes in that
commit were causing us to sometimes call `FactoryBot.load_definitions`
after `FactoryBot.reload`.
We could have changed `FactoryBot.load_definitions` to
`FactoryBot.reload`, which is what this PR does, but it didn't seem
necessary at the time since all the tests were still passing.
We fixed a problem in 9b83f48 that was causing us to watch the root
directory of the project. This fix caused a test failure, but I ended up
changing the test in 2b7bca0 because it seemed like an unlikely
scenario.
This PR adds back the original test case. Although I do think it
unlikely, I would rather not risk making a breaking change in the next
patch release.
With factory_bot 5 we changed the official way to include factory_bot
definitions in an engine from using an initializer to using the
`config.factory_bot.definition_file_paths` configuration.
We left these tests with the initializer around because we wanted to
avoid breaking existing engines.
With #331 if none of the paths in
`config.factory_bot.definition_file_paths` exist we won't load any
factory definitions at all.
Before this PR this test was failing with #311 because none of the paths
in `config.factory_bot.definition_file_paths` existed, and so the
definition file in the engine never got loaded.
I am changing this test because there scenario is unlike. If somebody is
using factory_bot definitions from an engine, they will most likely have
their own factory definitions as well, defined in one of the
`config.factory_bot.definition_file_paths`.
If it turns out somebody is using factory_bot definitions from an engine
without also using definitions in their own project, there are a couple
of workarounds:
- Add an empty factory file (e.g. test/factories.rb)
- Manually call `FactoryBot.reload`
- Update the engine to use the official `config.factory_bot.definition_file_paths` instead of an initializer
Currently, the `sqlite3` in `Gemfile` generated by `rails new` is not
compatible with Rails.
To solve this issue, modified it to use compatible `sqlite3` using
template.
Ref: https://github.com/rails/rails/issues/35161
Fixes#165 and closes#166
Currently the only way to customize the factory definition file
paths is to do it in an initializer right after the
"factory_bot.set_factory_paths" initializer. With this commit,
we can customize factory definition file paths by
setting `config.factory_bot.definition_file_paths`
in config/application.rb or the appropriate environment file.
Once we update the documentation to include this new configuration, we
should be able to close#149 and #180 as well, since using this
configuration can replace the initializer solution for sharing factories
in an engine (the initializer solution will still work, but with the new
configuration you don't need to know anything about the
fbr railtie).
This will also allow us to close#192, since we can use this
configuration with an empty array to disable automatic loading
of factories in development.
- Add Rails 5.1 and 5.2 to Appraisal
- Avoid running combinations we know are going to fail by moving to
"exclude" instead of "allow_failures"
- Use updated migration class for Rails 5.1+
* Remove gemfiles from version control to match same testing style as
Clearance and Suspenders.
* MiniTest does not need to be manually included as it is automatically
included by Rails by default.
* Add spring for Rails 4.1.
* Disable Spring to get specs to pass on Rails 4.1.
* Add therubyrhino for JRuby.
* Remove old references to Rails 3.
* Fix JRuby test where output is "1 runs", not "1 tests".
* Remove Rails 3.0 reference to "turn".
JRuby does not support setting/unsetting environment variables.
Thus, we will launch an entirely new process without the parents env when
we run `bundle install` inside the generated rails apps, forcing them to
use their own Gemfile, instead of the BUNDLE_GEMFILE setting from the main
gem codebase.
Previously, the railties required by the project gemspec was in conflict with
the rails versions being pulled in by Appraisal.
There were situations where a newer rails app was generated by `rails new...`
even though the Appraisal gemfiles/ value should have been setting it correctly.
We need to be able to use the versions of things specified in the appraisal gemfiles/
specify the version of rails for the initial generation of the applications,
but subsequently allow those applications to point to the `Gemfile` within
the newly generated rails apps, rather than wherever BUNDLE_GEMFILE was previously
set by Appraisal.
