The CLI looks for commands (like 'labels') in the first two positional args. This
is how commands like 'BLOCKER blocks ISSUE' work.
As per @coryb's comments in #21 - this allows us to support set/add/remove in a
consistent way for other types: components for example.
This commit rearranges the command to be as follows:
jira (set/add/remove) labels ISSUE LABELS...
The options to CmdLabels have been reordered accordingly.
GetTemplate and RunTemplate allow external users to access the template system,
and in particular allow them to provide their own Buffer to write the output to.
I've implemented exposed versions calling the private functions, rather than breaking
the internal API. If this isn't a concern, we should remove getTemplate and runTemplate
in a future commit.
This adds 'labels' command, which allows for the setting, addition and removal
of labels on an issue.
'set' action resets the issue labels to the list provided.
'add' action adds the supplied labels to the issue
'remove' action removes the supplied labels from the issue
The API already gracefully handles duplication, removal of non-existant labels, and the
supplying of an empty list of labels (which is useful in the case of 'set')
Eg
jira labels TEST-123 add label1 label2 label3
jira labels TEST-123 remove label1 label2
jira labels TEST-123 set label1 label2 label3
jira labels TEST-123 set # clears any labels on the issue
jira labels TEST-123 add # no-op
jira labels TEST-123 remove # no-op
This mirrors the functionality of the API.
Wrapper around time.Format, so that we can make concise lists without
the whole JIRA ISO timestamp, eg:
{{ dateFormat "2006-01-02T15:04" .fields.updated }}
Mike Pountney