Skip to content
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

Merged
merged 4 commits into from
Mar 27, 2017
Merged

Partial fix for #1395 #1396

merged 4 commits into from
Mar 27, 2017

Conversation

BlythMeister
Copy link
Contributor

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.

@BlythMeister
Copy link
Contributor Author

Hey @forki (or any other maintainer), any chance of getting this reviewed/merged?

@forki
Copy link
Member

forki commented Oct 12, 2016

This looks like it's changing a lot of the internals. That's very risky.

@matthid what do you think?

@BlythMeister
Copy link
Contributor Author

@forki @matthid I have added additional test coverage of scenarios and happy to add more if you can describe any :)

@matthid
Copy link
Member

matthid commented Oct 12, 2016

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.

@matthid
Copy link
Member

matthid commented Oct 12, 2016

Otherwise it looks like a logical change to make... Do a lot of people depend on the parallel processing?

@BlythMeister
Copy link
Contributor Author

As a compromise, I could look to make a flag which is passed on command like to run targets as early as possible?
That way it's not a change unless you opt in for it (which I would then do on my build script)

@forki
Copy link
Member

forki commented Oct 12, 2016

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:

As a compromise, I could look to make a flag which is passed on command
like to run targets as early as possible?
That way it's not a change unless you opt in for it (which I would then do
on my build script)


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#1396 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AADgNJPpIVBOIM9sBtSjux7nUaC_96UQks5qzRzJgaJpZM4KQylc
.

@BlythMeister
Copy link
Contributor Author

Ok, I've tried to create test scenarios to cover basics, the key to the change is the level adjustments.
I'm not sure what else I can do to increase confidence, but if you have anything I can try and implement it.

@forki
Copy link
Member

forki commented Oct 20, 2016

we will put that in alpha for next minor version

@BlythMeister
Copy link
Contributor Author

@forki there has been a few minor releases since october..any idea when this can be merge?

@forki forki merged commit 2fb55a7 into fsprojects:master Mar 27, 2017
forki added a commit that referenced this pull request Mar 28, 2017
@BlythMeister BlythMeister deleted the ParallelOrder branch May 11, 2021 15:57
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants