Update Tickets from the Command Line

In the April 2017 issue, I wrote about how to use ticketing systems as a sysadmin to organize your tasks better. In that article, I made a brief reference to the fact that I've integrated some of my own scripts with my ticketing system, so here I'm going to talk about a basic bash script I whipped up in a few minutes that can add a comment to a Jira ticket. Although my examples specifically are for use with the Jira ticketing system, you can adapt the same kind of idea to any ticketing system that allows you to interact with it via a web-based API.

One reason many sysadmins dislike ticketing systems is due to the fact that updating and maintaining tickets requires a shift in focus and a break from their regular workflow. To me, tickets are a great way to build an audit trail to show that you've completed a task, and one of the best ways to demonstrate that a task is complete is to paste in the proof of your work into comments in a ticket. Unfortunately, all of that copying and pasting can slow things down and discourages sysadmins from updating their tickets with command output.

My solution to the pain of keeping tickets updated with command output is to create a script I can pipe output to and have it appear as a comment in the ticket I specify. My tasks often generate output into log files, and it's nice just to pipe those log files into a script and have them show up in a ticket. I generally use my create_jira_comment script like this:


$ somecommand | create_jira_ticket -t TICKETNAME

My command may be as simple as an echo command or something much more sophisticated. In some cases, I've wanted to wrap the output inside a code block within the ticket comment and pass along a header to describe what the code block is, so I've added -C and -H options, respectively:


$ somecommand | create_jira_ticket -t TICKETNAME -C -H "Here
 ↪is the output from somecommand"

This makes it really easy for an administrator to update a ticket with command output without messing with copying and pasting pages of output into a ticket. The output shows up formatted properly, and when it's in a code block, the ticket shows it in such a way that someone can scroll through it to read the whole thing, but it doesn't fill up a whole page.

Before I get into the Jira-specific bits, let me go over the more generic parts of the script. First, there's the opening section of the script where I define a few variables, set some defaults and source a settings file so I don't have to have the password be hard-coded into this script:


#!/bin/bash

JIRA_HOST="somehost.example.com"
JIRA_USER="someuser"
JIRA_PASS="somepass"
# Set the user and password in a settings file
# instead of in the script
. /etc/default/jira_settings

OUTFILE="/tmp/create_jira_comment-$(date +%Y%m%d-%H%M%S)"

Next, I add a typical usage function (like all good script writers should) to output if someone doesn't use the right syntax with my script:


# Show usage information
usage() {
  cat >&2 <<EOF
Usage:
  $0 [-h | -t TICKET <-f FILENAME> <-H "Header text">
 ↪<-F "Footer text"> <-C>]

This script adds a comment to a Jira ticket based on command-line
arguments.

OPTIONS:
  -h              Show usage information (this message).
  -t TICKET       The Jira ticket name (ie SA-101)
  -f FILENAME     A file containing content to past in the Jira
comment (or - to read from pipe)
  -H HEADER_TEXT  Text to put at the beginning of the comment
  -F FOOTER_TEXT  Text to put at the end of the comment
  -C              Wrap comment in a {code} tags
EOF
}

As you can see in the usage output, the script can accept a number of command-line arguments. The one required option is -t, which specifies the name of the ticket to which you want to add the comment. All of the other options are optional.

As I started using this script, I realized that I often was piping command output into this ticket, and the default formatting inside a Jira comment just made it a huge wall of text. The -C option will wrap all of the text into a tag so that it shows up like code and is easier to read. Once I started wrapping output inside proper formatting, I realized sometimes I wanted to add text above or below the code block that explained what the code block was. I added the -H and -F arguments at that point, which let me specify text to use as a header or footer around the code block.

______________________

Kyle Rankin is senior security and infrastructure architect, the author of many books including Linux Hardening in Hostile Networks, DevOps Troubleshooting and The Official Ubuntu Server Book, and a columnist for Linux Journal. Follow him @kylerankin