The new argument modifies how the rspecq worker publishes the files and
examples to the queue.
By detault it first merges individual examples into files and then
depending on whether the `update-timings` is passed, it will either
publish based on the timings or randomly shuffly them.
If the `reproduction` argument is passed, the worker will ignore timings and
randomness and will publish the files exactly as given.
This feature is very important in order for a developer to be able to
successfully reproduce a flaky test as reported by the reporter in a previous
run.
This commit exposes the timeout we use to consider a queue failed
(not ready).
The need for this was triggered after using rspecq on a host
with lower specs.
These commits adds support on the Queue class to terminate builds after
a certain threshold of failures is surpassed. This configuration is
controlled via the `Queue#publish` method and it is persisted on Redis
Hash[1]. The persistence is added so that the value is shared between
different components that use the same queue instance. (e.g. worker and
reporter)
The feature can be enabled via the `--fail-fast` flag which is passed
onto the worker. This is in par with RSpec's `--fail-fast`[2] which will
terminate the execution of the suite after certain failed examples.
This is an optional flag, and will be nil if not set.
[1]: https://redis.io/topics/data-types#hashes
[2]: https://relishapp.com/rspec/rspec-core/docs/command-line/fail-fast-option
Since we always set a default --redis-host, setting the host from --redis-url
was not possible because the value from --redis-host always took precedence.
With this change, --redis-url always takes precedence and it's possible
to properly set the host using it.
Since we set a reasonable default ("spec", like RSpec does) that will fit most
of the cases, this setting doesn't have to be provided during Worker
initialization. This simplifies Worker#initialize.
This patch adds support for Workers to emit various RSpecQ internal events to
a Sentry[1] instance.
Reporting to Sentry is opt-in and is enabled by setting the SENTRY_DSN
environment variable (see
https://github.com/getsentry/raven-ruby#raven-only-runs-when-sentry_dsn-is-set).
If SENTRY_DSN is not set this is a noop.
Events emitted:
- [error] the spec file split command failed; slow spec files files will
be scheduled as a whole so build times will be negatively impacted
- [warning] no previous timings were found in Redis; scheduling will be random
so build times will be negatively impacted
- [info] slow files were detected and will be split, including the
actual filenames
The above are still printed to the standard output of the worker.
Closes#8
[1] https://sentry.io
Additionally:
- rename `--timings` to `--update-timings`
- don't communicate the default value of `--file-split-threshold`. We
handle this transparently (effectively disable it if it's not set) by
passing a very large value
Closes#4
- Improve descriptions
- Add shorthand version of flags
- Factor out defaults into constants
- Add checks for invalid flag combinations
- Add `--help` and `--version`
Isaac Moore