BitBucket (2)


Sonar Comments on BitBucket Pull-Requests

At work we have a scramble to use static code analyzers to improve the quality of code in general. Both from a security perspective and from a standardization perspective. I have worked with Sonar before, but it has almost always been in the background, alone and forgotten by everyone who are pushing features. Now those who know me are aware that i prefer early feedback, preferably pre-merge. I like to think of the Patch, Pull or Merge request as the real guard against flinchy developers like myself who don’t have time to run the tests, or check sonar for issues that should be fixed while i’m covering that particular code. This article is about resolving that and getting sonar comments directly on pull-requests.

Requirement

  • TeamCity as a build server
  • C# classic as software platform
  • MSBuild as a build system
  • BitBucket cloud for a source repository .

High level design

This is what it looks like from a high level. A Pull-Request in BitBucket triggers a TeamCity job that, in turn, runs the same pull-request builder build-process as would be done with a regular pre-merge job but with a sonar-analysis in preview-mode and a specific sonar-plugin that is able to post comments.

Prerequisites

Things you should probably do before delving in to all the configuration.

BitBucket

  • A specific user that can be named Sonar-Reviewer and added to your team

TeamCity

Make sure you build the pull-request trigger from master branch if the latest release is still pullrequest-20172603195632 since it needs the fix in this PullRequest by yours truly to be able to post the pull-request id to sonar. mvn package with maven should create the zip you need)

SonarQube

Configuration

There aren’t that many things to setup for this to work actually.

Configuration in BitBucket

Configuration in Sonar

  • If analysis is protected then create a system user for TeamCity to login to sonar

Configure TeamCity

  • Set the JAVA_HOME variable to where your JRE 8 is for each agent
  • Make sure any proxies the agent should use to post to api.bitbucket.org is also specified in the SONAR_SCANNER_OPTS environment variable, either as agent property or as build parameter. In my case i had to se env.SONAR_SCANNER_OPTS=-Dhttp.proxyHost=myproxy.tld -Dhttp.proxyPort=1234 in the AGENT_HOME/conf/buildAgent.properties.
  • Configure a pull-request trigger to look like this
  • Make sure your VCS root has the following branch specification: +:refs/heads/*
  • Go to parameters

    • Add the following parameters, it’s of course possible to skip the ones you don’t want configurable
    • Make sure you added the OAuth Client Key and Client Secret from your BitBucket user created earlier
  • Go to build steps

    • Add Sonar Analysis Begin step
    • Set a project key, version and branch as you see fit, they may not be empty but they are not important for this either
    • Add Sonar Analysis begin with the following huge parameter list with the following Additional CommandLine Args

/d:sonar.analysis.mode=preview /d:sonar.bitbucket.repoSlug=YOUR_REPOSITORY /d:sonar.bitbucket.accountName=YOUR_ORGANIZATION_OR_USER /d:sonar.bitbucket.oauthClientKey=%sonar.bitbucket.oauthClientKey% /d:sonar.bitbucket.oauthClientSecret=%sonar.bitbucket.oauthClientSecret% /d:sonar.bitbucket.pullRequestId=%trigger.pullRequestId% /d:sonar.bitbucket.minSeverity=%sonar.bitbucket.minSeverity% /d:sonar.bitbucket.approvalFeatureEnabled=%sonar.bitbucket.approvalFeatureEnabled% /d:sonar.bitbucket.maxSeverityApprovalLevel=%sonar.bitbucket.maxSeverityApprovalLevel% /d:sonar.bitbucket.buildStatusEnabled=%sonar.bitbucket.buildStatusEnabled%

Make sure it corresponds to the parameters you added before. Save the build step.

  • Add a MSBuild step with whatever targets you want. Sonar for MSBuild suggests MSBuild.exe /t:Rebuild
  • Add a Sonar Analysis End step with default settings

That’s it!

At this point you should be able to create a pull-request, see the job trigger in TeamCity and have the sonar-plugin work its magic and post any issues introduced by the PR as comments like this.

I’m especially happy i was able to put this integration in place, seeing as i had no prior C#, Sonar Analysis for MSBuild or TeamCity experience experience. But it all get’s easier with time, and most integrations look similar and require the same kind of tinkering.




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!