cedrata/jira-helper

Tool to have jira access from cli and manipulate cards and generate spring review reports

Jira Helper CLI

This project is born to help building automation scripts with jira. This CLI is a 1:1 integration with the Jira REST API v2 to help you execute repetitive tasks via scripts or simply change your card status, assignee and more to come.

Because a tool to query JSON payloads is already available (jq) this cli is intended to act as a simple HTTP client so it's flexible enogh and can help building scripts to automate you work with jira if needed.

Installing

$ go install github.com/cedrata/jira-helper@latest

Featrues

Because this implementation aims to be 1:1 implementation of the JIRA REST API v2 a command will exist for each section. Each command will have it's own subcommand, each subcommand will be linked to a URL and an HTTP method to keep the integration simple.

To follow you can find the implemented endpoints for each jira group:

• Issues

  • Assign Issue ✅
  • Get Transitions ✅
  • Transition Issue ✅

• Issue search

  • Search for Issue GET ❌ using directly the POST version

  • Search for Issue POST ✅

• Myself

  • Get Current User ✅

Configuration

Before using the cli create an empty file ~/.jira-helper.toml, execute then the cli with the following command for more informations on how to populate the configuraion file

$ jira-helper configure set

jira-helper's Issues

add license and make it open source

generalize http call functions (Get & Post)

When calling the get and post method we want to have a more generic approach to execute the http call. An http.Request object should be returned.

hide `completion` command

myself command implementation

return information about yourself given the provided token

add description for command acting as groups

commands like issues or myself act as group and they do not do nothing on their own, it could be nice to add the jira group description as documentation for commands to show when invoking help

e.g. https://developer.atlassian.com/cloud/jira/platform/rest/v2/api-group-issues/#api-group-issues has a top comment which is the following one:

This resource represents Jira issues. Use it to:
create or edit issues, individually or in bulk.
retrieve metadata about the options for creating or editing issues.
delete an issue.
assign a user to an issue.
get issue changelogs.
send notifications about an issue.
get details of the transitions available for an issue.
transition an issue.
Archive issues.
Unarchive issues.
Export archived issues.

It would be nice to add it to the Long attribute inside of and add a shorter version for the Short attribute for the IssuesCmd in cmd/issues/issues.go

file title fix

If --output foo.md is provided the Title of the md is equal to foo.md, I want to change it in order to make it only foo, so removing the file extension

I'd suggest to change this to make it work as follows, the file is by default a Markdown, provide only the name of the file without extension and add it inside the CLI. Also add textual feedback when creating the file with the absolute path where the file has been created.

issue status update

Add a new sub-command in order to allow status update of a given issue

panic when no issues available in search

When no issues matches the search criteria and the issues array is empty returns an out of bounds error

%!v(PANIC=String method: runtime error: slice bounds out of range [2:0])

add configuration command

provide a a new sub command to configure the CLI to provide the following functionalities:

• add a profile
• update a profile values
• delete a profile

add exit status status codes

In some situations it's better to have a custom return status code:

• wrong command syntax
• missing auth (when required, not all endpoints require auth and some can be anonymous http requests (to double check))
• something else...

add return status

In some cases a return status different from 0 (zero) can be useful. Try to understand to understand how to manage the status (sync.once with a global object maybe?)

store summary to file in issues sub command

When issues are returned from the issues command add a flag to choose to store the result on a file with a template

assign issue to a user command

convert configuration to INI file format

configuration file must become INI format
add configure command
add --profile flag to select the profile to use for the commands, the flag must be global and if no default profile is available it should be required

assign issue to user

Add issue sub command to assign a issue to a user given the user id or username TBD

add logger

Add logging to the application in a given path, /tmp should be a good option.
Use environment variable (viper prefix env var, take a look at it) to decide the level.
Make sure the environment variable is embedded in the package, must not be visible to the end user, only in developing mode it's visible