Closed gee-forr closed 4 years ago
This is a great PR, thanks for it @gee-forr! I'll review it later today. Thank you for it!
It seems there Rubocop violations, according to Travis CI, can you please fix those?
3.41s$ bundle exec rubocop
Inspecting 83 files
............................................................C....C.................
Offenses:
spec/acceptance/organizer/iterate_spec.rb:24:81: C: Metrics/LineLength: Line is too long. [83/80]
result = TestDoubles::TestIterate.call(:number => 1, :counters => [1, 2, 3, 4])
^^^
spec/acceptance/organizer/reduce_if_spec.rb:53:81: C: Metrics/LineLength: Line is too long. [83/80]
result = TestDoubles::TestIterate.call(:number => 1, :counters => [1, 2, 3, 4])
^^^
83 files inspected, 2 offenses detected
The command "bundle exec rubocop" exited with 1.
You got it.
--
Gabriel Fortuna gee.forr@gmail.com On 01 Jun 2020, 20:26 +0200, Attila Domokos notifications@github.com, wrote:
It seems there Rubocop violations, according to Travis CI, can you please fix those? 3.41s$ bundle exec rubocop Inspecting 83 files ............................................................C....C................. Offenses: spec/acceptance/organizer/iterate_spec.rb:24:81: C: Metrics/LineLength: Line is too long. [83/80] result = TestDoubles::TestIterate.call(:number => 1, :counters => [1, 2, 3, 4]) ^^^ spec/acceptance/organizer/reduce_if_spec.rb:53:81: C: Metrics/LineLength: Line is too long. [83/80] result = TestDoubles::TestIterate.call(:number => 1, :counters => [1, 2, 3, 4]) ^^^ 83 files inspected, 2 offenses detected The command "bundle exec rubocop" exited with 1. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.
All done :) Let me know if this will make it into a release, we'd love to use it from straight from rubygems in prod.
Thank you! 💯 👍
Hi there,
TL;DR - Context's now have an
#organized_by
attr.We recently came across an issue where we were using actions directly, outside of an organizer. When they failed, and triggered a roll back (like when they're used with an organizer), they instead raise an
FailWithRollbackError
exception, which is used internally by LS for managing roll back flow.This is fine, but there are times when we need to just call the action directly. Rather than duplicate the action, and make it fail without a rollback, I added the ability for a context to know if it's part of an organized run, or a single action.
We can then put an (admittedly ugly) if/else block and fail it differently depending on whether or not the action is called directly or from an organizer.
Hope you like, please let me know if there's anything I need to change.
e.g.