Closed indrekj closed 11 years ago
@indrekj you can fix the timeout error on rbx by doing something like: https://github.com/snusnu/substation/blob/master/config/devtools.yml
Build failed because (rbx-18):
1) Yardstick::Rake::Verify#initialize with custom arguments when threshold is not specified raises error
Failure/Error: Unable to find matching line from backtrace
Devtools::Project::TimeoutError:
Unit test took 0.10097199999999999 but max allowed is 0.1
https://github.com/indrekj/yardstick/blob/devtools/lib/yardstick/rake/verify.rb#L33 https://github.com/indrekj/yardstick/blob/devtools/spec/unit/yardstick/rake/verify/initialize_spec.rb#L38
It seems a random error that doesn't happen every time. Any suggestions how to fix it?
Oh, I was late :). Thanks.
There seems to be something wrong with Travis. I got Unit test took 1.826304 but max allowed is 0.3
. Last time it passed with max 0.2. And before that is passed with max 0.1.
@indrekj Its just statistic fluctuation. We just discussed this here: http://irclogger.com/.datamapper/2013-05-06#1367851643
IMHO we should pick 0.3 or something now and use a different strategy in future.
@mbj tbh, imo everytime i have to adjust the timeout value to something i have no idea if it will pass or not, i'm just annoyed and it takes away time. i'd vote for deactivating that extra safety net until we have a solution that checks cpu time only.
@snusnu Lets disable it for now. I dislike options.
@dkubb @mbj please excuse my snarky comment but...this conversation seems to be a significant effort. I wholeheartedly agree with @mbj that adding complexity to a tool that could work only in 1.9 mode is a wasted effort. yardstick is such a tool, there's no good reason why it must work under 1.8. People could just use it under > 1.9 (just like we run all our metric stuff only under 1.9.3 these days).
We talked about 1.8 support plenty of times but months are passing and we're still wasting time trying to support it with very little to none benefit. I know there are many apps out there running under 1.8 but at the same time there are many apps running under 1.9 and more apps that will run under 1.9 or 2.0 are being under development. I think we should focus our efforts on the future instead of trying to be nice to people being stuck on 1.8. Why? Because I'm not so sure if those people will ever benefit from using our libs, they have probably bigger problems to solve, like...porting their apps to ruby 2.0.
I'm just saying supporting 1.8 is a significant effort (time wise) and it's simply not worth the price because benefits coming from 1.8 support are too small these days.
...but yeah, your repo your rules. Just me 2 cents :)
Is there anything else I should change here?
@indrekj thanks for pinging me on this. It's awesome. I will merge this now.
@indrekj I'm already using your changes in private projects. Thx!
@indrekj I think I'm going to do a yardstick release with your new changes very shortly. I'll probably bump the minor number this time.
Thanks again!
@dkubb Thx. I was about to ask ;)
At the moment the exclude
feature only works with instance methods and class methods. Tomorrow, I'll will create a pull request so that it also supports classes and modules. This doesn't affect making a release of course. Just letting you know.
@indrekj that sounds good. I'll do a point release after that unless you beat me to it.
Coverage remained the same when pulling 6f7a432185697d5e73ee01759e04312cfc6f6a04 on indrekj:devtools into c937f262b2b54d739e5aa7ffd11f9a42183a69e0 on dkubb:master.