A GitHub App/Action that automates the creation of issue branches (either automatically, or after assigning an issue, or after commenting on an issue with a ChatOps command: /create-issue-branch or /cib).

Built in response to this feature request issue: isaacs/github#1125 (that issue is now closed and the discussion continuous here and here)

• Installation
• Usage
• Configuration
• Development
• Feedback, suggestions and bug reports
• Contributing
• License

There are two options to run this app as part of your development workflow:

1. Install it as an app for your organization/account/repository
2. Run it as an action in your GitHub action YAML configuration

Option 1 is easiest if you're developing on GitHub.com, option 2 gives you full control how and when the app runs in your development workflow.

The App is free to use for personal, and public organization repositories. There is a paid plan on the GitHub Marketplace if you want to use it for private organization repositories.

You can install the app for your organization/account/repository from the GitHub Marketplace

Add this to your workflow YAML configuration:

on:
  # The issue.opened event below is only needed for the "immediate" mode.
  # The issue.assigned event below is only needed for the default ("auto") mode.
  issues:
    types: [ opened, assigned ]
  # The issue_comment.created event below is only needed for the ChatOps mode.
  issue_comment:
    types: [ created ]
  # The pull_request events below are only needed for pull-request related features.
  pull_request:
    types: [ opened, closed ]

jobs:
  create_issue_branch_job:
    runs-on: ubuntu-latest
    steps:
      - name: Create Issue Branch
        uses: robvanderleek/create-issue-branch@main
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

The latest GitHub Marketplace release is not always up-to-date (due to this). To have access to all features please use version @main

The GitHub Action has one output variable: branchName, which contains the name of the branch that was created, or already exists in the repository. You can use this output in downstream actions. For a trivial example see this workflow.

Uninstall the App by navigating to: Settings > Applications > Installed GitHub Apps > Create Issue Branch > Configure. At the bottom of that page there's a button to uninstall the Create Issue Branch app.

You can also use this link to navigate to the configuration page mentioned above.

This app can support your development workflow in three ways (modes): auto, immediate, and chatops.

In "auto" mode the typical development workflow is:

1. An issue is created, for example: Issue 15: Fix nasty bug!

some time may pass

2. The issue is assigned
3. When the issue is assigned this app will create a new issue branch (for the example issue this branch will be called issue-15-Fix_nasty_bug)

In "immediate" mode the typical development workflow is:

1. An issue is created, for example: Issue 15: Fix nasty bug!
2. Immediately after creation, this app will create a new issue branch (for the example issue this branch will be called issue-15-Fix_nasty_bug)

In "chatops" mode the typical development workflow is:

1. An issue is created, for example: Issue 15: Fix nasty bug!

some time may pass

2. A developer that wants to work on this issue gives the ChatOps command /cib as a comment on the issue
3. This app will create a new issue branch (for the example issue this branch will be called issue-15-Fix_nasty_bug) By default the app notifies creation is completed with a comment on the issue.

GitHub Apps & Actions allow you to define custom and advanced automated workflows. Examples of Apps & Actions that can be used alongside this app to compose tailored issue workflows are:

• project-bot: App for project automation
• github-actions-automate-projects: Action for project automation
• auto-card-labeler: Automatically label issues/PRs

To get inspired of what is possible with Actions workflows, see this configuration .

Remember to always pick the simplest issue workflow that fits your project.

This app does not require a configuration. However, if you want to override the default behaviour you can do so by placing a YAML file in your repository at the location: .github/issue-branch.yml with the overrides.

If the app has a problem with your configuration YAML (e.g.: invalid content) it will create an issue with the title " Error in Create Issue Branch app configuration" in the repo. Subsequent runs with an invalid configuration will not create new issues, only one stays open.

Organization/user wide configuration prevents a configuration in every individual repo and is supported by putting the YAML file .github/issue-branch.yml in a repository called .github. So, if your organization/username is acme, the full path becomes: https://github.com/acme/.github/blob/main/.github/issue-branch.yml.

Remember to give the GitHub App access to the .github repository, otherwise it can't load the organization/user wide configuration.

Repository configuration files override the organization/user wide configuration file.

The default mode is "auto", meaning a new issue branch is created after an issue is assigned.

You can change the mode to "immediate", meaning a new issue branch is created immediately after creating an issue, by putting the following line in your issue-branch.yml:

mode: immediate

You can change the mode to "chatops", meaning a new issue branch is created after commenting on an issue with /create-issue-branch or /cib, by putting the following line in your issue-branch.yml:

mode: chatops

By default the app comments on the issue after creating a branch.

You can change this default behaviour, and make the app silent, by putting the following line in your issue-branch.yml:

silent: true

Branch names are generated from the issue, there are 3 built-in flavours or it can be customized.

The 3 built-in flavours are:

1. tiny => an i followed by the issue number, for example: i15
2. short => the word issue followed by the issue number, for example: issue-15
3. full => the word issue followed by the issue number followed by the issue title, for example: issue-15-Fix_nasty_bug

The default is full, other types can be configured in the YAML like this:

branchName: tiny

or

branchName: short

To customize branch names you can give branchName a string value where ${...} placeholders are substituted with fields from the GitHub issue or environment variables.

For example, if you would like to have your branch names contain only the issue number and title (similar to the GitLab branch naming convention), configure it like this:

branchName: '${issue.number}-${issue.title}'

See test/fixtures/issues.assigned.json for all possible placeholder names.

Substitution placeholders can also refer to environment variables in GitHub Actions. Environment variable names need to be prefixed with a % character to distinguish them from GitHub issue fields.

For example, if the environment variable SOME_VAR is defined outside the action it can be used in a branch name like this:

branchName: '${issue.number}-${%SOME_VAR}-${issue.title}'

Substitution values can be "sliced" with the slice operator: [start, end]. This operator behaves exactly like the JavaScript String slice() method .

For example, put this in your configuration YAML to limit issue titles to 64 characters:

branchName: '${issue.number}-${issue.title[0,64]}'

Substitutions for ${...} placeholders can be lowercased by putting a , before the closing curly. Likewise, substitutions can be uppercased by putting a ^ before the closing curly.

For example, issue titles can be lowercased in branch names like this:

branchName: '${issue.number}-${issue.title,}'

or if you want the complete title in uppercase:

branchName: '${issue.number}-${issue.title^}'

Substitutions can be left padded with zeros using the %n operator, where n is the minimum number of characters of the substitution result.

For example, issue numbers can be left padded with zeros like this:

branchName: 'issue-${issue.number%4}'

In the example above, if the issue number is 123, the resulting branch name will be issue-0123.

Characters that are not allowed in Git branch names are replaced by default with an underscore (_) character. You can configure a different replacement character as follows:

gitSafeReplacementChar: '-'

The above configuration would generate the following branch name for issue 15 that has the title "Fix nasty bug": issue-15-Fix-nasty-bug.

Furthermore, you also can replace arbitrary characters in the branch title:

gitReplaceChars: 'ab/'

The above configuration replaces all occurences of the characters 'a', 'b' and '/' in the branch title.

This app can automatically link a pull request to the issue for which the issue branch (of the pull request) was created. You can enable this feature with:

autoLinkIssue: true

Be aware that the app needs to be able to find the issue number in the branch name, otherwise this feature will not work. This feature only works if one of the following is true for your app configuration:

• You use the default branchName setting
• Your branchName setting is tiny, short or full
• Your branch name starts with the issue number
• Your branch name contains the string issue- (case insensitive) followed by the issue number, for example: Project-A-Issue-123-Rewrite_in_Clojure

This app can close issues automatically for you when a pull request for an issue branch is merged. You can enable this feature with:

autoCloseIssue: true

Be aware that the app needs to be able to find the issue number in the branch name, otherwise this feature will not work. This feature only works if one of the following is true for your app configuration:

• You use the default branchName setting
• Your branchName setting is tiny, short or full
• Your branch name starts with the issue number
• Your branch name contains the string issue- (case insensitive) followed by the issue number, for example: Project-A-Issue-123-Rewrite_in_Clojure

You can override the source branch (by default the "default branch" of the repository is used) in the configuration like this:

defaultBranch: 'dev'

You can override the source branch based on the issue label.

For example, if you want branches for issues with the enhancement label to have the dev branch as a source, and branches for issues with the bug label to have the staging branch as a source, add this to your configuration YAML:

branches:
  - label: enhancement
    name: dev
  - label: bug
    name: staging

The label field also takes a list of label names. In that case all labels in the list must be matched by labels of the issue. For example:

branches:
  - label:
      - enhancement
      - docs
    name: docs
  - label: enhancement
    name: dev

In the configuration above issues with the labels enhancement and docs will have the docs branch as a source, while issues with an enhancement label but not a docs label will have the dev branch as a source.

When issues have multiple labels the branch of the first match (based on the order in the configuration YAML will be used).

If a configured branch does not exist in the repository the default branch is used.

Branch names can be prefixed based on the label of an issue.

For example, if you want branches for issues with the enhancement label to have the feature/ prefix and branches for issues with the bug label to have the bugfix/ prefix, add this to your configuration YAML:

branches:
  - label: enhancement
    prefix: feature/
  - label: bug
    prefix: bugfix/

You can use ${...} placeholders in the prefix to substitute fields from the GitHub issue assignment JSON object. For example, if you want the GitHub login name of the user that created the issue in the branch prefix, add this to your configuration YAML:

branches:
  - label: enhancement
    prefix: feature/${issue.user.login}/

See test/fixtures/issues.assigned.json for all possible placeholder names.

Runs of this App/Action can be skipped based on the label of an issue.

For example, if you don't want to automatically create branches for issues with the question label, add this to your configuration YAML:

branches:
  - label: question
    skip: true

Wildcard characters '?' (matches any single character) and '*' (matches any sequence of characters, including the empty sequence) can be used in the label field.

For example, to set the default/fallback prefix issues/ for issues that do not have the enhancement or bug label, use this configuration:

branches:
  - label: enhancement
    prefix: feature/
  - label: bug
    prefix: bugfix/
  - label: '*'
    prefix: issues/

You can use this default/fallback behaviour also to run the App/Action only for certain issue labels. For example, put this in your configuration YAML if you want to run the App/Action only for issues with the bug label:

branches:
  - label: bug
    skip: false
  - label: '*'
    skip: true

Remember to put quotes around a single asterisk ('*') in YAML

Automatically open a (draft) Pull Request for the newly created branch. Enable this feature in your configuration YAML, for draft pull requests use:

openDraftPR: true

and for regular pull requests use:

openPR: true

Be aware that draft pull requests are not available in all repositories types, see the GitHub documentation for details.

You can override the pull request target branch based on the issue label.

For example, if you want (draft) pull requests for issues with the bug label to have the development branch as a source and have the pull request target branch set to hotfix, add this to your configuration YAML:

branches:
  - label: bug
    name: development
    prTarget: hotfix

You can skip the creation of branches based on the issue label. This configuration option is typically used together with the openPR/openDraftPR option to automatically create a (draft)PR between branches.

For example, to automatically open a PR to merge the develop branch in the release branch when the issue has a release label, add this to your configuration YAML:

openPR: true
branches:
  - label: release
    name: develop
    prTarget: release
    skipBranch: true

When the App opens a new (draft) Pull Request it can also copy over the following attributes from your issue:

• Description
• Labels
• Assignee
• Projects (only available in GitHub Action, not in the App)
• Milestone

You can enable this behaviour per attribute in the configuration:

copyIssueDescriptionToPR: true
copyIssueLabelsToPR: true
copyIssueAssigneeToPR: true
copyIssueProjectsToPR: true
copyIssueMilestoneToPR: true

Automatically opening a (draft) PR for an issue requires an empty commit on the newly created branch (this is a requirement by GitHub). This first empty commit might trigger GitHub Actions CI workflows. You can skip these workflows with the following configuration option:

prSkipCI: true

When this option is enabled, a Conventional Commit prefix (including a gitmoji) is automatically added to the PR title based on issue & PR labels.

For example, if there's an issue "Fix nasty bug" and accompanying branch issue-123-Fix-nasty-bug, where either the issue or the PR are labeled as "bug", then whenever a Pull Request for the branch is opened (automatically or manually) Create Issue Branch will prepend "fix: 🐛" to the Pull Request title, for example "fix: 🐛 isssue 123 Fix nasty bug".

Conventional PR titles create a clear and beautiful Git history. They also make it possible to implement automated Semantic Versioning of your software using tools such as Semantic Release.

By default, for issues/PRs that are labeled with "breaking change" (or "breaking-change") there will be an exclamation mark added to the title, for example: "feat!: ✨ Change in API".

You can enable conventional Pull Request titles with the following configuration option:

conventionalPrTitles: true

This feature works best if you enable only "Allow squash merging" on your repository settings page:

There are three prefix styles you can select: semver (default), semver-no-gitmoji, and gitmoji. You can configure the prefix style with the following configuration option:

conventionalStyle: semver

or:

conventionalStyle: semver-no-gitmoji

or:

conventionalStyle: gitmoji

With the "semantic versioning" (semver) style, Create Issue Branch will prepend "fix: 🐛" to the Pull Request title, for example "fix: 🐛 isssue 123 Fix nasty bug"

With the semver-no-gitmoji style, Create Issue Branch will prepend "fix: " to the Pull Request title, for example "fix: isssue 123 Fix nasty bug"

With the gitmoji style, Create Issue Branch will prepend "🐛 " to the Pull Request title, for example "🐛 isssue 123 Fix nasty bug"

Prefixes and emoji's for labels can be configured through the option conventionalLabels. This is the default:

conventionalLabels:
  fix:
    bug: '🐛'
    dependencies: '⬆️'
    security: '🔒'
  feat:
    enhancement: '✨'
  build:
    build: '🔧'
  chore:
    chore: '♻️'
  ci:
    ci: '👷'
  docs:
    documentation: '📝'
  style:
    style: '💎'
  refactor:
    refactor: '♻️'
  perf:
    performance: '⚡️'
  test:
    test: '✅'
  breaking:
    breaking-change: '💥'
    breaking change: '💥'

For example, to change the emoji for label "bug":

conventionalLabels:
  fix:
    bug: '🚑'

Or to add a new label type for features:

conventionalLabels:
  feat:
    new-stuff: '🚀'

Or to add a new prefix:

conventionalLabels:
  my-prefix:
    my-label: '🏷️'
    breaking: true

Note: for backwards compatibility, features and feat will both result in a prefix feat.

The default message displayed in the issue comments after a branch is created (and silent mode is not enabled) is:

Branch ${branchName} created!

You can customize this message with the commentMessage option in the configuration YAML. In the string value for this option ${branchName} is substituted with the name of the newly created branch and other ${...} placeholders are substituted with fields from the GitHub issue assignment JSON object.

For example, if you would like to have the original issue title in the comment, confgure it like this:

commentMessage: 'Branch ${branchName} created for issue: ${issue.title}'

See test/fixtures/issues.assigned.json for all possible placeholder names.

The features below are experimental and may be removed some day or promoted to standard features.

As discussed in this issue, enabling this feature allows you to give the branch name as an argument to the /cib ChatOps command. For example: /cib Simple NPE fix will create a branch named issue-1-Simple_NPE_fix

experimental:
  branchNameArgument: true

Unit Tests and coverage are implemented using Jest and Istanbul.

The snippet below shows the script which, upon execution, generates a coverage directory with coverage reports that are then used by CodeCov to generate a dashboard (description for CodeCov below the snippet)

"coverage"
:
"jest --collect-coverage"

Note: CodeCov is a third-party test coverage tool which can be associated to your GitHub repository to create a dashboard based on visual representations of test coverage. CodeCov also tracks improvements in coverage on every push once linked. For more information: https://docs.codecov.io/docs

Used CodeCov to generate a coverage dashboard through a bash command run in the prod/dev pipelines.

The bash script can only run if:

• You have a 'codecov' account (just log in with your GitHub account)
• The repository on your GitHub account is linked to your CodeCov account.
• You have a GitHub secret named CODECOV_SECRET_TOKEN which has the value of the token generated by CodeCov

Please note that once your repository is linked with your CodeCov account you will receive an authentication token generated by CodeCov which you will have to save as CODECOV_SECRET_TOKEN in your GitHub secrets for this repository. The bash script upon execution will provide a link to your CodeCov dashboard on your account.

The snippet below shows the workflow which runs the coverage command through yarn and bash script to generate a dashboard on CodeCov.io:

 - run: yarn run coverage
 - run: bash <(curl -s https://codecov.io/bash) -t ${{secrets.CODECOV_SECRET_TOKEN }}

Please create an issue here: https://github.com/robvanderleek/create-issue-branch/issues

If you like this Action/App, please star ⭐ it.

The list below contains features that might or might not be implemented in the future. Comment or +1 if this feature is useful for your use-case.

• Add Projects integration (see issue #142)
• Add issue label management functionality (see issue #177)
• Choose branch to branch from in ChatOps mode (see issues #155 and #213)

If you have suggestions for how create-issue-branch could be improved, or want to report a bug, open an issue! All and any contributions are appreciated.

For more, check out the Contributing Guide.

ISC © 2019 Rob van der Leek [email protected] (https://twitter.com/robvanderleek)