Draft: Adding Commit Message Negative Regex

Adding a new check

Verification steps for review

1. Open an SQL session (gitlab-psql)
2. Execute this command so that you can add a value that will violate the constraint: ALTER TABLE push_rules DROP CONSTRAINT commit_message_negative_regex_size_constraint;
3. Execute this command to add a value that will violate the constraint and cause the check not to pass: INSERT INTO push_rules (commit_message_negative_regex, created_at, updated_at) VALUES ( 'author_email ([a-zA-Z0-9_\-\.]+)|([a-zA-Z0-9_\-\.]+)|([a-zA-Z0-9_\-\.]+)|([a-zA-Z0-9_\-\.]+)|([a-zA-Z0-9_\-\.]+)|([a-zA-Z0-9_\-\.]+)|([a-zA-Z0-9_\-\.]+)|([a-zA-Z0-9_\-\.]+)|([a-zA-Z0-9_\-\.]+)|([a-zA-Z0-9_\-\.]+)|([a-zA-Z0-9_\-\.]+)|([a-zA-Z0-9_\-\.]+)|([a-zA-Z0-9_\-\.]+)|([a-zA-Z0-9_\-\.]+)|([a-zA-Z0-9_\-\.]+)|([a-zA-Z0-9_\-\.]+)|([a-zA-Z0-9_\-\.]+)|([a-zA-Z0-9_\-\.]+)|([a-zA-Z0-9_\-\.]+)|([a-zA-Z0-9_\-\.]+)|([a-zA-Z0-9_\-\.]+)|([a-zA-Z0-9_\-\.]+)|([a-zA-Z0-9_\-\.]+)|([a-zA-Z0-9_\-\.]+)|([a-zA-Z0-9_\-\.]+)|([a-zA-Z0-9_\-\.]+)|([a-zA-Z0-9_\-\.]+)|([a-zA-Z0-9_\-\.]+)|([a-zA-Z0-9_\-\.]+)|([a-zA-Z0-9_\-\.]+)|([a-zA-Z0-9_\-\.]+)|', NOW(), NOW());
4. Run the check and observe that it will be in the output as not passed (i.e. with a message attribute) because the above SQL adds a push_rule that violates the expected constraint
5. Execute this command to remove the push rule added with a value for commit_message_negative_regex that will cause the check to be not passed: DELETE FROM push_rules WHERE commit_message_negative_regex IS NOT NULL;
6. Run the check again, observe that it will now be in the output as passed (i.e. without a message attribute)

Author checklist

• After opening the MR:
  • Set it to the current milestone
  • Ask the Maintainer from the Reviewer roulette suggestion for review

---

Reviewer checklist

• I followed the verification steps and confirm the functionality of the new check
  • I executed the check as presented in this MR by running the generated playbook with spot
  • In case of unexpected/odd behavior here, verify the generated playbook to account for potential YAML parsing issues
• This check does only perform read operations
• This check does not output more than necessary on stdout for the check to function
• The message explains what it means when this check does not pass
• The workaround_url provides actionable information/steps for affected users
  • Consider if a Knowledge Base article should exist to serve as the ideal workaround URL
• This check is not using the Rails console/runner, or has Maintainer approval for doing so
• If this is a breaking change check:
  • It has the corresponding xx_breaking_changes tag (xx being the major release version for the change)
  • The workaround_url goes to the entry on the https://docs.gitlab.com/update/deprecations/ page
  • The ref_url goes to the deprecation issue linked from that entry
  • The title is the same as that entry
  • The version_started is equal to the announcement_milestone of the deprecation
  • The version_fixed is equal to the removal_milestone of the deprecation