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.

Time log enforcement and related use cases

The following time log configuration you will find in the configuration page of the hook

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

//Reject: no time unit
TEST-1 #time 1 
CODE
//Reject: no valid time unit
TEST-1 #time 1j 
TEST-1 #time 3h4j
CODE
//Reject: no issue key found
#time 3h
CODE
//Accept
TEST-1 #time 3h
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

//Reject: no comment given
TEST-1 #time 1 
CODE
//Accept
TEST-1 #time 1h #comment this is just a demo comment
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:

//Commit 1 no time log
TEST-1 some commit message
CODE
//Commit 2 no time log
TEST-1 some commit message
CODE

Push will fail, because no time log has been found.

Scenario 2:

//Commit 1 no time log
TEST-1 some commit message #time 1h
CODE
//Commit 2 no time log
TEST-1 some commit message 
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

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”

//Reject: Typo in transition statement
TEST-1 #start-rogress
CODE
//Reject: Unknown transition
TEST-1 #something-wrong
CODE
//Reject: No issue key
#start-progress
CODE
//Accept
TEST-1 #start-progress
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”

//Reject: The requested status is ambiguous
TEST-1 #start (What is meant? #start-progress or #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”

//Accept: The requested status is obviously
TEST-1 #start
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:

//Commit 1 no transition
TEST-1 some commit message
//Commit 2 no transition
TEST-1 some commit message
CODE

Push will fail, because no transition has been found.

Scenario 2:

//Commit 1 with transtion
TEST-1 #start
//Commit 2 no transition
TEST-1 some commit message 
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

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

//Reject: Typo in comment statement
TEST-1 #commnt my dummy commit message
JAVA
//Reject: missing commit message
TEST-1 #comment
CODE
//Reject: missing issue key
#comment my dummy commit message
CODE
//Accept:
TEST-1 #comment my dummy commit message
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:

//Commit 1 no comment
TEST-1 my dummy commit message
//Commit 2 no comment
TEST-1 my dummy commit message
CODE

Push will fail, because no comment has been found.

Scenario 2:

//Commit 1 with comment
TEST-1 my #comment dummy commit message
//Commit 2 no comment
TEST-1 my dummy commit message
CODE

Push will be accepted, because at least one comment has been found

NO

YES

Issue key

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

//Reject: INVALID-1 does not exist
INVALID-1 my dummy commit message
JAVA
//Reject: No issue key 
my dummy commit message
JAVA
//Reject: Valid issue key found
TEST-1 my dummy commit message
JAVA

YES

YES

Escape character

With this option it is possible to escape issue keys.

Examples

Assumption: The escape character has been set to “!”

//Reject: INVALID-1 does not exist
TEST-1 my dummy commit message. realates to INVALID-1
JAVA
//Accept: INVALID-1 is escaped
TEST-1 my dummy commit message. realates to !INVALID-1
JAVA

YES

YES

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.

See How to configure a local commit hook?