JIRA (2)


Create a Jenkins Support Channel

When creating a large Jenkins setup, it is often a good idea to consider have a team governing, documenting, and managing the tools a little. These teams almost always require a clear support channel, otherwise everything becomes tribal knowledge, and that is not going to scale well.

Signature of a large Jenkins setup means it has

  • Multiple workers with varying operating systems
  • Multiple integrations to systems for static analysis, artifact repositories and code-review platform triggers such as pull-requests and patch sets
  • Support for an advanced authorization role strategy or single sign on from other platforms
  • Support for multiple build-systems such as MSBuild, Maven, Gradle, Ant, Make and so forth

When a large number of teams with a similarly large number of software development stacks starts to use it. Then it becomes relevant with being able to support the systems by providing a clear and obvious support-channel.

A common channel for issue-management is JIRA, which ironically started as an ITSM-platform. And another common place to store documentation is whatever source-control platform you have available, such as GitHub Pages, Wikimedia or Confluence.

So i would like to show how to include custom-integration in the Jenkins header directly into those tools.

Starting point

Configure JIRA Issue Collector

  • In JIRA, create a target project
  • Go to settings for the project
  • Go to Issue Collectors
  • Click + Add issue collector
  • Configure it as you may wish, make sure your select custom trigger-style
  • Submit the collector
  • Extract the link in the markup JIRA wants you to embed.

The collector-link will look something like this

https://YOUR-PROJECT.atlassian.net/s/aef99a9d9e96520927s6987-T/-p6br4e/b/5/a44af77267a987a660377e5c46e0fb64/_/download/batch/com.atlassian.jira.collector.plugin.jira-issue-collector-plugin:issuecollector/com.atlassian.jira.collector.plugin.jira-issue-collector-plugin:issuecollector.js?locale=en-US&collectorId=909eeccc

Configure Jenkins to embed collector and run some JavaScript

  • Go to Manage Jenkins
  • Go to System Configuration
  • Fill in Issue Collector URL: with the collector-link from the previous step.
  • Fill in the Theme Javascript part with an accessable location where you save this JavaScript. SonaType Nexus rawFiles-store works nicely for this purpose.
  • Get the following html
  • Put it into the system message
  • preview html should now put two buttons in the header
  • If you want you can include custom styling to the buttons in the simple theme css box. I used the following to achieve the looks below.

And voila! You have opened a support channel directly from your Jenkins header into your documentation and added support for adding JIRA issues directly into your JIRA project! Clicking the Report an issue! will open a JIRA Modal and allow your users to fill in a support issue as their own JIRA users.

Issue collectors can be customized to pre-populate fields quite extensively, read more on Atlassians own documentation.

#




Have GitHub or BitBucket drive JIRA Workflows

At work we have all infrastructure you can imagine. Today i’m going to talk about three pieces of them.

  • Atlassian JIRA Cloud
  • GitHub Enterprise
  • Atlassian BitBucket Cloud

I was approached by a team that requested that we look into having BitBucket (In their case) drive the workflows of JIRA. If you are unfamiliar with JIRA it is a huge issue-tracker that you can customize beyond recognition. It is powerful, but is as a consequence quite complex. In this case the workflow consists of five states. TODO, IN PROGRESS, REVIEW, TEST and DONE.

The requirement was as follows:

TODO => IN PROGRESS

  • Given a JIRA issue is in TODO
  • When a branch is created, From JIRA or directly in GIT, that contains a JIRA issue token
  • Then the JIRA issue is moved from TODO to IN PROGRESS

IN PROGRESS => REVIEW

  • Given a JIRA issue is in IN PROGRESS
  • When a Pull Request is created on BitBucket or GitHub that contains a JIRA issue token
  • Then the JIRA issue is moved from IN PROGRESS to REVIEW

IN REVIEW => IN PROGRESS

  • Given a JIRA issue is in in REVIEW
  • When a Pull Request is declined on BitBucket or GitHub that contains a JIRA issue token
  • Then the JIRA issue is moved from REVIEW to IN PROGRESS

IN REVIEW => TEST

  • Given a JIRA issue is in in REVIEW
  • When a Pull Request is approved on BitBucket or GitHub that contains a JIRA issue token
  • Then the JIRA issue is moved from REVIEW to DONE
  • And the issue assignment is set to unassigned

At first i was thinking that’s rather excessive to have such triggers. What i didn’t see is that this is exactly how the team already worked, in BitBucket. JIRA was just additional overhead to them. Sure, they created the branch from their issue. But after that they didn’t seem to want to bother with JIRA more than to move the cards just before their SCRUM standups. So it made sense all the sense in the world to add it. And it gave me a reason to have a closer look at our JIRA integration between GitHub Enterprise since it didn’t seem to parse any issues from it.

So here’s how i made it work, in case someone else out there has a similar use case.

Steps to achieve it

  1. Become a JIRA admin, because modifying workflows require administrator permissions (Luckily i have a close colleague who is the JIRA admin)
  2. Setup Integration to BitBucket and GitHub enterprise from your JIRA
  3. Go to JIRA, Select Settings
  4. Select Projects
  5. Select the name of the project you want to add source triggers for
  6. Select Workflows
  7. Edit the workflow that is in use as list or diagram, diagram format is easiest
  8. Drag transition lines from each workflow state according to the requirements and name them accordingly. I get five of them, one for each requirement. We should end up with something resembling the image below.
  9. Select a transition, a pop-up should appear describing triggers, conditions and post-functions of the transition. Click triggers (0) to edit.
  10. Select the relevant source trigger for that transition
  11. Repeat steps 9 to 11 until all transitions have a source trigger.
  12. For the last requirement REVIEW => TEST we should add a post function that modifies the JIRA-issues field assigned to unassigned, it is added in the same way as source triggers but instead select post functions.
  13. Publish the workflow in order for the triggers to become activated

And you are all done!

You can check whether the triggers work by creating branches, commits and pull-requests that contain the jira issue and watch the activity tab on the JIRA issue to see that the source trigger actived!