grodowski / pronto-undercover Goto Github PK

Hi Jan,

First of all thanks for this gem, I was just trying to integrate it in my private repo to improve code coverage.
While pronto-undercover works well for new files it is causing some issues when some code is added to existing method.
The runner lists few extra lines that are not part of the diff.

I tried to do some research and found out that when patch_to_undercover_message(patch) is called it calls offending_line_numbers per patch which internally calculates uncovered lines and returns first line of that uncovered patch.

Then in the loop of the object returned by method call offending_line_numbers(patch) we are again checking uncovered lines but this time the uncovered lines returned are simply all the lines from first and last line of that particular patch. I can see that undercover's coverage method is called for this. This seems unnecessary and incorrect, as the correct line numbers (which are only part of the diff) can be returned using offending_line_numbers(patch) this call which can instead of returning [warning, first_line_no] return [warning, uncovered_lines] and which further can be used to prepare the output.

Let me know if you wan't to discuss this.

Hi there, we are seeing that pronto-undercover does not update its review after coverage changes. Typically:

• First commit is pushed, Pronto adds a review comment with uncovered lines
• Author takes heed and pushes a second commit which addresses missing coverage
• Pronto does not amend its review or add another one

We have included a PRONTO_PULL_REQUEST_ID="$TRAVIS_PULL_REQUEST" unbuffer bundle exec pronto run -f github_pr -c origin/master; step in our Travis script, wondering if there was an issue with our config?

Or it could be a new feature to have the bot approve PRs if undercover exits with 0?

Idea came out of #20, seems. like :nocov: should just work to suppress warnings on selected lines of code

When I run command ‘pronto run’ i’m getting an error:

undercover-0.3.4/lib/undercover/lcov_parser.rb:47:in `parse_line': could not recognise 'BRF:0 (Undercover::LcovParseError)

I found that version of undercover gem not matched with the last version of simplecov-lcov gem witch generate report with the ‘BRF’ symbols. But underсover of 0.3.4 version doesn’t expect this format of coverage report.

Obviously it can be fixed it by specifying the correct version of underсover in the .gemspec file.

Hi, how I can configure percentage coverage for method and not raise warning if it above.

Current pronto message:

app/serializers/applogin_history_serializer.rb:21 W: instance method subapp_name missing tests for lines 21, 22 (coverage: 0.6)

how to hide this if I configure coverage to (0.5) - I think this is 50%

Hi @grodowski !
pronto has released recently, and changed major version to 10.X
we actually switched and using it now
and we can not start using pronto-undercover now, because dependency in latest 0.1.3 version:
the issue we have:

ostet@daisy:~/coding/overhaul-backend$bundle install
Warning: the running version of Bundler (1.17.2) is older than the version that created the lockfile (1.17.3). We suggest you upgrade to the latest version of Bundler by running `gem install bundler`.
Fetching gem metadata from https://rubygems.org/.......
Fetching gem metadata from https://rubygems.org/.
Resolving dependencies........
Bundler could not find compatible versions for gem "pronto":
  In snapshot (Gemfile.lock):
    pronto (= 0.10.0)

  In Gemfile:
    pronto-brakeman was resolved to 0.10.0, which depends on
      pronto (~> 0.10.0)

    pronto-undercover was resolved to 0.1.3, which depends on
      pronto (~> 0.9.0)

Running `bundle update` will rebuild your snapshot from scratch, using only
the gems in your Gemfile, which may resolve the conflict.

would be nice to have pronto-undercover compatible with latest pronto
thanks in advance for any help
have a nice day!

When I run undercover directly, I get no warnings, but when I use pronto-undercover, I see:

Undercover::Report#build_warnings is deprecated! Please use the #flagged_results accessor instead.

Looks like it was deprecated in undercover 0.3.4: grodowski/undercover@6a35e2a

Requires output updates in patch_to_undercover_message