History | Log In     View a printable version of the current page.  
Issue Details (XML | Word | Printable)

Key: QB-3415
Type: Bug Bug
Status: Resolved Resolved
Resolution: Fixed
Priority: Critical Critical
Assignee: Unassigned
Reporter: J. Mash
Votes: 0
Watchers: 0

If you were logged in you would be able to see more operations.

Parallel Composition Step

Created: 03/Jul/19 01:32 AM   Updated: 05/Mar/20 04:33 AM
Component/s: None
Affects Version/s: None
Fix Version/s: 9.0.40

Original Estimate: Unknown Remaining Estimate: Unknown Time Spent: Unknown

 Description  « Hide
A common scenario we find ourselves in is to have a parallel composition container with a single child step that operates on a given fileset matching a pattern -- In one specific case, this results in the build step being executed roughly 470 times.

In cases where we need to cancel or stop a build in progress that has begun processing these repeated build steps, the cancel never seems to work as expected. After clicking the "stop" button, it will stop processing all steps that are currently "running", but it will not prevent any other steps in the queue from being processed.

The build step's execution conditions are "as long as the build is not canceled", and it works as expected when we use a sequential composition container. This makes it nearly impossible to cancel the build in any sort of timely manner, as it requires someone to sit there and click cancel every 5-10 seconds for about 5 minutes before everything's really canceled.

 All   Comments   Work Log   Change History      Sort Order:
Robin Shen [04/Jul/19 12:48 AM]
The cancel mechanism currently affects the running steps. To stop other steps when one is cancelled or in error, you may tick the option "Cancel On Error" of the parallel step.

J. Mash [10/Jul/19 04:24 PM]
All that seems to do is cancel everything on ANY error?

The use case here is a very large project with roughly 470 unique test programs that get executed (in parallel, ~24 threads, and takes about 2 hours), and we want all of theses tests to execute (regardless of each tests individual status) every time in all scenarios EXCEPT if the build is canceled. What we DO NOT want is to have 469 tests get "canceled" because the first test failed -- We need to run the remaining 469 tests, even if the first test failed, and we only want this behavior to change when we've "canceled" the build.

Hopefully that clarifies the situation.

J. Mash [10/Jul/19 04:30 PM]
Alternatively, a means by which a build can be outright killed immediately, halting all future processing of build steps, would be a reasonable option to provide this behavior/

Robin Shen [10/Jul/19 11:12 PM]
Yes, all is cancelled as long as one child step fails on any error. Will add the extra option to cancel all upon cancelling.