New Job: Jira Integration

I haven't been very active on this blog for the last few months. I've recently started a new job, and part of what I've been doing in my spare time is adding to my Emacs configuration to make some of the daily chores easier (or to remove them entirely).

If you know me, you know I'm not a fan of WebUIs, or just mouse-focused GUIs in general. Jira is no exception. Previously, I've had to deal with Jira's annoying click and drag nonsense and sort of dealt with it, but I've always wanted to be able to use it from within Emacs. Not just because that means no mouse-based WebUI, but also because it potentially means making custom automations around tickets. Enter the new job, where I'm able to make myself an API token, and therefore make use of org-jira for the first time.

You can see the config I've written around it here. This works basically exactly as expected, although I have had to do something a bit hacky to keep the API token properly stored. Storing the key on MacOS as recommended in the readme wasn't working for me, so instead I've stored it as a generic password. When launching Jira, this password is fetched into the kill ring to be pasted into the prompt if needed. This is kind of terrible, but it does work well enough.

(when (equal system-type 'darwin)
  (kill-new
   (string-trim-right (shell-command-to-string (concat "security find-generic-password -a \""
                                                     jiralib-user "\" -s \"jira\" -w")))))

You should be careful when storing the API token with add-generic-password, make sure you write it in the command with -w "<token>" and don't copy it into the prompt. When I was copying it into the prompt, the token was getting cut off, which was a pain to debug because Jira cloud doesn't have 401 errors for this sort of thing on the JQL search. You may also notice string-trim-right here: the output of shell-command-to-string includes the trailing newline, which will mess up the auth.

I'm also using my org projects space as the Jira workspace locally, which means I can use all the same organisation helpers as I do with my personal project files.

In terms of automations, org-jira already provides useful enough keybinds for progressing tickets, leaving comments, etc., and at the moment I don't feel like I need to improve there. However, since this Jira instance is integrated with Bitbucket, it's convention to use the ticket number when opening a new branch for work related to that ticket. That way Jira can show things like PR status, etc.

Because each Jira board or project only has one repository associated, I'm assuming that there will be only one directory for that project work, and that can be a customizable variable.

(defcustom jira-key-directory-alist '()
  "Directories associated with a particular project --- git repositories.
For example, (\"CBM\" . \"~/build/etc\") will use ~/build/etc for ticket-specific commands in the CBM project."
  :type 'alist
  :group 'jira
  :group 'theurgy)

Then this simple function fetches the Jira issue ID under the cursor, opens a magit status buffer in the appropriate directory, and starts branch creation.

(defun jira-branch-ticket ()
  "Create a branch from the current ticket, in the repository specified by `jira-key-directory-alist'."
  (interactive)
  (let* ((issue-key (progn
                    (org-jira-copy-current-issue-key)
                    (substring-no-properties (car kill-ring))))
       (project-code (car (split-string
                           issue-key
                           "-")))
       (project-dir (cdr (assoc project-code jira-key-directory-alist))))
    (magit-status project-dir)
    (kill-new issue-key)
    (call-interactively #'magit-branch-create)))

I'm not pre-selecting main/master as the origin here because it's possible that I may want to branch off something else. Nor am I pre-populating the branch name, just killing the ticket number, in case I need multiple branches per ticket.

Ideally, I would like to pre-populate the magit branch prompt with some editable default values, but I'm not actually sure how to do that, so this will do for now.

The next blog will look at the AWS CLI customisations I've built up, so stay tuned.