In this page
What is a check?
A check is a mechanism used to enforce rules or validate conditions to ensure code quality and compliance during the development process.
Conceptually, you can think of a "check" as a function triggered by specific events of the development process, with well-defined inputs and outputs:
Check types
There are three types of checks, each running at a specific stage of the development workflow. They complement each other to enforce the commit policy effectively and should be used together for optimal developer experience and results.
| Check type | When | Purpose | What if the policy violated? |
|---|---|---|---|
| Local check | Runs locally, before creating a new commit. | Ensures that the new commit is compliant with the policy, thus protects your local repository. (Earliest check in the workflow!) | You cannot create the commit. |
| Push check | Runs on Bitbucket, when pushing one or more commits to the Bitbucket hosted repository. | Ensures that the pushed commits are compliant with the policy, thus protects the Bitbucket hosted repository. | You cannot push the commits. |
| Merge check | Runs on Bitbucket, before merging a pull request. | Ensures that the pull request is compliant with the policy, thus protects the target repository and branch. | You cannot merge the pull request. |
Learn more about each check type by clicking the links in the first column.
Check input
As shown in the diagram above, checks receive the following inputs:
Commit policy
The commit policy is a set of configurable rules that will be checked against every Git object you are trying to send into the Git repository.
Subjects
Subjects are one or more Git objects to run the check against.
Supported object types are:
- Commits (commit message, author, etc.)
- Branches (branch name)
- Pull requests (title, description, source and destination branches, commits)
Check output
Checks verify the subjects they receive against the commit policy and produce a result. The check result is shown clearly to the user, depending on the check type. Local checks show their results in the Git client's interface, while merge checks show their results in the Bitbucket web interface.
As shown in the diagram above, checks produce the following outputs:
Status
The check status is a summary of the check's execution, indicating whether the commit policy was satisfied, violated, or if there were any issues during the process (technical errors or timeouts).
Check runs complete with one of the following statuses:
| Status | Description |
|---|---|
| Satisfied | The check ran successfully, and all conditions in the commit policy were satisfied. |
| N violation(s) | The check ran successfully, but it detected one or more violations of the commit policy. |
| In progress | The check is currently in progress and has not yet completed. |
| Blocked | The check could not be run due to an external reason (e.g. missing or invalid commit policy configuration). |
| Timed out | The check took too long, and it was terminated due to exceeding the time limit. |
| Failed | An unexpected technical problem occurred during the run of the check. |
| Not run yet | The check has not been run yet. |
Violations
This list specifies which subjects violated which rules and how. An example violation is that "Git commit with hash #123abc has blank commit message". If the commit policy was satisfied, the violation list will be empty.
Each violation is described by the following details:
- Subject type (e.g. commit or pull request)
- Subject ID (e.g. commit hash or pull request ID)
- Description (e.g. "does not include a valid issue key" or "does not have the expected format")
- Hint (an optional suggestion on how to resolve the violation)
Questions?
Ask us any time.