Jira Hooks for Bitbucket

If this option is enabled, the related text field should contain a regular expression, which will define the syntax of the commit messages.

If the option is set, and the following regular expression is given,

^\[([A-Z]+)-(\d+)\](.|\n)+

then each commit message must start with a issue key, which is in brackets. Additionally after the key there must be a further description (e.g. "[TEST-1] further text" will be accepted. Only "[TEST-1]" as commit message will not be accepted. Also "TEST-1 and some further text" will not be accepted, because of the missing brackets. If the commit message do not match, the push or merge is blocked.

If this option is enabled, the related text field should contain a regular expression, which will define the valid status of issue key references.

If the option is set, and the following regular expression is given,

Reviewed|Integration Request

then a merge or a push can be done only, if the issue status is "Reviewed" or "Integration Request". (Of course also a more complex regular expression is possible.)

Attention

If you have a international company and if you will support different languages, then you have to respect this in the regular expression. For example the regular expression

To Do|Aufgabe

will support the german and english version of the related status.

If this option is enabled, the related text field should contain a valid JIRA JQL expression. A commit will be accepted only, if all issue key references will match the given JQL

If the option is set, and the following JQL is given,

(assignee=benni and fixVersion is not EMPTY)

then a given issue reference will be checked with this JQL. So a merge or push is only possible, if the assignee is the user "benni" and the fix version is set to any version.

(assignee=$currentUser)

You can also use the keyword "$currentUser", which will be replaced with the user wich will execute the merge or push. So the JQL ensure that the merge/push can only be done by the assignee of the issue.

• You can configure where to search for issue keys. Respect issue keys only in branches, only in commits or in branches and commits.
• In addition you can add an escape character to ignore specific issues 
• If the format of your issue keys are not the default, you can adjust the regular expression to search issue keys in branches and commit messages

Escape character

The character will be used in in combination with regular expressions. Please think about the character. 

If you want to mention another issue key in your commit message that is related to your change but should not be validated in relation to your work, then you can escape this issue key

TEST-2 my change has a relation to !TEST-1

If this options are set, a issue key must exist. Additionally the issue key must reference a valid issue in JIRA.

There are 5 possibilities to check issue-keys

Regarding the issue key in branch name you can explicitly disable some branches (e.g development or master). This exception is only valid for the push hook.

This is a push example, but the behavior regarding the merge hook is the same. (e.g. TEST-10000 does not exist)

git checkout -b my-branch/something
git commit -m 'TEST-1 TEST-10000 this is a example'
git push

git checkout -b my-branch/something
git commit -m 'TEST-1 TEST-10000 This is a example'
git commit -m 'This is a example'
git push

git checkout -b my-branch/TEST-1
git commit -m 'This is a example'
git push

git checkout -b my-branch/something
git commit -m 'TEST-1 This is a example'
git commit -m 'This is a example'
git push

git checkout -b my-branch/TEST-2
git commit -m 'TEST-1 This is a example'
git commit -m 'This is a example'
git push

You can specify how application links should behave. You can specify where issues will be searched

If selected, only configured project links will be used for validation

If the Bitbucket project is connected to one or more Jira projects via Application Link, then select this option. This will result in searching for matching issues only in the connected projects.

If this option is enabled, the related text field should contain a valid list of user group. If the user which will do the merge/push is in the given group, then the checks will not be evaluated.

This is a push example, but the behavior regarding the merge hook is the same.

If the option is set, and the group admin is configured. Additionally there are several commits which would block a push or merge (e.g. no issue key reference is available), then the behaviour is:

git commit -m 'this is a example'
git push

git commit -m 'this is a example'
git push

Based on a keyword in a commit message you can skip the all checks for this commit. The keyword can be configured via regular expression. As soon the regular expression match, the commit will not be validated

Example: .*non-functional.*

git merge -m "non-functional: just correct some typos" branch-name
git push

If the option is set, and the following regular expression is given,

then the checks will be validate only if:

• you will push commits in the master or develop branch
• you will merge pull requests in the master or develop branch

If you will push or merge change-sets in a branch with a other name, then the checks will not be evaluated and the merge/push is always allowed.

If enabled force pushes will not be checked

If this option is not enabled a push can be done only, if in the push contains no merge commit. This ensures that commits can be done via Bitbucket only. But of course there can be exceptions. Therefore you can allow merge commits, but only if there is a special keyword given.

Example: skip keyword = "merge-skip-fantasy"

"branch x"    ----- A 
                     \
                      \
"branch y"  --- FA -- merge --> push

If this option is enabled, the related text field should contain a regular expression, which will define the syntax/naming of all new branches. This check will only be executed, if a new branches will be created via a push from a client. The creation of a branch via Bitbucket do not execute this check.

If the option is set, and the following regular expression is given,

branches\\/[bug|feature]+\\/.*

then each new branch needs to match this regular expression.

If this option is enabled, the tag name is checked against the MAJOR.MINOR.PATCH pattern. According to the semantic version rules, MAJOR, MINOR and PATCH must be non-negative integers without leading zeros (e.g. 1.0.0)

If you want to change the default behaviour, you can do this in the Advanced section.

• Tag suffix string: By default, all version suffixes are not allowed. This means that you cannot append any further metadata such as "-final" to the version. With this option, you can add suffixes that are based on the semantic version rules. https://semver.org/lang/de/
• Allowed suffixes: If you do not agree with the standard for suffixes, you can adjust the standard behaviour of the validation with your own regex here
• Custom Naming Convention: If you don't want to use the standard versioning, you can overwrite it here. If you adjust the standard behaviour of the validation with your own regex, all other validations of the version number check will be deactivated. The tag name will then only be checked against this regex

This option is used to compare the tag name with a Jira project version.

This option is used to compare the tag name with more than just the Jira project version. The checked status must also match the status of the Jira version

The corresponding project key must be entered here so that the add-on knows in which project to search for valid versions

Here you can specify a JQL string that is used to search for issues in Jira. You can also decide in which case a push of the Tag is rejected. Either the JQL query must return a result or must not return a result.

In the JQL string, you can use the keywords $version and $projectKey (e.g. project=$projectKey and fixVersion = $version and resolution is empty). As soon as the JQL returns a result, the push of the tag is rejected. If you use the $version keyword, a valid Jira version must have been identified with the tag. If you use the keyword $projectKey, the projecty key must be configured.

If you want to change the default behaviour regarding the Jira connection, you can do this in the Advanced section.

Version detection

If the tag name is not the same as the name of the Jira version by default, you can use a RegEx to define how the version is extracted from the Tag name.

Application links:

You can specify how application links should behave. You can specify where issues will be searched

• If selected, only configured project links will be used for validation: If the Bitbucket project is connected to one or more Jira projects via Application Link, then select this option. This will result in searching for matching issues only in the connected projects.
• If selected, not all application links needs to be reachable/accessible: By default, all project links that have been configured must also be accessible. If not, then the validation fails. Set this option if a valid application link is sufficient.

The following options define the exceptional situations when the tags are not validated. If these conditions are met, creating a tag without validating the rules is allowed.