Control Freak: extend "Look for Jira References" with "Beginning of the first line of commit message"
Hi!
In our environment, we use the following commit message schema:
TICKET-1234: Description
We enabled Control Freak’s “Jira Policy” > “Jira Reference Must“ > “Exist in Jira“.
However, quite often the description contains stuff that looks like a Jira Issue ID, but it’s not:
TICKET-1234: implements business feature ABCD-1234
Control Freak assumes that the second identifier is also a Jira ID, and rejects the commit.
As far as we are concerned, only the beginning of the commit message is where we might put a Jira issue.
Would it possible to add "Beginning of the first line of commit message" as an option to "Look for Jira References" in Jira Policy?
Thank you,
David
Comments (3)
-
repo owner -
reporter Unfortunately we already have many projects and repositories with active development, and a well-established commit message convention. I doubt we can easily change that. :(
I understand your concern about complexity, it really is a subtle difference.
However, I think there’s value in adding this feature, as it would allow for teams to adopt this rule even if they are not following the bracket convention, which is not universally accepted. (For example, they are not mentioned in the Atlassian guide.) This would be mainly beneficial for existing users, not new ones, as if you are just start a project on Bitbucket+Control Freak, it’s a no-brainer to adopt the commit conventions.
-
I believe the described problem can be solved by adding the project ‘TICKET’ to the Jira whitelist: https://bit-booster.com/hook/docs/#jiraWhite
- Log in to comment
Would you be willing to use the “Only-Check-Jiras-In-Brackets” control? It’s meant for exactly this scenario.
Of course devs would need to know to put the pertinent Jira ref in brackets, like so:
[TICKET-1234]: implements business feature ABCD-1234
I’m hesitant to add a new variation to cover your desired logic because things are already pretty complicated, and it will be hard to explain this variation (it’s pretty subtle). We also must allow multiple-jiras, so scenarios like this must also be handled:
TICKET-123, TICKET-456: implements business feature ABCD-1234
But I’m not completely opposed, either…