Easily Enforce Jira Workflows in Bitbucket — Validate and Block Commits Based on Configured Policies

As announced recently, Yet Another Commit Checker (YACC), a plugin for Atlassian Bitbucket, is now part of the Mohami app suite.

Commit checking is often the missing link in the comprehensive automation of professional development workflow, and YACC’s flexibility and simplicity makes it an easy win.

For teams in the Atlassian ecosystem, the YACC plugin works in lockstep with both Bitbucket and Jira to ensure pristine commits according to the rules — your rules. The plugin provides integrated commit and branch name monitoring that ensures a clean commit history and helps reinforce critical source control policies.

No matter how many times you repeat the rules to your team, someone is going to skip a requirement, a procedure, or both, if only once in a while. Frequent commits can tempt some to cut corners, creating little remnants of technical debt that adds up. And that’s not necessarily a product of anything other than your team’s focus on code, which is a good thing.

But it is one of the reasons automation makes sense. You can’t hold everyone’s hand when it comes to checking in code, but when quality is mandatory, and you demand both frequent and clean commits, automation is not optional.

What’s New in YACC

With its broad installed base, YACC’s already feature-rich functionality is enjoyed by Bitbucket users world-wide.

Part of Mohami’s commitment to taking on the YACC codebase included a detailed audit of open issues, opportunities for feature enhancements, and the state of legacy code.

The result? Important new features for common use cases, thorough lockdown of edge-case validations, and a renewed code base to support on-going feature development. Here are some of the features we added:

Jira User Impersonation

After reviewing 4 years of support issues, we found that common complaints were issues with Jira permissions. YACC queries Jira to verify Jira issues found in the commit message, and here are a few ways these requests can fail:

• A user mentions a ticket in their commit message (WIDGET-3), but they don’t have read access to the corresponding Jira project (WIDGET)
• Commits via an access key (e.g. commits by Jenkins/Bamboo) don’t have a corresponding Bitbucket/Jira user, and thus all Jira issue checks fail.

The solution: administrators can now specify a user to be used for all Jira queries made by YACC, regardless of who is pushing code. It’s easy to configure, by going to Administration → YACC Global Push Hook and editing the “Overridden Username” in the “Jira Authentication Configuration” section:

Note that the “Overridden username” setting is shared between the YACC pre-receive (aka push) hook and the YACC Bitbucket merge check.

YACC as a Bitbucket merge check, rather than a pre-receive hook

When enabled as a pre-receive hook, YACC checks all commits pushed to any branch; this means that work-in-progress commits often get snagged by rules that are only really intended for production branches.

In addition to being enabled as a pre-receive hook, YACC can now be enabled as a Bitbucket merge check. The two modes operate completely independently, with separate settings. You can enable one, both, or neither. When YACC is enabled as a merge check, checks are only performed in the context of a Pull Request.

If there are any failures, the pull request cannot be merged and the corresponding YACC failure explanation is displayed:

Verifying branch and commit reference the same Jira message

It’s easy to typo the Jira ticket referenced in a branch name. For example, the branch may be named bugfix/PROJ-12-fixit while the commit messages reference PROJ-13. This causes Bitbucket to link the corresponding pull requests to both PROJ-13 and PROJ-12, even though the code only relates to PROJ-13.

We’ve added a new option, “Require Matching Jira Issue in Branch Name”, to address this small yet common annoyance:

YACC Features — the tried and true

In addition to the new features listed above YACC contains many features that teams have used and relied on for years:

Configurable on a Global, Project, or Repo Basis

Rigid, one-size-fits-all policies tend to serve every project equally badly. YACC has three levels of settings:

• Global settings can be configured by administrators, by going to Administration → YACC Global Push Hook or to Administration → YACC Global Merge Checks
• Project settings can be enabled in the “Hooks” and “Merge Checks” sections of the project configuration.
• On the repository level, YACC settings can be “Inherited”, which uses the Project settings, or “Enabled”, which uses repository-specific settings.

In all cases, more specific settings override more general ones. So, if the repository-level hook is disabled, the global settings are applied. To override the global settings, simply enable YACC on the specific project or repository.

Commit requirements

The commit message, linked issues, and the commit authors can all be validated:

• Check that the commit message matches a specific regex — e.g. Jira enforce issue should come first, or enforce a maximum line length of the first line.
• Check that the commit message references a valid Jira issue
• Verify the Jira issues in the commit message match a specific JQL — e.g. enforce that only “In Progress” tickets are pushed to the repository.
• Verify the git commit author & email vs. the Bitbucket user & email — prevents common errors of git user and email misconfiguration

Branch requirements

Active development leads to many branches — release branches, experimental branches, pull request branches…without policies, it can quickly become a confusing mess. For this reason, YACC can validate branch names at branch creation:

• Check that branch names match a specific regex — e.g. only allow branches starting with the bugfix/, feature/, and experimental/ prefixes.
• Check that branch names contain the same Jira issue as the commits being pushed — this is enabled via the “Require Matching Jira Issue in Branch Name” setting, mentioned above.

Powerful exclusion rules

In a dynamic and fast-paced environment, rigid process often needs a release valve — YACC offers many ways to exclude a commit or branch from the active policies. Here are some of the ways YACC exclusions can be defined:

• Skip checks for certain users
• Skip checks for commit messages that match a regex (e.g. .*#skipchecks.*)
• Skip checks for branches that match a regex (e.g. experimental/.*)
• Skip checks on merge commits
• Skip checks on commits made via the Bitbucket web editor
• Skip checks of “Service User” (e.g. continuous integration) commits:

Custom error messages

Buttoning down commit practices doesn’t need to be an exercise in babysitting. YACC lets you define both the rules — what’s acceptable and what’s not — and the messages delivered when users violate the rules.

Each type of YACC policy comes with a custom message that can be displayed to the user when the policy fails, explaining the issue to them or referring them to external documentation.

Do you really need YACC?

Your team may be getting along just fine without automated validation of commits. After all, programmers at all levels are known for their strict adherence to team rules, the love of best practices, and unerring compliance with procedures.

If that describes your team, then problem solved.

But if you’re the gate-keeper of rules and policies, and you could use a little automated discipline in the ranks, there’s no more critical gate to keep than the one that protects your source repository.

In the commit attempt below Johnny J. may be a rockstar when it comes to writing multi-threaded message managers or enterprise neural networks, but a little bit of his personal GitHub configuration may be leaking into the company Bitbucket commit history:

Tiny impurities in the commit process may seem unimportant, but they can add up over time and affect the maintainability and integrity of the code base. Policies that go unenforced can quickly wither into the background noise of projects as symbolic yet meaningless attempts to improve process or discipline. That also reflects on team leaders and project managers. Everyone needs a little nudge once in a while. And everyone appreciates being treated the same way.

When the right commit rules are automated, the result is superior quality, consistent metadata, and a cleaner source code repository.

Try it for free right now

Want to try YACC for free? YACC and other powerful plugins from Mohami are available from the Atlassian Marketplace.

Your Confluence administrator can start plugin installation with a single mouse click and you can experience the benefits of YACC and easily enforce Jira workflows in Bitbucket

1. Log into your Confluence instance as an admin and choose Add-ons, or go to the Atlassian Marketplace here.
2. Locate YACC and click Try it free.
3. You’re all set! Click Close in the Installed and ready to go dialog.

YACC supports both server and data center deployments.

Even Better Together

As simple as it is to see ROI from YACC, it gets even better when used with complementary macros. Checkout these Bitbucket macros. They can help take your development to the next level…

• Prevent accidentally exposing sensitive data with Security for Bitbucket
• Host documentation or any static website directly from a repository, with Pages for Bitbucket
• Easily create and share code snippets in Bitbucket Server with Snippets for Bitbucket

Mohami extends the Atlassian ecosphere with a suite of sensible, productivity-boosting macros that plug key gaps in functionality, unlock integration between platforms, and streamline development operations.