| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
| |
Currently we sometimes find a redundant begin block in code review
(e.g. https://github.com/rails/rails/pull/33604#discussion_r209784205).
I'd like to enable `Style/RedundantBegin` cop to avoid that, since
rescue/else/ensure are allowed inside do/end blocks in Ruby 2.5
(https://bugs.ruby-lang.org/issues/12906), so we'd probably meets with
that situation than before.
|
| |
|
|
|
|
|
|
|
|
|
| |
This prevents the array from being dumped as a DRbObject so we can reduce
communication with the server.
In DRb, if `Marshal.dump` fails, `Marshal.dump` is executed again after
converting the object to `DRbObject`. This also possible to reduce the
execution of `Marshal.dump` by converting to a format that can be
marshalized in advance using `DRbObject`.
This is the same approach to Action Pack's parallel test. Ref: 5751b7ea58d7cf259dda30fb42fff51fc6ae93d5
|
| |\
| |
| | |
Windows support for parallelization and instrumenter
|
| | |
| |
| |
| |
| | |
Add Windows support for `ActiveSupport::Testing::Parallelization`
and `ActiveSupport::Notifications::Instrumenter`.
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
DRb wraps in `DRbUnknown` if the data contains a type that can not be
resolved locally. This can happen if an error occurs in the test and the
error class can not be resolved on the server side.
When this happens, an instance of `DRbUnknown` is passed to the `result`
of `Server#record`. This causes another error(undefined method assertions
for #<DRb::DRbUnknown:> (NoMethodError)) in `reporter.record`.
This can confirm by the following steps.
```
$ rails new app -B --dev; cd app
$ rails g scaffold user name:string
$ edit `config.action_controller.allow_forgery_protection = true` in environments/test.rb
$ bin/rails t
```
In the case of `DRbUnknown` occurs, can't resolve error exception. So wrap
exception with `DRbRemoteError` in the same way as an unmarshalled object.
|
| |\
| |
| | |
Fix DRb::DRbServerNotFound errors in parallel tests
|
| | |
| |
| |
| | |
marshallable DRbRemoteError
|
| |/ |
|
| |
|
|
|
|
| |
This commit moves the `run_cleanup` hook into an `ensure` block so we
make sure to cleanup the databases even if an exception is raised while
running the parallel tests.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Use attr_reader/attr_writer instead of methods
method is 12% slower
Use flat_map over map.flatten(1)
flatten is 66% slower
Use hash[]= instead of hash.merge! with single arguments
merge! is 166% slower
See https://github.com/rails/rails/pull/32337 for more conversation
|
|
|
Provides both a forked process and threaded parallelization options. To
use add `parallelize` to your test suite.
Takes a `workers` argument that controls how many times the process
is forked. For each process a new database will be created suffixed
with the worker number; test-database-0 and test-database-1
respectively.
If `ENV["PARALLEL_WORKERS"]` is set the workers argument will be ignored
and the environment variable will be used instead. This is useful for CI
environments, or other environments where you may need more workers than
you do for local testing.
If the number of workers is set to `1` or fewer, the tests will not be
parallelized.
The default parallelization method is to fork processes. If you'd like to
use threads instead you can pass `with: :threads` to the `parallelize`
method. Note the threaded parallelization does not create multiple
database and will not work with system tests at this time.
parallelize(workers: 2, with: :threads)
The threaded parallelization uses Minitest's parallel exector directly.
The processes paralleliztion uses a Ruby Drb server.
For parallelization via threads a setup hook and cleanup hook are
provided.
```
class ActiveSupport::TestCase
parallelize_setup do |worker|
# setup databases
end
parallelize_teardown do |worker|
# cleanup database
end
parallelize(workers: 2)
end
```
[Eileen M. Uchitelle, Aaron Patterson]
|
