-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
When running with --retry, exit code should be 0 if a failed scenario passes on retry #1044
When running with --retry, exit code should be 0 if a failed scenario passes on retry #1044
Comments
@mattwynne does this capture the issue appropriately? Is this something that can be addressed in v3.0.0.pre.1? |
That's great thanks @rishi-freshbooks. We'll do our best to fix this in a future pre-release of v3, yes. |
@mattwynne any progress on this? Just encountering this issue myself - I love that I finally got the --retry flag working in circleci (note: I had to put the command at the end of the line otherwise a --format option that had an --out param seemed to swallow the retry attempt), however, once the retry started "working", circle still saw the run as a failure. 😞 |
- Updated configuration to count the base number of cases being run - Updated failure? method to use cases.total_passed and total_cases to determine if the run was successful
@mattwynne - I took a really ugly pass at this (master...streetlogics:issue/retry-success-exit-code-0-1044) just to get something working. Definitely open to any thoughts you might have on improving this for the actual implementation |
Awesome, thanks @streetlogics one of us will take a look ASAP |
Any update? My team is also interested in this fix as a non-zero exit code causes our Bamboo build to fail. |
Just ran into the @mattwynne, Is there an ETA for it and/or is there anything we could do to help push this across the finish line? |
Yes, in non-strict mode the exit code should be 0 is all scenarios passes on retry, but in strict mode (option I think a that first the summary should be updated with a new flaky category (as in @streetlogics patch does not handle the strict mode correctly, and as I just stated, I think that the exit code should be based on the summary (if the summary reports a failed scenario - then the exit code should be non-zero) |
- Updated configuration to count the base number of cases being run - Updated failure? method to use cases.total_passed and total_cases to determine if the run was successful
- Updated configuration to count the base number of cases being run - Updated failure? method to use cases.total_passed and total_cases to determine if the run was successful
## [3.0.0](cucumber/cucumber-ruby-core@v3.0.0.pre.2...v3.0.0) (2017-09-27) ### Changed * Step#name renamed to #text ([#137](cucumber/cucumber-ruby-core#137) [@olleolleolle](https://github.com/olleolleolle)) * Use past tense in event names (`xStarting` -> `xStarted`) (see [cucumber/cucumber-ruby#1166](cucumber/cucumber-ruby#1166) @brasmusson). ### Added * Do not create test cases for scenarios with no steps ([#144](cucumber/cucumber-ruby-core#144) @brasmusson) * Handle selective strict settings ([#143](cucumber/cucumber-ruby-core#143) @brasmusson) ### Fixed * Fix DataTable's Location to be aware of all of its lines ([#142](cucumber/cucumber-ruby-core#142) @botandrose) ### Improved * As per [#251](cucumber/common#251): renamed History.md to CHANGELOG.md, added contributing message at beginning, and misc formatting. ([#145](cucumber/cucumber-ruby-core#145) [jaysonesmith](https://github.com/jaysonesmith)) ## [3.0.0.pre.2](cucumber/cucumber-ruby-core@v2.0.0...3.0.0.pre.2) (2017-07-26) ### New Features * Add a flaky result type to be used for flaky scenarios ([#141](cucumber/cucumber-ruby-core#141), [cucumber/cucumber-ruby#1044](cucumber/cucumber-ruby#1044) @brasmusson) * Make the Summary report able to say if the total result is ok ([#140](cucumber/cucumber-ruby-core#140) @brasmusson) * Replay previous events to new subscribers ([#136](cucumber/cucumber-ruby-core#136) @mattwynne) * Ruby 2.4.0 compatibility ([#120](cucumber/cucumber-ruby-core#120) @junaruga) * Use tag expressions ([#116](cucumber/cucumber-ruby-core#116) @brasmusson) * Access example table row data by param name ([#118](cucumber/cucumber-ruby-core#118) @enkessler) ### Bugfixes N/A ### Removed Features N/A ### Refactoring * Travis: jruby-9.1.10.0 ([#130](cucumber/cucumber-ruby-core#130) @olleolleolle) * Travis: jruby-9.1.12.0 ([#133](cucumber/cucumber-ruby-core#132) @olleolleolle)
Flaky tests still fails the scenario, How can i force cucumber to have a pass if the scenario has passed during the re-run. I see this is the simplest thing I can implement comparatively with |
@reach2jeyan have you tried using the flags defined in this (merged) PR? |
@xtrasimplicity Yes! and still I get cucumber has failed with 1 flaky scenario and since the flaky scenario has previously failed |
@reach2jeyan Hmm, that's interesting. Could you please post a MCVE? |
@xtrasimplicity but re-run failed tests are not going to be updated in the parent report; it will remain as a separate report with left-over failed scenarios @mattwynne is there a way to get the consolidated report after re-run tests? or any work-around ignoring the failed tests if the tests are passed on --retry |
This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
Summary
When running cucumber with the --retry flag, the process will exit with a non-zero code if the scenario fails on first try but passes on a retry.
Expected Behavior
Running cucumber with --retry flag should exit with code 0 if scenarios pass on first try or within the specified number of retries .
Context & Motivation
The non-zero exit code causes our build job in JenkinsCI to fail when it should report as success.
The text was updated successfully, but these errors were encountered: