Alternatives

In this page

Jira Commit Acceptance Plugin

If you are long-time Jira user, you may know that there was (is) another app existing with similar functionality. You may be wondering how the old Jira Commit Acceptance Plugin compares to the new Better Commit Policy for Jira?

A secret first: the original developer of Commit Acceptance Plugin is now working on Better Commit Policy! Several years ago, Aron built the old app based on an idea initiated by Atlassian. Long time has gone since then, and today Jira has much better features to support the same concept.

Some of the modern Jira features we take advantage of in Better Commit Policy:

• Powerful JQL (for super-flexible conditions)
• Hot-deploys with the PLUGIN2 framework (for easy installation and upgrading without Jira restart)
• Standard REST API

Overall, we consider Better Commit Policy as a modern, scalable, maintained re-implementation of Commit Acceptance Plugin. Not to mention, that Midori offers commercial support for the new app.

Comparison

Migrating from Jira Commit Acceptance Plugin

This sections guides you through the process of migrating your repositories from Commit Acceptance Plugin to Better Commit Policy.

Commit Acceptance Plugin supported hook scripts written in Perl and Python, but Better Commit Policy only supports Python. If you have been using Perl scripts so far, and Python is not installed on your server yet, install that now.

Then, for each legacy hook script:

1. Backup the legacy script (.py/.pl and .bat/.sh files) by appending .old to the end of the file extension.
   On Windows, make sure extensions are visible in Windows Explorer to correctly do that.
   On Linux, also remove execute permissions.
   This way you disabled the legacy script, but you can still return to that if something goes wrong.
2. Create a new commit policy that replaces the legacy commit acceptance settings.
   You can look up the legacy settings by checking the projectKey variable in the legacy script, and visiting the commit acceptance settings of that project in Jira. You primarily need to use the "Commit message must contain issue keys from a JQL query" condition as a replacement for the old settings. (Tip: consider making your policies stronger by using the other conditions, too.)
3. Generate and install the new hook script for the newly created policy.
4. Run the new hook script in diagnostic mode to check if everything works fine.
   If you are using Subversion and the new hook script cannot find the svnlook application, then open both the legacy and the new script, and copy the value of the svnLookPath (legacy script) variable to svnlook_path (new script). Please be careful: the variable names are different!
5. Do some testing by commiting changes that should be rejected (negative testing) or accepted (positive testing).
6. Have a chocolate.

At the end, don't forget to uninstall Commit Acceptance Plugin from Jira. You also want to delete the legacy scripts backed up in the first step of the previous guide.

Hand-written hook scripts

This may be tempting to add hand-written hook scripts to your repositories, but there are several disadvantages of this approach.

Comparison

First off, these scripts are difficult to maintain and modify. If your policy changes, you need to go through all hook scripts and make the modifications in each of those one by one, as the logic is captured in the scripts, not in the serverside. For a large number of repositories, this is time-consuming and error-prone. If you use Better Commit Policy, you can create a single and consistent policy, and verify that in any number of repositories. You can update the single shared policy, and the change will immediately take effect in all repositories!

Second, lack of the integration between the hook scripts and Jira makes you less efficient. For example, you can check if there is a Jira issue key mentioned in the commit message, but you can only check if it is formally there. Unless you communicate with Jira, you can't check if that points to an existing issue, if the issue is unresolved, is in the right project, is in the current sprint, etc. Similarly, you can roughly check the committer's identity by verifying his username, but can't check if he has an active Jira account and if he is in the developers group, for instance.

The only advantage of this approach is that you save the license fees of Better Commit Policy. Considering that we offer 10$ Starter licenses and fair pricing for larger Jira tiers, this isn't a real advantage.

Questions?

Ask us any time.