-
Notifications
You must be signed in to change notification settings - Fork 183
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
upgrade to Bullseye 2.0.0 RC2 #1456
Conversation
Thanks, @adamralph. I'm not sure I'll be using it though. I blame it for
Unless we start generating framework-dependent external assemblies (which we could), it seems we're just asking for failures! None of this means I'm against upgrading. |
FWIW, I'm not wild about the interaction between |
@blairconrad that's strange. It worked perfectly for me. That said, I probably wouldn't use |
Sure, @adamralph, but I was running local! And having to then rerun my build is a bit annoying. It may be an infrequent occurrence. Maybe exacerbated by my weird oldish laptop hardware. Then again, it has happened all one times that I've tried! |
All |
@blairconrad it sounds like what you really need is to run Regarding your failure, I guess some builds simply won't be able to use parallel target execution. If there are two targets contending for a resource, there's nothing Bullseye can do to remove that contention. Those targets will have to be changed before parallel execution can be used. It is weird that it works for me though. I've tried several times without failure. |
Because I want to run tests on newly-built code, but I don't want the darn thing to bother with the gitversioning (and previously, restoring, which was the bigger deal). It's a small thing, but a thing. I'm probably better off running as you say. Except for the integs…
Absolutely. I didn't mean to suggest that it's a problem with the Bullseye feature. That's why I mentioned that I'm not against us upgrading.
Nondeterminism is like that sometimes (but not always! I kill me.). My hardware config at home must make me lucky. I just now tried on the work computer, and 3 successes right in a row, with about 50% reduction in execution time, as you saw. Which is very cool. |
|
~300 ms and a certain number of lines spewed to the screen. But yeah, it's not that big a deal. I'd trade the I'd gotten in the habit of running |
@adamralph, can we take the next RC instead? |
@blairconrad absolutely. I've pushed the package, but NuGet is taking forever to index it. As soon as that's done, I'll push the amended commit. |
I've pushed the amended commit. @blairconrad RC2 has the logging change we discussed. |
Thanks, @adamralph. I appreciate the custom RC2! |
This change has been released as part of FakeItEasy 4.9.1. Thanks, @adamralph. Look for your name in the release notes! 🍵 |
Exactly twice as fast with the new
--parallel
option! You may want to think twice before using it for CI though, since the console output from many targets get interleaved, and there's not much that can be done about that. I've been using it to speed up local builds.