dkubb / yardstick

A tool for verifying YARD documentation coverage
http://wiki.github.com/dkubb/yardstick
MIT License
172 stars 22 forks source link

Add devtools #10

Closed indrekj closed 11 years ago

coveralls commented 11 years ago

Coverage Status

Coverage remained the same when pulling 6f7a432185697d5e73ee01759e04312cfc6f6a04 on indrekj:devtools into c937f262b2b54d739e5aa7ffd11f9a42183a69e0 on dkubb:master.

coveralls commented 11 years ago

Coverage Status

Coverage remained the same when pulling 9ab9660ba84fd1a475374977bdab536c52424afd on indrekj:devtools into c937f262b2b54d739e5aa7ffd11f9a42183a69e0 on dkubb:master.

snusnu commented 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

indrekj commented 11 years ago

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?

indrekj commented 11 years ago

Oh, I was late :). Thanks.

coveralls commented 11 years ago

Coverage Status

Coverage remained the same when pulling c8d3f038c0278ee870c80664f81b333cb4f70631 on indrekj:devtools into c937f262b2b54d739e5aa7ffd11f9a42183a69e0 on dkubb:master.

coveralls commented 11 years ago

Coverage Status

Coverage remained the same when pulling 12d190894ca2bba3bf8f84c6037a9ba5ceac14cd on indrekj:devtools into c937f262b2b54d739e5aa7ffd11f9a42183a69e0 on dkubb:master.

indrekj commented 11 years ago

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.

mbj commented 11 years ago

@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.

snusnu commented 11 years ago

@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.

mbj commented 11 years ago

@snusnu Lets disable it for now. I dislike options.

coveralls commented 11 years ago

Coverage Status

Coverage remained the same when pulling c4454622c8a2bb03f763de375f82519477a10cdd on indrekj:devtools into c937f262b2b54d739e5aa7ffd11f9a42183a69e0 on dkubb:master.

solnic commented 11 years ago

@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 :)

coveralls commented 11 years ago

Coverage Status

Coverage remained the same when pulling c4138a7953e485a248db151252579c7f54e2b599 on indrekj:devtools into c937f262b2b54d739e5aa7ffd11f9a42183a69e0 on dkubb:master.

indrekj commented 11 years ago

Is there anything else I should change here?

dkubb commented 11 years ago

@indrekj thanks for pinging me on this. It's awesome. I will merge this now.

mbj commented 11 years ago

@indrekj I'm already using your changes in private projects. Thx!

dkubb commented 11 years ago

@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!

mbj commented 11 years ago

@dkubb Thx. I was about to ask ;)

indrekj commented 11 years ago

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.

dkubb commented 11 years ago

@indrekj that sounds good. I'll do a point release after that unless you beat me to it.