Integrating Stack Exchange and JIRA


We are working to get the Red Hat Mobile Application Platform (RHMAP for brevity) Open-Sourced as FeedHenry and have discussed the usual array of community support options : mailing-lists, IRC, GitHub, JIRA, etc. However, the community is already using Stack Overflow to ask questions and get help from one another.

This leads to a question though : how do we integrate Stack Overflow monitoring with our current workflows? Enter so-monitor, a simple node.js application to watch Stack Overflow for questions and track their status in a JIRA. The project creates a ticket when a question is asked using a tag we monitor and then will close the JIRA ticket when the question is marked as answered.

Setup of Development Environment

I decided to write the monitor as a Node.js application, and that I would use Visual Studio Code as my IDE. Being a Java developer I am used to many tooling features: intellisense, robust debugging, etc. Also being a Java developer I had heard that most of these things were just not as mature in the Node.js ecosystem. While I feel this is still true, VS Code and [Definitely Typed|] have closed the gap significantly. If you are interested in learning more about this setup I suggest following MS’s blog post. It was very helpful to me.

Consuming the Stack Exchange API

The Stack Exchange API is pretty standard as far as RESTful APIs go. There is a public API that with a limited quota expands more once you get an API key. The biggest difficulty I had was with their filters concept. Basically in Stack Exchange sites you can create a filter for your API calls that lives on their servers and then reference it with a stable, public ID.

I used Moveo’s Stack Exchange API wrapper to access the API and it worked rather well.

JIRA’s black magic

For as simple as Stack Overflow was, JIRA was not. However, JIRA is 100% scriptable and you can configure it to respond to nearly any requirement you may have. Putting a question into JIRA was basically four steps

  • Create the ticket
  • Formatting the question as a issue
  • Tagging my team
  • Closing the issue when the question was answered.

To wrap the JIRA REST API I used steve’s node jira library.

The trickiest part of the process was keeping the issue and the question states in sync. I used a custom field to track the question id returned by the Stack Exchange APIs, but managing the state hit an unexpected snag.

JIRA uses a transitions metaphor for changing the state of a ticket. This means there isn’t a “close issue” API call, but instead you have to upload a “transition” object to the issue endpoint that defines which transition you wish the issue to have taken. This means that you have to either a) check the state of the JIRA issue, lookup a transition, and execute that one or b) create a “Any State” -> “Close” transition in JIRA and hard code that. I chose “b”. For more information I encourage you to read JIRA’s API docs. They are really good and it is a very different pattern than Stack Exchange uses.


While the Stack Exchange and JIRA APIs were the main meat of the monitor project, there were many small “learnings” I had above and beyond that. VS Code and typings is a wonderful JavaScript experience. Using Q promises and wrapping node calls in Promises with simple one liners made my main code much easier to follow. Node.js and the JavaScript ecosystem has come phenomenally far in four years and it is finally as productive as more “Enterprisey” technologies like .Net and Java.