Add repolint linter

[wesley-dean-flexion]

I swear I submitted something like this already but I can't find it, so I must be hallucinating..

Is your feature request related to a problem? Please describe.

There's a group that provides Repolint, a "linter" that "lints" repositories. The rulesets (default ruleset) are configured via JSON file; the rules may be of the following types:

• apache-notice
• directory-existence
• file-contents
• file-existence
• file-hash
• file-hashes-not-exist
• file-no-broken-links
• file-not-contents
• file-not-exists
• file-starts-with
• file-type-exclusion
• git-grep-commits
• git-grep-log
• git-list-tree
• git-working-tree
• json-schema-passes
• large-file
• license-detectable-by-licensee
• best-practices-badge-present

An example rule is:

 "readme-file-exists": {
      "level": "error",
      "rule": {
        "type": "file-existence",
        "options": {
          "globsAny": ["README*"],
          "nocase": true
        }
      }
    },

which would throw an error (alternatively, it could throw a warning) if there is no file that matches README* (case-insensitive glob in this case). That is, the ruleset requires the conditions under which the repository would pass (so, read this as "the repo must have a README")

Describe the solution you'd like

I would like to add REPOSITORY_REPOLINT. I'm happy to do the implementation. My request here, like with #3493, is whether or not folks think this is a good idea to add.

Describe alternatives you've considered

...not..using Repolint?

Additional context

I'm happy to do the work if folks thing it's worth it and it's in alignment with the vision for MegaLinter.

[echoix]

The project seems to have recent commits, but no releases since 3 years ago. Is it a linter commonly used in its respective domain?

[wesley-dean-flexion]

One of the teams with whom I work uses it fairly extensively and it facilitates some functionality I'm trying to codify. The phrase that enters my mind is "policy compliance" even though it's closer to "are they following our recommendation?".

For example, one of our recommendations was that repos should have a .pre-commit-config.yaml file; ideally, it should reference gitleaks, detect-secrets, etc. but that's really secondary. We can't tell if a developer is using pre-commit to keep secrets out of their commits; however, we can tell if a developer is not if the config file isn't there.

So, we would have a file-exists rule with a glob that matches .pre-commit-config.yaml.

That specific use-case aside, I believe there is value is in recommending a set of rules that help make it easier for repositories to adopt practices designed to help repository maintainers make community-friendly repos. So, encouraging folks to have CODEOWNERS and README files (etc.), adopt dependency maintenance tools (Dependabot, Renovate, etc.), and so on may help make the OSS world a better place.

recent commits, but no releases since 3 years ago

I'm not very surprised from a functionality perspective (once you get file-exists working, I'm not sure how much maintenance of that code would be required). I will say that I'm a little disappointed from a dependency update / vulnerability perspective, for sure.

Thank you for the feedback, @echoix. It's very helpful for supporting intentional decisions.

[echoix]

If you try to find other issues where we introduced linters, there's a couple of guidelines that we try to follow.

Some factors we use:

• Actively maintained
• Not really new/recognized by the community
• Plays nice with other linters already there (especially npm ones)
• Useful
• Isn't dangerous (goes a little bit with the actively maintained criteria)
• Installed sized and linting speed. Introducing a linter that does almost nothing but takes 0.8 GB more space, or slows everyone by minutes doesn't have its place.
• Isn't too annoying for users when introducing it and enabled by default.

[wesley-dean-flexion]

Fair comments.

1. Good point. 11 commits over the past year. It looks like they're all Dependabot; I see there are several issues asking them to cut a new release over the past year and, since the last release was in 2021, they seem to be ignored
2. It's been around for a while , but yeah, I get it
3. yeah, it's written in Node; whether or not it could cohabitate in an image with other Node-based tools is something I haven't explored
4. I think it's interesting but I'm likely in the minority
5. I haven't audited the source; however, npm audit --dry-run asserts that there are 2 criticals and 5 highs and that's not very comforting)
6. yeah, the image from running docker build -t repolinter . is 1.3GB. The list of dependencies listed is a little breath-taking (Ruby plus Python plus Perl plus the C/C++ build stack) just to build a Node app; it would be one thing if the it was a multi-stage build.. but it's not..
7. yeah, the default ruleset would need to be extremely limited so as to minimize the new noise when the linter's added; we could mitigate that with only running it when a ruleset is supplied); then again, the first thing I do with a new MegaLinter deployment is to disable the SPELL linters so as to not deal with the noise.. :shrug:

..and I would also add:

8. they publish a GitHub Action that could be invoked every bit as easily as MegaLinter
9. the aforementioned action allows for the automatic creation of issues in a repo to track finding resolution; this is something my group want to use to "help" repos come into compliance, but it's (way) outside of MegaLinter's behavior; that is, even if it was integrated with MegaLinter, we would still need to implement that which we could otherwise get for "free" with their action
10. their security disclosure policy is just a link to examples of security disclosure policies :grimacing:

That said, I think it could add value, especially in situations where a group may have domain-specific rules that they want to enforce.

[nvuillam]

I share @echoix's thought as the latest release is from 2021 😨

But nothing prevents to create a MegaLinter Plugin, that way we are not responsible about the security around it and people use it at their own will and risk :)

[wesley-dean-flexion]

create a MegaLinter Plugin

Ohh, good point! I keep forgetting about that option :facepalm:

[nvuillam]

If you try to find other issues where we introduced linters, there's a couple of guidelines that we try to follow.

Some factors we use:

• Actively maintained
• Not really new/recognized by the community
• Plays nice with other linters already there (especially npm ones)
• Useful
• Isn't dangerous (goes a little bit with the actively maintained criteria)
• Installed sized and linting speed. Introducing a linter that does almost nothing but takes 0.8 GB more space, or slows everyone by minutes doesn't have its place.
• Isn't too annoying for users when introducing it and enabled by default.

I love this list, we should add it somewhere in the documentation, and maybe use it to remove some linters for the next major version :)

Current candidates are protolint and sql-lint as they are not maintained and full of CVEs 😇

[wesley-dean-flexion]

I share

Sure. It sounds like it's not a good match. That's totally fine -- it's why I asked before doing the work!

I'll close this out here. If anyone comes along afterwards, they can find this conversation.

Thank you, @nvuillam and @echoix for your help, your time, and your wisdom.

[nvuillam]

@wesley-dean-flexion if you really want to use repolint in MegaLinter, just write the descriptor in another repo, or directly in repolint repo, and you can use it as a plugin :)

The descriptor format is the same than for internal descriptor, except that you are restricted to RUN instructions for installation