✨ add --nuget package manager flag

[balteravishay]

What kind of change does this PR introduce?

Add --nuget (nuget) switch to scorecard flags so that users have the option to run Scorecard using the Nuget package manager.

• [v] PR title follows the guidelines defined in our pull request documentation

What is the current behavior?

Users of the npm, pypi and rubygems ecosystems can run Scorecard on packages that are hosted on the respective registries, by running scorecard with the ecosystem flag, for example: --npm=angular

What is the new behavior (if this is a feature change)?**

Users of the nuget ecosystem can also run Scorecard on packages that are hosted on Nuget.org, by running scorecard with the ecosystem flag, for example: --nuget=Newtonsoft.Json

• [v] Tests for the changes have been added (for bug fixes/features)

Which issue(s) this PR fixes

Addresses but does not closes this issue: #1578
-->

Special notes for your reviewer

Does this PR introduce a user-facing change?

For user-facing changes, please add a concise, human-readable release note to
the release-note

(In particular, describe what changes users might need to make in their
application as a result of this pull request.)

Run Scorecard on packages hosted at Nuget.org using --npm. For instance: --nuget=Newtonsoft.Json

[codecov]

Codecov Report

Merging #3020 (aad8ef0) into main (d72deff) will increase coverage by 3.21%.
The diff coverage is 92.13%.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3020      +/-   ##
==========================================
+ Coverage   62.01%   65.23%   +3.21%     
==========================================
  Files         166      168       +2     
  Lines       12380    12586     +206     
==========================================
+ Hits         7677     8210     +533     
+ Misses       4279     3925     -354     
- Partials      424      451      +27     

[github-actions]

Stale pull request message

[balteravishay]

I'm not sure how to get past the codecov check.
currently it seems as if only code in flags.g and root.go is not covered.
any advice?

[spencerschrock]

I did try to spot-check some nuget repos from https://www.nuget.org/packages (e.g. go run main.go --nuget AWSSDK.Core), and some seem to be not working. Is this a matter of missing data for the packages? Or alternative ways of searching for the link to the source repo? All of them seem to have Source repository links on the web UI, but perhaps not in the API page we're checking:

error: source repo is not defined for nuget package <packagename>.

• https://www.nuget.org/packages/Newtonsoft.Json
• https://www.nuget.org/packages/Serilog/3.0.0-dev-02022
• https://www.nuget.org/packages/AutoMapper

Sometimes repos link to a specific file instead of the top-level link (github.com/org/repo). the logic on this can differ on this between github and gitlab sadly.
repo unreachable: GET https://api.github.com/repos/Azure/azure-sdk-for-net/blob/Azure.Core_1.32.0/sdk/core/Azure.Core/README.md.

• https://api.nuget.org/v3/registration5-semver1/azure.core/index.json#page/1

Other than that, I have some broad style comments, but not going to block on any more as it can always be refactored later, but wanted to mention it as a resource.
*package_managers_test.go has a huge diff. Which I assume comes from the examples you unmarshall for your tests. We tend to place those in a testdata folder as files, and read the contents during the tests. It helps separate the test logic from the data.

• getters with get in the name: https://go.dev/doc/effective_go#Getters
• a lot of types starting with nuget, which to me means some of this might better be in it a nuget package somewhere (maybe internal/packagemanager/nuget?).

[balteravishay]

Thanks for the thorough review @spencerschrock ! I sure appreciate it !
I fixed your comments, moving both packagemanager and nuget clients under "clients" folder. that added some changes to the makefile and the initialization, which I hope works for you.

[spencerschrock]

Thanks for addressing all the feedback! I know it meant a lot of re-writing, but I think there was a huge readability benefit from it.

Only a small thing. Can we keep these two new packages private by moving them under an internal folder (and update the Makefile rules)? The functionality was previously unexported inside of cmd. Now that they're in their own packages we had to exported some functionality, but we can still stop people from relying on it.

I think either option works fine:
internal/packagemanager
internal/nuget

or

cmd/internal/packagemanager
cmd/internal/nuget

https://go.dev/doc/go1.4#internalpackages
https://dave.cheney.net/2019/10/06/use-internal-packages-to-reduce-your-public-api-surface

[balteravishay]

@spencerschrock, couldn't agree more, thanks again for the thorough review! I've learned a whole lot about golang development and best practices. fixed this iteration's comments about making the clients packages internal.