Create rule which allows to match the message against a configurable message format

[hferentschik]

I would like to have a rule which allows verifying a certain format of the first lines of the commit message. In the projects I am working we, for example, want to ensure that each commit message starts with the issue key the commit is related to, eg:

JIRA-1001 Bla bla

I would like to do something like (using regexps):

JIRA-[0-9]+ [A-Z].*

Looking at the current rules they are all static. What would be your idea around configurable rules?

[vbatts]

in the "first line" or matched at all in the message?

[hferentschik]

in the "first line" or matched at all in the message?

In this particular case I am after verifying the first line, but I guess in a more generically it might make sense to be able to verify the message as a whole as well. Maybe this would be two different rules or just configurable via an option (whether to apply the rule to the first line or whole message).

[vbatts]

i'm thinking that the rules to run will just be able to accept a value. like git-validation -run "dco,message_regexp='^JIRA-[0-9]+ [A-Z].*$'". This will take a little massaging, but should not break anyone's usage.

[hferentschik]

i'm thinking that the rules to run will just be able to accept a value. like git-validation -run "dco,message_regexp='^JIRA-[0-9]+ [A-Z].*$'".

Ok, so no config file or similar? What's about multiple arguments? So in your example - dco,message_regexp='^JIRA-[0-9]+ [A-Z].*$ - I guess dco and message_regexp are the names of the rules to enable. The equals after message_regexp is then a way to pass config values into the rule, in this case the regular exression. What if a rule would take more than one parameter? Is it up to the rule to handle the incoming value and potentially split it into multiple config values?

[vbatts]

in #31 i refactored a bit so that there could be multiple instances of valued rules like .. -run "message_regexp='foo',message_regexp='bar'".
dco is an existing rule being chosen to run as well.
If the rule needs multiple parameters, i suppose that would have to be parsed inside the rule itself, because it would get a string of the value

[hferentschik]

If the rule needs multiple parameters, i suppose that would have to be parsed inside the rule itself, because it would get a string of the value

ok

[vbatts]

I've merged the feature now. You can `go get -u ...` and try it out!

…

On Thu, Oct 12, 2017 at 11:18 AM, Hardy Ferentschik < ***@***.***> wrote: If the rule needs multiple parameters, i suppose that would have to be parsed inside the rule itself, because it would get a string of the value ok — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#30 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAEF6b0ffqrrL-_IulGmUeJkQlLCEl81ks5sri3TgaJpZM4PteF5> .

[hferentschik]

Works like a charm. Thanks :-)

[vbatts]

yw!

…

On Thu, Oct 12, 2017, 15:39 Hardy Ferentschik ***@***.***> wrote: Works like a charm. Thanks :-) — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#30 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAEF6Xjwpqjgqcz-nIL38Ypqv9McvgHuks5srmdtgaJpZM4PteF5> .