Smart Commits Checker for Bitbucket

What is the Smart Commits Checker for Bitbucket Plugin?

The Smart Commit Checker for Bitbucket add-on aims to validate smart commit keywords and their associated actions in advance. The goal is to detect and prevent errors in the process as early as possible to keep your project consistent. The add-on "Smart Commit Checker for Bitbucket" prevents the specification of e.g. wrong time entries or impossible transitions directly during the commit/push of the change-set. The add-on "Smart Commits Checker for Bitbucket" is an enrichment in your development process, because it reduces errors and increases the consistency of your projects.

Why it is needed?

By default Bitbucket will not recognize typos and will not warn or inform developers. So developers are not aware that they have made mistakes

As result: We cannot solve problems that we do not know. Faulty messages 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 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

The Smart Commit Checker for Bitbucket 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.

The addon will provide two strategies to evaluate the commit message. It provides a local git hook commit-check and a remote push to evaluate a set of commits.

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

CODE

//Reject: no time unit
TEST-1 #time 1 
//Reject: no valid time unit
TEST-1 #time 1j 
TEST-1 #time 3h4j
//Reject: no issue key found
#time 3h
//Accept
TEST-1 #time 3h

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

//Reject: no comment given
TEST-1 #time 1 
//Accept
TEST-1 #time 1h #comment this is just a demo comment

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

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

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

Scenario 2:

CODE

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

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 if you 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”

CODE

//Reject: Typo in transition statement
TEST-1 #start-rogress
//Reject: Unknown transition
TEST-1 #something-wrong
//Reject: No issue key
#start-progress
//Accept
TEST-1 #start-progress

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

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

//Reject: The requested status is ambiguous
TEST-1 #start (What is meant? #start-progress or #start-design)

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

//Accept: The requested status is obviously
TEST-1 #start

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

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

Push will fail, because no transition has been found.

Scenario 2:

CODE

//Commit 1 with transtion
TEST-1 #start
//Commit 2 no transition
TEST-1 some commit message

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

JAVA

//Reject: Typo in comment statement
TEST-1 #commnt my dummy commit message
//Reject: missing commit message
TEST-1 #comment
//Reject: missing issue key
#comment my dummy commit message
//Accept:
TEST-1 #comment my dummy commit message

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

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

Push will fail, because no comment has been found.

Scenario 2:

CODE

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

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

NO

YES

Issue key validation

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

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

YES

Escape character

With this option it is possible to escape issue keys.

Examples

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

JAVA

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

YES

Application link

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?