Support per-repo (or repo type?) configuration

[jeefy]

This is somewhat related to #66 but warrants a new Issue/Thread

Many projects have different repos for different purposes. clomonitor should expand the db schema so repos can be flagged as governance, docs, or code repos.

For example, Knative has several repos:

• Community -- A governance repo that holds a lot of policy/procedure info. This should be the primary repo, but it would have a different license (CC 4.0) since it's more of a "Docs" repo. It also is going to fail any sort of "recent release" check since it's not a code repo.
• Eventing -- A code repo that should have an Apache 2.0 License and a "recent release" check
• Service -- A code repo that should have an Apache 2.0 License and a "recent release" check
• Docs -- A docs repo that should have a CC 4.0 License check

If we can decouple the idea of "primary/secondary" repos to instead allow a repo to be flagged as one or more of these categories, I think it will better match many of the projects that exist or will soon be onboarded.

[tegioz]

At the moment we support multiple repositories kinds (primary and secondary) and for each kind we run a different set of checks that can be configured separately. Some context about where the primary and secondary repository kinds come from: #15 (comment), #15 (comment), #15 (comment).

We can add more repositories kinds, that's not a problem. However, we need to keep in mind that the more we have with more configurable variants, the more complexity we'll introduce producing reports, scoring them and specially combining repositories scores to produce a project's final score with homogenized results.

I'd suggest we keep track of how often situations like this occur before making important changes that would affect all projects. Once we have collected more feedback and use cases we can decide if it's better going with the kinds we have, we need to add more or we handle this in a completely different way. We'll be happy to refactor whatever is needed 🙂

I think in many cases the problem described in #66 can be addressed nicely with some headers in the README file, which also makes the information more discoverable by users. We also support .github repos for the default community health files. Some projects' repositories may not need to be added to CLOMonitor at all, as with a reference to some key docs from the main one may be enough.

On a side note about KNative, it looks like neither the library we are using to detect licenses nor Github are detecting it properly. Maybe it's because the LICENSE file contains the text of two licenses (CC and Apache), but not sure. CC is not on our list of approved licenses either (that affects the approved license check), but we could change that.

[jeefy]

Zoning in on the License issue, that's where things get somewhat complex.
CC4.0 is the license we want projects to use only for their docs
Their code should fall under one of the existing licenses you have already (like Apache 2.0)

Because of this split-brained scenario, I'm personally trying to push for the existence of a LICENSE file as well as a LICENSE-DOCS file.

This has been discussed previously (cncf/project-template#12) and I think it's the ideal path forward. Likewise it should also simplify the license checks.

[tegioz]

Because of this split-brained scenario, I'm personally trying to push for the existence of a LICENSE file as well as a LICENSE-DOCS file.

Cool, that'd be nice 👍

[chalin]

Adding my 2 cents: I'd vote for more repo types than just primary and secondary, such as code, docs, and community(?). /cc @nate-double-u