Bitrise Tests Made Easier: Update JIRA Issues with Build Number and Forget About Delays in QA Testing

When you trigger Bitrise build with changes and forget to tell QA specialists some essential information, there are two likely scenarios. You waste time waiting for the update from the tester, only you don’t know it’s never coming. Or you get so many questions about builds that you can’t keep up. Sounds familiar? If so, let us tell you about the JIRA issue update that keeps workflow in order.

About Bitrise

A quick explanation for those unfamiliar with Bitrise. It’s a CI/CD (Continuous Integration and Delivery) system for building and testing automation, dedicated to mobile apps development.

Engineers create production software and run unit tests with this platform, while QA specialists use it to conduct manual tests. When it comes to deployment in App Store and Google Play, Bitrise also becomes handy. It’s useful even when you want to integrate your app with a testing platform, such as TestFlight.

Using Bitrise is simple. First, a software developer configures it and specifies what needs to be done and in what order. Then the system tracks down the changes in a version control system (e.g., Git). When the changes are being pushed, the process described by the developer begins.

If everything is stored in one place, what can go wrong?

A lot of things can get forgotten along the way. Developers realize that if they won’t indicate which build needs to be tested, nobody else will. But such information often escapes their memory anyway. As a result, QA specialists can’t figure out which build contains features that have to be tested. It’s even worse when you maintain or develop multiple versions of the project simultaneously. This can significantly slow down the entire development process.

Time gap between the submission of the changes and CI build/deployment is no help either. It often lasts more than 1 hour. This means that sometimes testers can spend a lot of time trying to evaluate changes that haven’t been deployed yet, even though they figure as Ready to Test.

And last but not least – developers can simply forget to move tasks into the next column on the JIRA board. For example, from Ready for Code Review to Ready to Test. Delay in testing is a natural consequence.

Automation is the answer

If to err is human, then automation is what we need. Precisely, a custom Bitrise step that automatically annotates JIRA tickets with build numbers and moves them into the Ready to Test column. With such a solution you don’t need to worry that you’ll forget to tell QA specialists everything they need to know. The system will do it for you.

Even though Bitrise offers over 300 steps and integrations, we couldn’t find anything that would optimize developer-tester cooperation in a way we wanted. So, we created a new step, anyone can easily use in their projects.

How to add our custom step to JIRA?

First, the step needs to know the issues associated with your build, so it examines Git history of the merge that triggers the current build. Each merge request can have multiple tasks related to it. Sometimes these tasks are so small or very tightly coupled, that it’s easier to combine their changes in one single merge request.

What happens next? Step extracts all the messages of commits involved from the merge commit. Then it looks for issue keys using a predefined format. For example, [BETI-1234]. As you might have already noticed, there’s no extra work that needs to be done at this point. Most developers use Git and many of them place issue keys in commit messages.

How does the JIRA issue update work?

You may wonder how do we pick the commits associated with a given merge commit. There’s a cool trick for that. To list these commit objects, we use:

git rev-list

This command lists all the commits that are reachable from a given commit (by following parent links). It excludes those that are reachable from the ones that begin with the ^ symbol.

Commit B is reachable from commit A if it can be found by following parent links starting from commit A. As the man documentation describes it:

“You can think of this as a set operation. Commits reachable from any of the commits given on the command line form a set, and then commits reachable from any of the ones given with ^ in front are subtracted from that set.”

For better understanding, take a look at the example below. Let’s say this is your current commit graph:

And here you can see the reachability sets from merge commit and its parent:

To retrieve a list of commits that were “merged-in”, simply type:

git rev-list <merge-hash> ^<merge-parent-1-hash>

This will output a set of commits reachable from merge commit, excluding those reachable from Parent 1. And this is what you are looking for! In the background, step uses git2go package, a wrapper around libgit2 library, to obtain selected commits from Go.

What happens when a build fails?

Good news, you can keep a ticket history from failed builds. The step uses Bitrise API to gather information about the commits from all aborted or failed builds preceding the current one. Every commit from each build is undergoing the same procedure of task key extraction as described above.

Updating changes in JIRA

With the proper keys, the step moves to JIRA and updates the Made in Build field with JIRA API. It’s a custom field with a unique ID. If you want the build to be available immediately, the step will move it to the Ready to Test column or equivalent.

Image: Step inputs from step.yml.

Now, all you need to do is to search for “Update JIRA issues with build number” in Bitrise step library and add it to your workflow. It should be placed right below the steps responsible for building, testing, and deployment.

Configuration

Congratulations! You managed to add a new step. Now let’s move on to the next part which is configuration. Basically, you just need to fill out some empty fields, so the step could work. With our cheat sheet, it should be quick and easy.

1. App version (e.g., 1.0.0) – every version of the project has a special number. If you develop an iOS project, you can extract the version number from Info.plist of the main target. It’s called CFBundleShortVersionString. Alternatively, you may use a custom step that can do it for you: bitrise-step-xcode-build-version.
2. JIRA host (e.g., https://example.atlassian.net) – paste your JIRA instance URL here.
3. JIRA custom field ID (integer) – a number of the build should figure as the ID of the field. You can read how to find it here. And if you don’t have this number yet, check out this guide that explains how to create it.

Image: Step configuration in a workflow editor.

This step uses HTTP basic authentication mechanism for communication via JIRA API, so you need to pass some information concerning your JIRA account:
4. JIRA username – user (or bot) login.
5. JIRA access token – user (or bot) password or API token (you can generate it here).

Finally, you just have to type the following data:
6. Issue pattern – a regular expression for matching issue keys in commit messages. For example, ([A-Z]{1,10}-[0-9]+).
7. Bitrise access token – you can find your API token here.

And that’s all. Your step is ready to use!

Get a source code and try it out

This JIRA issue update build step proves useful in our projects and we encourage you to give it a go. If we managed to keep you interested, visit our Github repo where you can find the source code. And don’t forget to let us know how (if at all) our solution has changed the way you develop your apps.