Recommended usage on rails / CI (Jenkins) server

[Ben Turner]

Firstly, thanks to Benjamin for bringing metric_fu back from the dead - it's really appreciated.

I am now trying to perform similar miracles on my own application, pulling it up from ruby 1.8.7 / rails 3.0. I've manage ruby to 1.9, but next I was looking into rails 3.1, and that's when the Gemfile started to whine.

Looking at metric_fu now, I note that the later versions do not need to be run within the Gemfile - is that the better way of running it ? Equally, we'd like to run the reports via Jenkins, which I guess means installing the gem manually on the box (as currently it's installed via bundler) - will this work ?

Part of our build was always to run the reek part of the report, and fail if the reek count increased (encouraging the developer to fix the reek, or comment / exclude the error manually to acknowledge it's one we can live with). This might be something we can still do my remote executing metric_fu outside of our application context though, and just parse the output YML file, not sure. 

Finally, doesn't simplecov need to be part of the Gemfile bundle ? Does that mean metric_fu will need to be as well, if we want to do code coverage ? 

Sorry, scattered thoughts from someone slightly out of their depth here. Appreciate any advice / tips / assistance.

Regards,

Ben

[Benjamin Fleischer]

Hey Ben-

On Wed, Apr 30, 2014 at 7:57 PM, Ben Turner <ben.t...@gmail.com> wrote:

OT: Ruby 1.8.7 -> 1.9.3 is rough. You'll likely have a lot of encoding errors.  I wrote a post about it here, if you like http://www.benjaminfleischer.com/2013/06/10/ruby-19-upgrade-and-encoding-hell/  I just got a PR into master, of a gem I recommend there, that will sanitize utf8 in your rack app (rails) https://github.com/whitequark/rack-utf8_sanitizer

Looking at metric_fu now, I note that the later versions do not need to be run within the Gemfile -

 

I'd recommend running metric_fu via the command-line (and probably with a .metrics) file over running it as a rake task.  Sometimes it works better that way for reasons I haven't looked into.  Thus, if you gem install metric_fu on your CI, you'll be able to run it.  Including it in a Gemfile or bin/ci script are probably good ways to ensure it is installed.

Equally, we'd like to run the reports via Jenkins

I'm not currently doing this, but a user has added instructions on the wiki https://github.com/metricfu/metric_fu/wiki#integration-with-jenkins  As an aside, CodeClimate is really great.  You can probably get a two-month trial with them if you ask nicely.

 

Part of our build was always to run the reek part of the report

You could for sure parse the metric_fu output report.  By default it would be in tmp/metric_fu/_data/YYYYMMDD.yml.  The information in there would be much reduced from reek's, but if you're just looking for number of smells, that would work.  (Aside: this is an area of metric_fu I want to improve in general, and specifically implement reek as a library, rather than shelling out). That said, reek's not usually a good metric for failing a build.  The VCR gem has some interesting quality checks in it https://github.com/vcr/vcr/blob/master/Rakefile#L39 https://github.com/vcr/vcr/blob/master/spec/quality_spec.rb as do metric tools like Fudge, devtools, and maybe pronto (see https://github.com/metricfu/metric_fu/wiki/Code-Tools )

Finally, doesn't simplecov need to be part of the Gemfile bundle ? Does that mean metric_fu will need to be as well, if we want to do code coverage ? 

Good point, I hadn't thought of that.  SimpleCov will need to be in the Gemfile so it can run with tests.  If you're using the metric_fu simplecov formatter, then metric_fu would have to be in the Gemfile as well to make it available.  Just set the require to false so you don't load unnecessary stuff.

 

Hope that helps

Would you mind adding any info you're comfortable with on where you use metric_fu and how? https://github.com/metricfu/metric_fu/wiki#where-is-metric_fu-used-and-how

-Benjamin