jolly-brancher 1.0.2

CLI tool that creates git branches from JIRA tickets

A sweet branch creation suite

Description

The overarching goal here is to facilitate developer time and remove duplicative work.

As a developer, I am more productive (and more descriptive) when I only have to write the description for what I’m working one one time (or barring that, as few times as possible).

In order to streamline and facilitate the developer’s workflow this tool aims to connect an arbitrary ticketing system (currently only JIRA is supported) to a git forge (currently only GitHub is supported).

Usage

Jolly brancher will, given a repository location create branches from JIRA tickets that automatically include ticket information in the branch, and branch name.

Given the repository base directory, you are provided with a list of repositories that you can act on (with tab completion):

After choosing a repository, you can either create a branch based on the contents of a ticket

Alternatively, if the branch name is well formed, you can create a PR against the parent of the branch, the tool will ask some questions and construct the body of the PR (it scans the CODEOWNERS file and suggests those users as tags), and create it:

If you decline to do so, then you will be redirected to the branch creation flow:

It will further create a pull review from an existing branch that is well formed:

It automatically populates the PR description with information from the ticket

Configuration

JIRA and git credentials are required in ~/.config/jolly_brancher.ini in the following format:

[jira]
auth_email = <[e-mail]>
base_url = https://<subdomain>.atlassian.net
token = <basic_auth_token>

[git]
pat = <personal_access_token>
repo_root = <~/path/to/local/repositories>
forge_root = https://github.com/<organization_name>/

Future Features

• Extract the contents of the comments in the branch and construct a description of the changes in the branch

• Perform in place analysis of the branch and add information to the PR - Were any tests added? - Run unit tests / linter (fetch from github actions) - Include other interesting statistics

• Automatically tag the owner of the files that were changed

• Pull the acceptance criteria from the ticket and format it into a list of checkboxes so the developer can indicate which are met by the current revision