Error out on unconfigured git emails

[lumag]

It's not unfrequent that engineers fail to configure Git correctly and send changes having foo@users.noreply.github.com as the patch author. Filter out these emails and reject corresponding patches.

[ndechesne]

This is a valid request, as we are consolidating all checks in a common location, I think this should be implemented in https://github.com/qualcomm/commit-emails-check-action

[ndechesne]

and we would get it from #55

[lumag]

and we would get it from #55

Oh, nice that you've noticed. We definitely can not enable https://github.com/qualcomm/commit-emails-check-action. It would rule out all external contributions (or require manual override for each and every developer outside of Qualcomm).

[lumag]

@ndechesne after reading the PR checker, no, it will not block these emails. The default policy is to allow everything (including those autogenerated emails) except several qinc / CAF exceptions.

[mynameistechno]

and we would get it from #55

Oh, nice that you've noticed. We definitely can not enable https://github.com/qualcomm/commit-emails-check-action. It would rule out all external contributions (or require manual override for each and every developer outside of Qualcomm).

It should not rule out external contributors, it should mostly prevent specific QC related domains from being used. cc: @quic-nasserg

[mynameistechno]

It's not unfrequent that engineers fail to configure Git correctly and send changes having foo@users.noreply.github.com as the patch author. Filter out these emails and reject corresponding patches.

We had enabled an enterprise rule to block @users.noreply.github.com commits - it's common to see this e-mail when folks commit directly from the UI - but it interfered with commits from depedenabot.

We want to block foo@users.noreply.github.com but not e.g. 49699333+dependabot[bot]@users.noreply.github.com.

@quic-nasserg should https://github.com/qualcomm/commit-emails-check-action do this? @njjetha could also take another look at the enterprise rule as well - when I gave it a shot the limited regex support was making it more difficult than I anticipated.

[quic-nasserg]

I think we could add that as a rule. It will be a little tricky to handle that dependabot use case, but it should be doable. Would we allow any bot accounts?

[mynameistechno]

I think we could add that as a rule. It will be a little tricky to handle that dependabot use case, but it should be doable. Would we allow any bot accounts?

I'm not aware of any others that follow that convention, but it may be a good idea to allow .*[bot]@users.noreply.github.com

[mynameistechno]

I'm meeting with @quic-nasserg next week - I'll bring this case up as well