go-jira

Simple command line client for Atlassian's Jira service written in Go.

GDPR USERNAME DISCLAIMER

When this tool was initial written the "username" parameter was widely used in the Atlassian API. Due to GDPR restrictions this parameter was been almost completely phased out other then V1 login. The "--user" field is still provided as a default global, however moving forward any usage of this field should be phased out in favor of the "--login" option.

Commands which previously took a username will now expect an email address such as watch, create, assign, etc...

Install

Download

You can download one of the pre-built binaries for go-jira here.

Build

You can build and install the official repository with Go (before running the below command, ensure you have GO111MODULE=on set in your environment):

go get github.com/go-jira/jira/cmd/jira

This will checkout this repository into $GOPATH/src/github.com/go-jira/jira/, build, and install it.

It should then be available in $GOPATH/bin/jira.

Usage

Setting up TAB completion

Since go-jira is built with the "kingpin" golang command line library we support bash/zsh shell completion automatically:

• https://github.com/alecthomas/kingpin/tree/v2.2.5#bashzsh-shell-completion

For example, in bash, adding something along the lines of:

eval "$(jira --completion-script-bash)"

to your bashrc, or .profile (assuming go-jira binary is already in your path) will cause jira to offer tab completion behavior.

Configuration

go-jira uses a configuration hierarchy. When loading the configuration from disk it will recursively look through all parent directories in your current path looking for a .jira.d directory. If your current directory is not a child directory of your homedir, then your homedir will also be inspected for a .jira.d directory. From all of .jira.d directories discovered go-jira will load a <command>.yml file (ie for jira list it will load .jira.d/list.yml) then it will merge in any properties from the config.yml if found. The configuration properties found in a file closest to your current working directory will have precedence. Properties overridden with command line options will have final precedence.

The complicated configuration hierarchy is used because go-jira attempts to be context aware. For example, if you are working on a "foo" project and you cd into your project workspace, wouldn't it be nice if jira ls automatically knew to list only issues related to the "foo" project? Likewise when you cd to the "bar" project then jira ls should only list issues related to "bar" project. You can do this with by creating a configuration under your project workspace at ./.jira.d/config.yml that looks like:

project: foo

You will need to specify your local jira endpoint first, typically in your homedir like:

mkdir ~/.jira.d

cat <<EOM >~/.jira.d/config.yml
endpoint: https://jira.mycompany.com
EOM

Then use jira login to authenticate yourself as $USER. To change your username, use the -u CLI flag or set user: in your config.yml

Dynamic Configuration

If the .jira.d/config.yml file is executable, then go-jira will attempt to execute the file and use the stdout for configuration. You can use this to customize templates or other overrides depending on what type of operation you are running. For example if you would like to use the "table" template when ever you run jira ls, then you can create a template like this:

#!/bin/sh

echo "endpoint: https://jira.mycompany.com"
echo "editor: emacs -nw"

case $JIRA_OPERATION in
    list)
      echo "template: table";;
esac

Or if you always set the same overrides when you create an issue for your project you can do something like this:

#!/bin/sh
echo "project: GOJIRA"

case $JIRA_OPERATION in
    create)
        echo "assignee: $USER"
        echo "watchers: mothra"
        ;;
esac

Custom Commands

You can now create custom commands for jira just by editing your .jira.d/config.yml config file. These commands are effectively shell-scripts that can have documented options and arguments. The basic format is like:

custom-commands:
  - command1
  - command2

Commands

Where the individual commands are maps with these keys: * name: string [required] This is the command name, so for jira foobar you would have name: foobar * help: string This is help message displayed in the usage for the command * hidden: bool This command will be hidden from users, but still executable. Sometimes useful for constructing complex commands where one custom command might call another. * default: bool Use this for compound command groups. If you wanted to have jira foo bar and jira foo baz you would have two commands with name: foo bar and name: foo baz. Then if you wanted jira foo baz to be called by default when you type jira foo you would set default: true for that custom command. * options: list This is the list of possible option flags that the command will accept * args: list This is the list of command arguments (like the ISSUE) that the command will accept. * aliases: string list: This is a list of alternate names that the user can provide on the command line to run the same command. Typically used to shorten the command name or provide alternatives that users might expect. * script: string [required] This is the script that will be executed as the action for this command. The value will be treated as a template and substitutions for options and arguments will be made before executing.

Options

These are possible keys under the command options property: * name: string [required] Name of the option, so name: foobar will result in --foobar option. * help: string The help message displayed in usage for the option. * type: string: The type of the option, can be one of these values: BOOL, COUNTER, ENUM, FLOAT32, FLOAT64, INT8, INT16, INT32, INT64, INT, STRING, STRINGMAP, UINT8, UINT16, UINT32, UINT64 and UINT. Most of these are primitive data types an should be self-explanatory. The default type is STRING. There are some special types: * COUNTER will be an integer type that increments each time the option is used. So something like --count --count will results in {{options.count}} of 2. * ENUM type is used with the enum property. The raw type is a string and must be one of the values listed in the enum property. * STRINGMAP is a string => string map with the format of KEY=VALUE. So --override foo=bar --override bin=baz will allow for {{options.override.foo}} to be bar and {{options.override.bin}} to be baz. * short: char The single character option to be used so short: c will allow for -c. * required: bool Indicate that this option must be provided on the command line. Conflicts with the default property. * default: any Specify the default value for the option. Conflicts with the required property. * hidden: bool Hide the option from the usage help message, but otherwise works fine. Sometimes useful for developer options that user should not play with. * repeat: bool Indicate that this option can be repeated. Not applicable for COUNTER and STRINGMAP types. This will turn the option value into an array that you can iterate over. So --day Monday --day Thursday can be used like {{range options.day}}Day: {{.}}{{end}} * enum: string list Used with the type: ENUM property, it is a list of strings values that represent the set of possible values the option accepts.

Arguments

These are possible keys under the command args property: * name: string [required] Name of the option, so name: ISSUE will show in the usage as jira <command> ISSUE. This also represents the name of the argument to be used in the script template, so {{args.ISSUE}}. * help: string The help message displayed in usage for the argument. * type: string: The type of the argument, can be one of these values: BOOL, COUNTER, ENUM, FLOAT32, FLOAT64, INT8, INT16, INT32, INT64, INT, STRING, STRINGMAP, UINT8, UINT16, UINT32, UINT64 and UINT. Most of these are primitive data types an should be self-explanatory. The default type is STRING. There are some special types: * COUNTER will be an integer type that increments each the argument is provided So something like jira <command> ISSUE-12 ISSUE-23 will results in {{args.ISSUE}} of 2. * ENUM type is used with the enum property. The raw type is a string and must be one of the values listed in the enum property. * STRINGMAP is a string => string map with the format of KEY=VALUE. So jira <command> foo=bar bin=baz along with a name: OVERRIDE property will allow for {{args.OVERRIDE.foo}} to be bar and {{args.OVERRIDE.bin}} to be baz. * required: bool Indicate that this argument must be provided on the command line. Conflicts with the default property. * default: any Specify the default value for the argument. Conflicts with the required property. * repeat: bool Indicate that this argument can be repeated. Not applicable for COUNTER and STRINGMAP types. This will turn the template value into an array that you can iterate over. So jira <command> ISSUE-12 ISSUE-23 can be used like {{range args.ISSUE}}Issue: {{.}}{{end}} * enum: string list Used with the type: ENUM property, it is a list of strings values that represent the set of possible values for the argument.

Script Template

The script property is a template that would produce /bin/sh compatible syntax after the template has been processed. There are 2 key template functions {{args}} and {{options}} that return the parsed arguments and option flags as a map.

To demonstrate how you might use args and options here is a custom-test command:

custom-commands:
  - name: custom-test
    help: Testing the custom commands
    options:
      - name: abc
        short: a
        default: default
      - name: day
        type: ENUM
        enum:
          - Monday
          - Tuesday
          - Wednesday
          - Thursday
          - Friday
        required: true
    args:
      - name: ARG
        required: true
      - name: MORE
        repeat: true
    script: |
      echo COMMAND {{args.ARG}} --abc {{options.abc}} --day {{options.day}} {{range $more := args.MORE}}{{$more}} {{end}}

Then to run it:

$ jira custom-test
ERROR Invalid Usage: required flag --day not provided

$ jira custom-test --day Sunday
ERROR Invalid Usage: enum value must be one of Monday,Tuesday,Wednesday,Thursday,Friday, got 'Sunday'

$ jira custom-test --day Tuesday
ERROR Invalid Usage: required argument 'ARG' not provided

$ jira custom-test --day Tuesday arg1
COMMAND arg1 --abc default --day Tuesday

$ jira custom-test --day Tuesday arg1 more1 more2 more3
COMMAND arg1 --abc default --day Tuesday more1 more2 more3

$ jira custom-test --day Tuesday arg1 more1 more2 more3 --abc non-default
COMMAND arg1 --abc non-default --day Tuesday more1 more2 more3

$ jira custom-test --day Tuesday arg1 more1 more2 more3 -a short-non-default
COMMAND arg1 --abc short-non-default --day Tuesday more1 more2 more3

The script has access to all the environment variables that are in your current environment plus those that jira will set. jira sets environment variables for each config property it has parsed from .jira.d/config.yml or the command configs at .jira.d/<command>.yml. It might be useful to see all environment variables that jira is producing, so here is a simple custom command to list them:

custom-commands:
  - name: env
    help: print the JIRA environment variables available to custom commands
    script: |
      env | grep JIRA
 ```

You could use the environment variables automatically, so if your `.jira.d/config.yml` looks something like this:
```yaml
project: PROJECT
custom-commands:
  - name: print-project
    help: print the name of the configured project
    script: "echo $JIRA_PROJECT"

Examples

• jira mine for listing issues assigned to you

custom-commands:
  - name: mine
    help: display issues assigned to me
    script: |-
      if [ -n "$JIRA_PROJECT" ]; then
          # if `project: ...` configured just list the issues for current project
          {{jira}} list --template table --query "resolution = unresolved and assignee=currentuser() and project = $JIRA_PROJECT ORDER BY priority asc, created"
      else
          # otherwise list issues for all project
          {{jira}} list --template table --query "resolution = unresolved and assignee=currentuser() ORDER BY priority asc, created"
      fi

• jira sprint for listing issues in your current sprint ```yaml custom-commands:
• name: sprint help: display issues for active sprint script: |- if [ -n "$JIRA_PROJECT" ]; then # if project: ... configured just list the issues for current project {{jira}} list --template table --query "sprint in openSprints() and type != epic and resolution = unresolved and project=$JIRA_PROJECT ORDER BY rank asc, created" else # otherwise list issues for all project {{jira}} list --template table --query "sprint in openSprints() and type != epic and resolution = unresolved ORDER BY rank asc, created"