Integrate NDepend with Atlassian Bamboo

So far we don't propose a first-class integration with Bamboo but we are planning to do it.

You can vote for Bamboo integration on our User Voice.

For now, you can follow this awesome in-depth tutorial written by Nordès Lamarre reproduced below, courtesy of the author.

What is Bamboo?

Quickly speaking, Bamboo is the Build server from Atlassian in it’s CI stack. It is often used with the integration of BitBucket and it also offers possibilities to connect to any other repositories (GitHub included). Bamboo itself allows you to create build project, deployment strategy, interconnection with other Atlassian tools or even send automatically a message with the build status to your #Slack channels. If you already played with Jenkins, AppVeyor or GitLab, you should be already familiar with the daily usage of such tool. In order to get more details on Bamboo, please follow this link, it will provides full details on Bamboo.

  • Bamboo Server (or Agent) in Windows. In case you need to install a new instance click here to download Bamboo.
    • It is mandatory to use or install the JDK 1.8 (or JRE also seems to work) in a folder named without any space. Any version greater than 8 won’t work. This is supposed to become supported in the future.
    • If you run a test server locally in order to look how it works, it will be accessible on http://localhost:8085/
    • During the first time wizard, a key will be required for activation (30 days or real license). To obtain a 30 days license, go into your Atlassian space or simply use this link in order to request the evaluation license for your account
  • NDepend Build Machine license or NDepend Trial active on the build machine (or your current machine, if you run Bamboo locally)
  • PowerShell is not mandatory, but you will see later that it is a must in case you want to have a proper build without failure

Bamboo – Add NDepend Capability

What is a capability in Bamboo

In Bamboo, in order to be able to use any build related tools, you should normally set it for each agent in order to add a specific capability. In this case, we will add the NDepend capability to a Windows agent. That capability will point to the NDepend.Console.exe executable coming from the NDepend package previously installed/downloaded. Don’t forget to launch it at least once in order to trigger the license. The details are available in the documentation. In my case, it is installed into [D:\NDepend\NDepend_2018.2.1.9119]. I prefer to keep the version within the folder name, this way it is easy to know if my agent is using the proper version of the tool. If I change the executable folder, this capability will affect automatically all builds that are using this capability. It will not, in any cases, re-trigger an automatic build. The variable will then be re-applied starting from the next build.

It is common to keep those capabilities or executable in that screen. It groups all your agent(s) features. More details on this feature can be found on the Atlassian website.

Be aware: The capability displays dependencies with existing builds. That being said, if a capability variable is used within a script, you won’t see anywhere that there is an active dependency. For that reason in case of multiple agents, you are required to specify manually which Agent should be used for your build stage.

Go to your agent configuration
  • 1) Click on the options wheel;
  • 2) Select Agents;
  • 3) This will make you jump in the administration panel directly on the Agents build resources;
  • 4) Select any of your Windows build Agent by clicking it.

Agent summary
  • 1) Validate that your agent name is valid;
  • 2) Select the Capabilities tab;
  • 3) Click the Add capability link button.

Adding the capability
  • 1) Capability type: Executable
  • 2) Type: Command
  • 3) Executable label: NDepend
  • 4) Path: D:\NDepend\NDepend_2018.2.1.9119\NDepend.Console.exe
  • 5) click the button Add

See the Agent specific capabilities

As you can see, after doing the previous steps, you will have your Agent specific capability added. Now, we can use that capability during our build.

Bamboo Build configuration – Capabilities (Easy)

Let’s consider that your build already exists and that you want to add the NDepend.Console.exe command. In the tutorial below I will use a simple Dotnet Core 2.1 solution as sample. The build will be named IdentityServer4.LdapExtension (GitHub project), where you would have your Git repository, NDepend project and your basic build already configured (checkout and build).

Add a new task to your build stage
  • 1) Ensure that you are in the configuration of your project;
  • 2) Go to your build job where you usually run your tests and everything else;
  • 3) Within the Tasks tab, you will find all details of your current job;
  • 4) Add a new task.

Once the popup show
  • 1) Search for Command in the search box;
  • 2) Select Command by clicking it.

Let’s configure the command
  • 1) The new command task should be displayed already;
  • 2) The description of the task, in this case: NDepend;
  • 3) Select the executable you created for your agent capability: NDepend;
  • 4) Enter the argument to the full path of your NDepend project file (.ndproj extension).
    Before that make sure that in the NDepend UI NDepend Project Properties > Paths Referenced all paths are defined as relative (to the location of the project file).

    Example: ${}/IdentityServer.LdapExtension.ndproj.
    You can add the /silent option if you don’t want to see all the output logs from NDepend, but I strongly not advise to do so within a build. You might need to debug using the logs.

  • 5) Save your configuration

Build your new configuration

I recommend to always build after having done any modification. That way it’s easy to see if you caused the build to fail for a real reason (configuration) or if it’s due to code change (triggered builds).

Notice that NDepend.Console.exe returns a non-zero exit code when at least one Quality Gate fails. This exit code can be used to eventually stop your build process in such situation. See more explanations here.

The report will exist even on failure, however the build will be red and your artifact will probably not be even available. Since there’s no /ErrorLevel custom configuration for the exit code, then you will have to do differently in order to ignore those errors.

  • Option 1: Ignore the errors by adding the special tags from NDepend within your code.
    In that case, simply add the NDepend ignore attributes where required and re-launch a build after your commit.
  • Option 2: Use a script instead of a command in order to control your flow completely and to continue even if there’s a quality gate issue
    This is the topic of the next section

Bamboo Build configuration – PowerShell Script (Complex)

As stated previously, this section is more for those who already have a project with no severe issue that causes a quality gate to fail, or if you want to fail upon quality gate but still want to generate reports.

Don’t get me wrong, the Capability created is worth it. However the only drawback in this case is that the Capability will not be detecting our build dependency to NDepend.

In this case, instead of creating a command, we will create a script (or add to current Dotnet Core build script)

  • 1) Go in your Build configuration, default stage (or specific one) and click on Add task;
  • 2) Select the Script type;
  • 3) Enter the description and select Windows PowerShell as the Interpreter;
  • 4) In this case, we will be using the Inline type instead of a PS1 shell script. This option will create automatically a shell script behind the scene. Just re-write the code-snippet bellow the image.

The PowerShell is using the existing NDepend project file (.ndproj extension, this is an XML file). Then it is creating the final command and execute it (Invoke-Expression). Here’s the PowerShell script used in the above picture.

# NDProj should normally be a variable in the build, the same goes for other parts.
# This way you can use a build script instead of inline, and that build script
#  can be part of your build repository.
$ndproj = "IdentityServer.LdapExtension.ndproj"

# Load the NDepend XML project file.
$ndependXml = [xml](Get-Content .\${ndproj})

# Launch NDepend command
$expr = "${bamboo.capability.system.builder.command.NDepend} " +`
   "${}\${ndproj} " +`
   "/OutDir ${}\NDependOut"

Invoke-Expression $expr

# Simple output for the execution result.
write-host "The exit code was: ${LASTEXITCODE}"

Generate the NDepend Artifact

Now, you should be able to build and have the NDepend output folder. In this demo, we have NDependOut as the folder. To do so, we need to add the artifact configuration. Please, go back in the Build configuration and your default stage where you have the NDepend script. Once this is complete, select the Artifacts tab and click on Create artifact button.

The fields to input are:

  • Name: NDepend
  • Location: NDependOut
  • Copy pattern: **/*

Once this is completed, you should be able to re-build your project and see if your build artifact is there. Note that if you want to compare your builds, you could re-use the shared artifact. This is a bit more complex, but it’s possible and it won’t be explored in this tutorial. You could simply avoid cleaning up the build folder at every new build. I don’t suggest to do that, but it’s something that could work out.

For example, we have the following successful build:

  • 1) Green build = success
  • 2) Go in the artifacts of your build
  • 3) Click on the artifact name that interest you (NDepend in this case)

Once the artifact will open, it will show the content of the ZIP file. Just click on the file NDependReport.html. Doing so opens a link that looks like: http://localhost:8085/artifact/I4E-ID/shared/build-19/NDepend/NDependReport.html#Main

Your page should look similar to this (It depends actually on your project):


Thank you for reading, and I hope it helped you configure your build! If you wish to also integrate with SonarQube, you also can. You just have to do what is proposed in SonarQube integration with NDepend documentation and in your Bamboo script, where you build your Dotnet project, you add the NDepend Sonar Runner. The result can then be seen after your build directly within SonarQube. Don’t forget that you might want to install some Marketplace plugin in Bamboo for Sonar in order to send the data. In case you don’t want to use a plugin it is also possible.

About The Author

Nordès Ménard-Lamarre

With more than 15 years working actively in IT as a specialist, he loves taking any challenge brought to him. Having a strong background in development, databases and architecture he's also talented in managing teams. In his daily work, he enjoys sharing his knowledge with others and love to share and discuss about new ideas. He always says that we never stop learning, it's the only path that lead to success and finding the best solution to existing problems. He thinks that every IT specialist should follow the latest trends and experiment them everyday, Doing so improves their general knowledge and helps providing the best solutions to any problem. You can follow him through his Blog or contact him through his LinkedIn profile.