Ignore commit messages if they match regular expression #17
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Addresses #14.
See the README diff for a user-facing explanation of the changes in this PR, starting with "Ignoring commits." It includes details on how to configure
poper
settings to ignore certain commit messages.Purpose
Some commit messages are automatically generated. From this very repository, we have an example:
That commit message summary has 52 characters.
If
poper
runs either of the following checks on that commit, it may fail:character_limit
summary_character_limit
Merge commit messages (for example) are automatically generated by concatenating several strings, one of which is the name of the merged branch. Since the branch name may be arbitrarily large, each time you merge a branch into yours and generate a merge commit, you run the risk of that commit failing a
poper
check.There may be reasons why someone would want to keep the long merge commit messages in the repository as-is, while also enforcing length limits on commit messages which developers have directly authored.
Approach
This PR adds related settings to
Poper::ConfigFile::EMPTY
.Rule
s may then access these settings via methods that are dynamically created and callable on the@config
instance variable.The settings themselves provide strings that can be passed to the
Ignore::MatchingPattern
interface, which can be included in anyRule
. This interface provides ashould_ignore?
method which may be used to return early from a check if it returnstrue
.I felt
Rule::Ignore::MatchingPattern
deserved its own folder because there could be reasons to ignore a rule check other than a commit message matching a pattern.A
Regexp
descendant class has been created to parse non-String
values that could be passed to theRule
s from the user configuration.Hopefully this approach provides room for future expansion of regular expression matching capabilities (enforcing that a commit message does match a pattern), as well as expanding which rules may be ignored in certain circumstances.
Further considerations
No pre-existing
poper
configurations should be affected by these changes.