Atlassian DevOps Event Impressions

Today I attended an event, organized by ManageWare, titled “Bridging the Gap Between Dev & Ops”, focusing on Atlassian’s tools suite. JIRA is a very popular tool here in Israel, so the main theme of the event was to showcase how productivity and collaboration can be increased when integrating JIRA with other tools.

There were quite a few presentation (detailed at the end of the post) on various DevOps-oriented subjects, such as CI/CD pipelines, monitoring and reporting. Nothing revolutionary, but it was nice to see how a good integration between various tools (not just Atlassian ones…) can really make things flow faster and help focus on generating value for the business.

I only wish some of the sessions were longer, there was a lot more to see; unfortunately, due to time constraints, most presenters had to rush through their materials.

And finally we had some fresh Pizza and ice-cold beer ūüôā

The presentations:

Continue reading

Advertisements

JIRA SOAP API is being deprecated

In the past I mentioned that I¬†use the JIRA::Client Perl module quite frequently. This module is based on JIRA’s SOAP API.

Recently it came to my attention that Atlassian deprecated their SOAP API in JIRA 6.0 and will be removing it altogether in JIRA 7.0 (see here). Anyone who is still using the SOAP API is encouraged to migrate to the REST API.

Specifically for the JIRA::Client module, an alternate module, JIRA::REST, is now available, providing similar functionality.

So if you’re using any SOAP-based access to JIRA, it’s time to move on…

JIRA Behaviour plugin: handling sub-tasks

I was asked¬†to show a warning message when editing an issue custom field, in case there are subtasks to the issue. Since I¬†already had a validator script which was used for a similar purpose, I figured I’ll just copy the code into the relevant behavior entry and it would work. Clean and simple.

Boy, was I wrong.

As you may know, you need the issue object in order to work with its¬†subtasks. In¬†all Script Runner environments (validators/post functions/etc.) you have the readily available ‘issue’ variable. However it does not exist in the Behavior plugin environment. Since both were written by the same developer, I assumed it must be¬†there somewhere, so tried all sorts of stuff¬†to try and¬†find it, but to¬†no avail (why doesn’t it exist in the FieldBehaviours class?).

“Fine”, I said, “let’s get the issue key and obtain the object from it”. Not very elegant, but simple enough.

Wrong again. getFieldById(“issuekey”) returns null. I honestly have no idea why. Again I had to spend a lot of time¬†searching for a reason, then gave up and started looking for a way to work around it. Eventually I¬†figured out the correct way to get the issue object.

 

import com.atlassian.jira.ComponentManager
FormField field = getFieldByName("MyCustomField")
def issueid = getFieldById("id").value
def issue = ComponentManager.getInstance().getIssueManager().getIssueObject(Long.parseLong(issueid));
Collection subTasks = issue.getSubTaskObjects()
if (!subTasks.empty) {
 field.setHelpText("<div class=\"warningBox\">Attention: the issue has subtasks.</div>")
}
else {
 field.setHelpText("")
}

 

Getting a JIRA issue’s priority using Perl

JIRA::Client is a great and useful module. Too bad some of its usage is so cryptic!

For example – suppose you want to print an issue’s priority field. if you simply use $issue->{priority} you will get the priority id, not the display name which everyone is used too.
So, how to get the display name? documentation is very vague on this subject. Google doesn’t help much here.

After a lot of trial & error I figured out a way.

Continue reading

Adding Clickable UNC paths to JIRA

I was tasked with the mission to find a way to add a UNC link to a certain shared document, in a way that every user will be able to access it.

The easiest way I found, so far, is to add a default, read-only field to each issue, so whenever creating or working on an issue, the link is available.

Yes, it’s an overkill, but other options such as adding it to the menu bar seem to require too much research and development (and perhaps being affected by the next JIRA update).

Turns out adding a clickable UNC field is a bit tricky… since there is no such field type (UNC link), and writing UNC paths in text fields doesn’t make them clickable, i figured out the following eay:

  • Add a URL field
  • Set the default value to the document path, for example: file://servername/folder/subfolder/filename.doc
  • Make it read-only using the behaviors plug-in.
  • Use a bulk action to update the field for the relevant issues (since setting a default only affects newly created issues).

Simple, effective, and future proof (and yes, database space wasting… but it’s a price I’m happy to pay).

 

UPDATE: It works fine in IE 11, but¬†doesn’t work in recent Chrome and FireFox versions due to their default security settings. See this KB article for more information.

Migrating to JIRA – Technical

When migrating from ClearQuest to JIRA, there are some several technical pitfalls which one may encounter. In this post I will detail the main issues which I tackled during the migration process.

The general strategy is to use as much of the built-in JIRA fields as possible, since many abilities and plug-ins uses them by default (such as JIRA Agile). It required effort, but it certainly paid off.

Let’s discuss the details, then:

Continue reading