High-level CLI for JIRA and Trello
- From source:
pip install -r requirements.txt
pip install .
- From PyPi:
pip install jirate
- In a locally-built container:
make
./jirate-c [args]
Configuration is a JSON document stored as ~/.jirate.json
- an example can be found in the contrib/jirate.json
file in this repository.
url
(Required) - URL to your JIRA instancetoken
(Required) - A valid personal access token for your accountdefault_project
(Required) - Default project to use when interacting with JIRAeausm
(Optional) - Set tofalse
to disable EZ Agile Planning votinghere_there_be_dragons
(Optional) - Set totrue
if you intend to use custom code to render JIRA custom field datadefault_fields
(Optional) - When displaying lists of issues, display these fields (and optional field widths) by defaultno_format
(Optional) - Set totrue
if you would prefer Jirate not attempt to render JIRA comments and descriptions as markdown (JIRA text isn't markdown, so the markdown processor often gets this wrong)searches
(Optional) - List of JQL searches and their names. The special search nameddefault
is applied when one runsjirate search
.custom_reorder
(Optional) - Defaults to true. If set to false, custom field definitions will not reorder base JIRA fields when listing issues.custom_fields
(Optional) - One of:- Custom field rendering definitions in the format of the jira
/field
data with some additional fields (see below) - A filename pointing to custom field definitions, or
- Custom field rendering definitions in the format of the jira
proxies
(Optional) - HTTP and/or HTTPS proxies to usecache_expire
(Optional) - Number of seconds to cache certain JIRA configuration data locally (default:300
;0
means no expiration)cache_file
(Optional) - Where to store cached JIRA configuration data (default:~/.jirate.cache
)fancy_output
(Optional) - If set to true, render some things as links and enable per-line visual separation for tablescolor_shift
(Optional) - Tune color separation when usingfancy_output
. (0..128; default=16)
Each field in custom_fields
is a dictionary. Jirate only cares about a few fields when defining custom rendering; most fields it automatically discerns by asking the server for the /field
data:
id
(Required) - the JIRA custom field name (customfield_xxxxx
).name
(Required) - Generally this should come from your JIRA instance, but you can rename it to whatever you like if you want.display
(Optional) - false (to not display this field) or one of several built in renderers:string, any, number, value, name, version, user, value_list, email_list, name_list, date, datetime
disabled
(Optional) - If set totrue
, do not allow rendering of this field, even if requestedverbose
(Optional) - If set totrue
, only display this field when someone requests verbose output or requests this field explicitlycode
(Optional) - whenhere_there_be_dragons
is set to true, insert a snippet of Python code to render your data. The field is passed to your one-line of code asfield
; all fields in the issue are passed in asfields
. You'll need to know the custom field ID of any field you are trying to reference.code
can also be something like:#~/filename.py:function_name
. If defined in this way,~/filename.py
should containdef function_name(field, fields)
in it.field
is the raw value of the current field being processed, andfields
is the JSON data for all fields in the issue.
- Trello support is somewhat unmaintained as the maintainers do not have access to a commercial Trello instance any longer. Taking patches.
- Whenever operating on your default project, you do not need to include it in operations. In the below examples, if your default project was
MYISSUE
, you could omit it when calling operations onMYISSUE-123
and simply provide123
- Project keys are case insensitive from the CLI; they are automatically translated to upper-case.
- cat (print) a task:
jirate cat MYISSUE-123
jirate cat -v MYISSUE-123
jirate -p myissue cat 123
- View an issue in your browser (xdg-open):
jirate view MYISSUE-123
jirate -p myissue view 123
jirate view 123
- Listing issue types available
jirate lt
jirate -p MYPROJECT lt
- Listing issue fields, whether they are required, and, if applicable, allowed values for a specific issue type
jirate create -t Bug
jriate -p MYPROJECT create -t Epic
- Create new Task. This spawns an editor. First line is your summary, the third lines and subsequent become the description (think: git commit message):
jirate new
- Create a subtask for an issue (spawns editor):
jirate subtask MYISSUE-123
- Create new specified issue type with a summary (but no description):
jirate new -t Bug This is my Bug Summary
jirate new -t Bug "This is my Bug Summary"
jirate -p myissue new -t Task "This is my Task Summary"
- Creating an issue with custom fields:
jirate create -t Story story_points 3 summary "This is my summary" description "This is my description" assignee my-user-id
- List open issues in the default project assigned to you
jirate ls
- List open, unassigned issues in the default project assigned to you
jirate ls -U
- List open issues assigned to
other-user
in the default project:jirate ls -u other-user
- Search for all unresolved issues assigned to you (unless you overrode the search named
default
in your configuration file):jirate search
- Execute the search named
foo
defined in yoursearches
list in~/.jirate.json
:jirate search -n foo
- Search for all issues assigned to you and display the a table with key (always displayed on left), status, priority, and summary (with width limited to 20 characters):
jirate search --fields status,priority,summary:20
- Execute a raw search and display just the key and priority:
jirate search -r "field1 is not EMPTY" --fields priority
- Assign an issue
jirate assign MYISSUE-123 me
- assign to yourselfjirate assign MYISSUE-123 other-user
- assign toother-user
- Unassign an issue
jirate unassign MYISSUE-123
- Editing the summary or description of an issue (spawns editor):
jirate edit MYISSUE-123
- Comment on an issue (spawns editor):
jirate comment MYISSUE-123
- Edit a comment on an issue (see cat):
jirate comment 123 -e 12345667
- Make that comment private to the Employee group (case/space sensitive; quote if needed):
jirate comment 123 -e 12345667 -g Employee
- Make that comment public:
jirate comment 123 -e 12345667 -g all
- Move several issues to closed and set resolution to "Won't Do":
jirate mv -r "won't do" MYISSUE-123 OTHERPROJECT-234 closed
jirate close -r "won't do" MYISSUE-123 OTHERPROJECT-234
- Move several issues to
In Progress
and assign them to yourself:jirate mv -m ISSUE-1 ISSUE-2 ISSUE-3 in_progress
- Move several issues to
In Progress
and assign them toother-user
:jirate mv -u other-user ISSUE-1 ISSUE-2 ISSUE-3 in_progress
- List issues assigned to you in your default project:
jirate ls
- List the fields for an issue and display any values which are allowed to be updated (and, if applicable, allowed values):
jirate fields MYISSUE-123
- Updating the value of most fields (note: does not support the Any type schema):
jirate field 123 set severity critical
jirate field 123 set customfield_123455934 critical
jirate field 123 set priority minor
- Setting a list field to a set of values:
jirate field 123 set contributors user1,user2,user3
- Add (or remove) several Jira usernames to (or from) the Contributors field:
jirate field MYISSUE-123 add|remove contributors user1,user2
- List components:
jirate components
jirate components -q
jirate -p OTHERPROJECT components
- Search component names and descriptions for a regex:
jirate components -s kernel
- Create a link between two issues:
jirate link PROJ-123 depends on PROJTWO-111
- Clear all links between two issues:
jirate unlink PROJ-123 PROJTWO-111
- Attach external link to an issue:
jirate attach PROJ-123 http://www.github.com Github Home
Jirate has powerful templating - templates are a combination of Jinja2 and YAML. Note that typical syntax differs from Jinja2 since double-braces are used by Jira, we use {@
and @}
instead.
- Generate a template from an existing issue:
jirate generate-template MYISSUE-123 > my-template.yaml
- File a new issue from a template:
jirate template my-template.yaml version 1.2
Because Jirate resolves field IDs to human-readable values, it's possible to use the human-readable field names in your templates. There are some strange exceptions, but most custom fields are supported as long as your project's creation metadata supports the field.
There are two typical methods of setting default values.
{% set var=var or "1.0 %}
{@var|default('1.0')@}
Jirate ignores variables in templates which start with underscores. This allows you to use Jinja2 code to slice up existing variables or to create derived variable values from user input. The first usage of a variable in a template - even in a YAML comment - is what tells Jirate to require the variable from the user. Here's an example of creating a _version_next
by slicing up the version
value given to us by a user:
# {@version@} - version to stand up
{% set _version_info = version.split('.') %}
{% set _ = _version_info.append(((_version_info.pop()|int) + 1)|string) %}
{% set _version_next = _version_info|join('.') %}`
Now {@_version_next@}
can be used within fields inside your template.
This is useful for when a user needs to create a set of known tasks, but does not have the full context for what is entailed yet. They might generate stub 30 issues, then generate a template from the first one and apply it to the other 29.
jirate template --apply MYISSUE-123 mytemplate.yaml version 1.0
- Call an API
jirate call-api /field