Allow sumi to check if user email matches a given regex

[marovira]

Feature Request

Summary

The idea is to provide a new entry into the config that allows the user to set an email regex that all commits must satisfy.

Motivation

There's a couple of reasons why this feature is extremely useful:

• Consistency: at my day job, our gitlab instance isn't particularly well coordinated in terms of the emails that users use, which makes it hard to track who is making what changes and finding them in the company registry. By enforcing that all emails must come from a certain domain, it makes it much simpler to track who's making changes.
• Less mistakes: as part of my job, I sometimes contribute to open source projects using my GitHub account. As a result, my user config uses my GitHub email. This causes issues when I have to work on our own private repos as I sometimes forget to run git config user.email "me@work_email.com" causing me to have to back-out commits or (in extreme cases) have to run git filter-repo to change the email address. By having sumi be able to ensure the email comes from my work address, it would prevent this from ever happening.

A side-motivation is that I'm trying to explore alternatives to gitlint, which is what we're currently using. The project is great, but hasn't been updated in over 3 years and has some features that I need (such as checking for imperative mode). Sumi is in a perfect position to replace gitlint since it almost covers all my needs and is also a standalone executable that I can just install to simplify development in certain cases.

Detailed Description

There are two sides to implementing this feature, so I'll describe how each of these could be done separately.

The Config

This one is easy. Reading through the code, it would just be a matter of cloning Config::header_pattern and renaming it as user_email_pattern or something similar. As the two are effectively the same (just regexes) the existing code and tests that cover header_pattern can just be duplicated to cover the new entry. In principle the code could be refactored to merge these two together and cover them with the same code instead of duplicating, but the simplest option is to just duplicate the code.

The Check

To implement the check, we first need a way to obtain the user email address. I can think of two ways of accomplishing this (with varying levels of difficulty):

1. Add a function similar to get_git_commentchar that runs git config --get user.email to grab the email address from the current git config.
2. A more complex version of this would involve peeking into the git log and parsing the information from there, similar to what gitlint is doing here.

Version 1 is the easiest but has the drawback that it depends exclusively on the user.email value being set. This is (probably) true in local environments, but it is almost certainly not true in CI. Since you've recently added the ability to check ranges of commits, this could be problematic. Version 2 is the most robust as it allows extracting the email address directly from the log, negating the need for user.email to be set.

[welpo]

Hey, thanks for writing this request, @marovira

The drawbacks are real. In case we go for the log check, since it'd be needed for CI/range checks, we would only be able to check after the commit is made, no?

I think we may need both paths:

• if user is using --commit, we check git config --get user.email
• if checking range, use log

but… how about linting a PR title? That's how I use it in my repos, but I suppose if you're setting a regex for user email, you're not linting at the PR level, but at the commit level…

Rambling a bit. Thoughts?

[marovira]

I think we may need both paths:

if user is using --commit, we check git config --get user.email
if checking range, use log

Yes, we'll definitely need to use both paths with that exact logic.

but… how about linting a PR title? That's how I use it in my repos, but I suppose if you're setting a regex for user email, you're not linting at the PR level, but at the commit level…

This one's a bit trickier. If I understand correctly, the sumi action uses the sumi.toml found at the root of the repo. If that's the case, then there are a few alternatives I can think of to lint the PR title:

• Create a separate sumi.toml and somehow pass that in as an argument to the action to lint PR titles. Reading through the code, I think this should be relatively straight-forward.
• If I'm reading the code correctly (I'm a bit tired right now so... apologies if I'm not making a lot of sense!), it seems that it would just be a matter of overriding this specific option through either the command line or an environment variable.

To elaborate on the last point (and for illustration purposes, say the new option is called email-regex). If the user wanted to use it for general commits/pre-commit usage but wanted to disable it for linting PR titles, then they could do either:

• Define GIT_SUMI_EMAIL_REGEX and set it to an empty string
• Pass an empty string to --email-regex through the CLI.

I think the first option would be easier to use and would require 0 changes to the current action, while the second could be easier to implement than the "have a separate sumi.toml for PR titles" option.

I think this covers all the use-cases, unless I missed something? Thoughts?