3 Inconsistent Behaviours (one works; the other two fail)

[texadactyl]

[1] On the web, my github site (https://goreportcard.com/report/github.com/texadactyl/jacotest.go), gets the common failure that many people are reporting:

There was an error processing your request: Could not analyze the repository: no .go files found

This is a strange result because there are plenty of .go files if the operational code simply walked the tree.

[2] When I follow the local installation instructions and run it from the command line, it works as expected. Success!

[3] When I try the README.md instructions for running as a local web application,
GRC_DATABASE_PATH=./db make start
I see the following:

vendor/github.com/dgraph-io/badger/v2/backup.go:26:2: cannot find module providing package github.com/dgraph-io/badger/v2/pb: import lookup disabled by -mod=vendor
	(Go version in go.mod is at least 1.14 and vendor directory exists.)

In my opinion, I should not have to perform a local install in order to use goreportcard. Agree?

[texadactyl]

It would be helpful if there was a way for goreportcard to be verbose while walking the github site tree. I suggest that goreportcard display each directory as it traverses the tree.

[texadactyl]

What is "v2" under badger? I see branches release/v2.0 and release/v2.2007
under https://github.com/dgraph-io/badger.

It seems that the web version of goreportcard is failing because of its inability to use badger while the CLI version simply walks the tree rooted at the current directory and gets the job done.

Also, you might want to consider not being dependent on a particular version of badger if at all possible. Taking my own medicine, as it were: my badger app makes no mention in the source code of the badger version (I just get the latest stable version if badger is updated).