In this page

Configuring Better Commit Policy for Bitbucket

This page discusses the configuration settings which affect the behavior of the app globally, regardless of which project and which repository it is used in.

All the global configuration settings came with sensible defaults that work as expected in most cases.

System settings

You can change these settings via Bitbucket configuration properties (defined in the bitbucket.properties configuration file).

Modifying these properties requires you to restart Bitbucket. For a detailed how-to, please see the Configuring application properties page in the official Bitbucket documentation.

To verify if your custom values are correctly picked up, increase the logging level to DEBUG and you should see log lines like this: 

2019-09-02 11:24:11,582 DEBUG [threadpool:thread-1] c.m.b.p.c.s.SystemSettingsManager System property <plugin.bcp.bypass.accessKeys> is set to true
Verifying commits pushed by SSH access keys

(since app version 4.2.0)

Bitbucket allows you to use SSH access keys as way of authentication. Its primary use is to allow external systems (typically a build system) to authenticate to Bitbucket via SSH, without the need of storing usernames and passwords on the external system's side.

Authenticating by an access key means that the external system will be represented with a so-called "service user", not a regular user, within Bitbucket. As it is not a regular user, Better Commit Policy for Bitbucket will not be able to connect to Better Commit Policy to Jira, where the actual verification is done.

Why? As you know, the connection between Bitbucket and Jira requires an impersonation-enabled application link. Impersonation requires the user (the service user in this case) exist in both of the linked applications. In this case, as the service user does not exist in Jira, the authentication will fail.

You can activate one of these two behaviors to handle the problem:

  1. Always reject: all commits pushed by access keys are automatically rejected without verification. This is the default behavior, being the safer option of the two.
    In this mode, a line like this will be written to the Bitbucket log every time when an access key pushes a commit to Bitbucket: 
    2019-09-10 14:01:47,406 WARN  [hook-callback:thread-1] 4d2ac794bb228e7c @1L7SHAHx841x86x0 1ura5ig 127.0.0.1 SSH - git-receive-pack '/project_1/rep_1.git' c.m.b.p.c.c.CommitPolicyVerificationHook Rejecting commits pushed by access key "Access Key User - foobar@acme.com"
    When administrators see this, they should either switch to the "always accept" option or configure the external system not to push commits.
  2. Always accept (bypass): all commits pushed by access keys are automatically accepted without verification.
    Activate this only if you have an external system that wants to use a read/write-enabled access key to push commits to Bitbucket.
    This mode can activated by setting the following Bitbucket configuration property: 
    plugin.bcp.bypass.accessKeys=true

Questions?

Ask us any time.