-
Notifications
You must be signed in to change notification settings - Fork 585
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
Partial fix for #1395 #1396
Partial fix for #1395 #1396
Conversation
This makes the logic easier to read
This will show the groups which targets run in which is incredibly useful!
Hey @forki (or any other maintainer), any chance of getting this reviewed/merged? |
This looks like it's changing a lot of the internals. That's very risky. @matthid what do you think? |
Might be a candidate to rebase on top of FAKE vnext (#1281)? However, this probably means that is not released anytime soon... As I'm currently quite busy. |
Otherwise it looks like a logical change to make... Do a lot of people depend on the parallel processing? |
As a compromise, I could look to make a flag which is passed on command like to run targets as early as possible? |
I don't think we need a flag. Just enough confidence that it's correct Am 12.10.2016 19:45 schrieb "Chris Blyth" notifications@github.com:
|
Ok, I've tried to create test scenarios to cover basics, the key to the change is the level adjustments. |
we will put that in alpha for next minor version |
@forki there has been a few minor releases since october..any idea when this can be merge? |
URGENT: Bug Fix For Parallel From #1396
Targets now fire as early as possible.
However, targets will not move onto the next level until all targets on that level are completed.
Therefore, in the situation described in #1395 although T2.1 and T3 run along side each other, T2.2 waits until the longer running T3 has completed before starting even though it has no dependency on it.