User Guide 0.5.0
Why I need to check smart commits?
Typos and mistakes can be happen. By default the Bitbucket will not recognize typos and will not reject or warn developers. So developers are not aware that they have made a mistake
We cannot solve problems that we do not know. Faulty smart commits are accepted without error message
So if we are not aware that we have made mistakes, this will lead to the following serious complications in our projects:
Missing time logs = missing money: During the accounting therefore many time-logs may be missing.
Fuzzy/unclear project status: Issues will not be in the correct status
Broken communication: Important comments will not be added to issues
But also, if developers are aware that they have made mistakes, it would be annoying to fix them:
Higher workload and stress level for project leads and management. The controlling is hard and an exact accounting nearly impossible.
More effort for developer: Each known mistake needs to be fixed manually, a developer needs to change ticket status, time-logs and so on manually.
Our solution - Smart Commit Checker
The Smart Commit Checker for Bitbucket add-on works a pre-receive hook and enforces correct smart commits in commit message. If the hook will detect invalid commit messages, the hook will reject the commit and/or the push.
![](../__attachments/588447828/HookeEnable.png?inst-v=1326d43b-40f9-4cf4-9ee7-484df01991ac)
Time log enforcement and related use cases
The following time log configuration you will find in the configuration page of the hook
![](../__attachments/588447828/TimeCheckAdvanced.png?inst-v=1326d43b-40f9-4cf4-9ee7-484df01991ac)
Check | Description | Commit time | Push time |
---|---|---|---|
Time check | This option evaluates possible typing errors in time-log statements. If a #time keyword was found, a valid time value must be specified. Use case Typos can be happen. But the system should recognize this and the system should enforce this typos. Examples
CODE
CODE
CODE
CODE
| YES | YES |
Time check - comment enforcement | Each time-log needs a work-log description. Therefore a comment must also be given for each time specification. Examples
CODE
CODE
| YES | YES |
Time log required | This check will evaluates all commits of push actions. It enforces, that developers will add at least one time statement in at least one commit. Examples Scenario 1:
CODE
CODE
Push will fail, because no time log has been found. Scenario 2:
CODE
CODE
Push will not be rejected, because at least one time log has been found | NO | YES |
Advanced
This settings you do not need to change. Only would would like to add further restrictions regarding valid time-logs.
The first regular expression, will be used to identify valid time statements
The second regular expression, will be used validate given time values
Transition Check
The following transition configuration you will find in the configuration page of the hook
![](../__attachments/588447828/TransitionCheck.png?inst-v=1326d43b-40f9-4cf4-9ee7-484df01991ac)
Check | Description | Commit time | Push time |
---|---|---|---|
Transition check | The commit/push will be rejected, if the transition is not found or the transition cannot be executed in the current issue state The system will evaluate the requested transition. To do this, it will fetch all currently possible transitions and it will compare the detected transition request with the possible transitions Example Assumption: The issue TEST-1 has only one possible transition: “Start progress”
CODE
CODE
CODE
CODE
Restriction: It is not possible to evaluate transition chains like: TEST-1 #start-progress #resolve Also not if it would be valid. In this case two pushes are needed | YES | YES |
Ambiguous transition | The commit/push will be rejected, if the transition request is not obviously. Example 1 Assumption: The issue TEST-1 has two possible transitions: “Start progress” and “Start design”
CODE
The commit/push will be rejected, if the transition request is not obviously. Example 2 Assumption: The issue TEST-1 has two possible transitions: “Start progress” and “Resolve”
CODE
| YES | YES |
Transition required | This check will evaluates all commits of push actions. It enforces, that developers will add at least one transition statement in at least one commit. Examples Assumption: The issue TEST-1 has only one possible transition: “Start progress” Scenario 1:
CODE
Push will fail, because no transition has been found. Scenario 2:
CODE
Push will be accepted, because at least one transition has been found | NO | YES |
Comment Check
The following transition configuration you will find in the configuration page of the hook
![](../__attachments/588447828/CommentCheck.png?inst-v=1326d43b-40f9-4cf4-9ee7-484df01991ac)
Check | Description | Commit time | Push time |
---|---|---|---|
Comment check | The commit/push will be rejected, if the comment statement has been found, but no comment as message has been found. Example
JAVA
CODE
CODE
JAVA
| YES | YES |
Comment required | This check will evaluates all commits of push actions. It enforces, that developers will add at least one comment statement in at least one commit. Examples Scenario 1:
CODE
Push will fail, because no comment has been found. Scenario 2:
CODE
Push will be accepted, because at least one comment has been found | NO | YES |
Issue key
![](../__attachments/588447828/IssueKeyAdvanced.png?inst-v=1326d43b-40f9-4cf4-9ee7-484df01991ac)
Check | Description | Commit time | Push time |
---|---|---|---|
Issue key validation | The commit/push will be rejected, if no issue key has been found or existing issue keys are invalid. Example
JAVA
JAVA
JAVA
| YES | YES |
Escape character | With this option it is possible to escape issue keys. Examples Assumption: The escape character has been set to “!”
JAVA
JAVA
| YES | YES |
Application link
![](../__attachments/588447828/ApplicationLink.png?inst-v=1326d43b-40f9-4cf4-9ee7-484df01991ac)
Check | Description | Commit time | Push time |
---|---|---|---|
Only one | Only one application link needs to be reachable, for a valid configuration. | YES | YES |
Project links | Only the configured project links will be used to validate the commit message | YES | YES |
Local and remote check
With our hook it is possible to check the commit message at push time. Faulty commits are rejected and the commits have to be revised. This is annoying because there are maybe several commits affected, which makes changes difficult. So, why not do the same checks at commit time? That's why we introduced a REST API check. This REST-API check works with the same preferences, so the preferences can be managed centrally. By using a normal git-hook, you can perform the same checks locally at commit time and remote at push time.