Sample report for Azure DevOps

Reporting was always a pain point in Azure DevOps, because people used on SQL Server reporting Services for the on-premise version, missed a similar ability to create custom reports in Azure Dev Ops.

Now you have a nice integration with Power BI and a nice article here that explains how to connect Power BI to your instance and create some basic query. The nice part is that you can use a query that will connect directly with the OData feed, no need to install anything.

Power BI - Advanced Editor - Replace strings in query

Figure 1: Sample OData query that directly connects to your organization account to query for Work Item Data.

I strongly encourage you to experiment with Power BI because is a powerful tool that can create really good report, closing the gap with on-premise version and old Reporting Services.

Gian Maria.

Azure DevOps gems, YAML Pipeline and Templates

If you read my blog you already know that I’m a great fan of YAML Pipeline instead of using Graphic editor in the Web UI, there are lots of reasons why you should use YAML; one for all the ability to branch Pipeline definition with code, but there is another really important feature: templates.

There is a really detailed documentation on MSDN on how to use this feature, but I want to give you a complete walkthrough on how to start to effectively use templates. Thanks to templates you can create a standard build definition with steps or jobs and steps in a template file, then reference that file from real build, just adding parameters.

The ability to capture a sequence of steps in a common template file and reuse it over and over again in real pipeline is probably one of the top reason for moving to YAML template.

One of the most common scenario for me is: account with lots of utilities projects (multitargeted for full framework and dotnetstandard), each one with its git repository and the need for a standard CI definition to:

1) Build the solution
2) Run tests
3) Pack a Nuget Package with semantic versioning
4) Publish Nuget Package inside an Azure DevOps private package repository

If you work on big project you usually have lots of these small projects: Utilities for Castle, Serilog, Security, General etc. In this scenario it is really annoying to define a pipeline for each project with Graphical editor, so it is pretty natural moving to YAML. You can start from a standard file, copy it in the repository and then adapt for the specific project, but when a task is updated, you need to re-update all the project to update all the reference. With this approach the main problem is: after some time the builds are not anymore in sync and each project start to behave differently.

I start defining my template once, in a dedicated repository, then I can reuse it in any project. When the template changes, I want to be able to manually update all pipelines to reference the new version or, even better, decide which project will be updated automatically.

Lets start with the real build file, that is included in the real repository and lets check how to reference a template stored in another repository. The only limit is that the repository should be in the same organization or in GitHub. Here is full content of the file.

trigger:
- master
- develop
- release/*
- hotfix/*
- feature/*

resources:
  repositories:
    - repository: templatesRepository
      type: git
      name: Jarvis/BuildScripts
      ref: refs/heads/hotfix/0.1.1

jobs:

- template: 'NetStandardTestAndNuget.yaml@templatesRepository'
  
  parameters:
    buildName: 'JarvisAuthCi'
    solution: 'src/Jarvis.Auth.sln'
    nugetProject: 'src/Jarvis.Auth.Client/Jarvis.Auth.Client.csproj'
    nugetProjectDir: 'src/Jarvis.Auth.Client'

The file is really simple, it starts with the triggers (as for a standard YAML build), then it comes a resources section, that allows you to references objects that lives outside the pipeline; in this specific example I’m declaring that this pipeline is using a resource called templateRepository, an external git repository (in the same organization)  called BuildScripts and contained in Team Project called Jarvis; finally the ref property allows me to choose the branch or the tag to use with standard refs git syntax (refs/heads/master, refs/heads/develop, refs/tags/xxxx, etc). In this specific example I’m freezing the version of the build script to the tag 0.1.0, if the repository will be upgraded this build will always reference version 0.1.0. This imply that, if I change BuildScripts repository, I need to manually update this build to reference newer version. If I want this definition to automatically use new versions  I can simply reference master or develop branch.

The real advantage to have the template versioned in another repository is that it can use GitFlow so, every pipeline that uses the template, can choose to use specific version, or latest stable or even latest development.

Finally I start to define Jobs, but instead of defining them inside this YAML file I’m declaring that this pipeline will use a template called NetStandardTestAndNuget.yaml contained in the resource templatesRepository. Following template reference I specify all the parameters needed by the template to run. In this specific example I have four parameters:

buildName: The name of the build, I use a custom Task based on gitversion that will rename each build using this parameter followed by semversion.
solution: Path of solution file to build
nugetProject: Path of the csproject that contains the package to be published
nugetProjectDir: Directory of csproject to publish

The last parameter could be determined by the third, but I want to keep YAML simple, so I require the user of the template to explicitly pass directory of the project that will be used as workingDirectory parameter for dotnet pack command.

Now the real fun starts, lets examine template file contained in the other repository. Usually a template file starts with a parameters section where it declares the parameters it is expecting.

parameters:
  buildName: 'Specify name'
  solution: ''
  buildPlatform: 'ANY CPU'
  buildConfiguration: 'Release'
  nugetProject: ''
  nugetProjectDir: ''
  dotNetCoreVersion: '2.2.301'

As you can see the syntax is really simple, just specify name of the parameter followed by the default value. In this example I really need four parameters, described in the previous part.

Following parameters section a template file can specify steps or event entire jobs, in this example I want to define two distinct jobs, one for build and run test and the other for nuget packaging and publishing

jobs:

- job: 'Build_and_Test'
  pool:
    name: Default

  steps:
  - task: DotNetCoreInstaller@0
    displayName: 'Use .NET Core sdk ${{parameters.dotNetCoreVersion}}'
    inputs:
      version: ${{parameters.dotNetCoreVersion}}

As you can see I’m simply writing a standard jobs section, that starts with the job Build_and_test that will be run on Default Pool. The jobs starts with a DotNetCoreInstaller steps where you can see that to reference a parameter you need to use special syntax ${{parameters.parametername}}. The beautiful aspect of templates is that they are absolutely like a standard pipeline definition, just use ${{}} syntax to reference parameters.

Job Build_and_test prosecute with standard build test tasks and it determines (with gitversion) semantic version for the package. Since this value will be use in other jobs, I need to made it available with a specific PowerShell task.

  - powershell: echo "##vso[task.setvariable variable=NugetVersion;isOutput=true]$(NugetVersion)"
    name: 'SetNugetVersion'

This task simply set variable $(NugetVersion) as variable NugetVersion but with isOutput=true to made it available to other jobs in the pipeline. Now I can define the other job of the template to pack and publish nuget package.

- job: 'Pack_Nuget'
  dependsOn: 'Build_and_Test'

  pool:
    name: Default

  variables:
    NugetVersion: $[ dependencies.Build_and_Test.outputs['SetNugetVersion.NugetVersion'] ]

The only difference from previous job is the declaration of variable NugetVersion with a special syntax that allows to reference it from a previous job. Now I simply trigger the build from the original project and everything run just fine.

image

Figure 1: Standard build for library project, where I use the whole definition in a template file.

As you can see, thanks to Templates, the real pipeline definition for my project is 23 lines long and I can simply copy and paste to every utility repository, change 4 lines of codes (template parameters) and everything runs just fine.

Using templates lower the barrier for Continuous integration, every member of the team can start a new Utility Project and just setup a standard pipeline even if he/she is not so expert.

Using templates brings a lots of advantage in the team, to add to standard advantages of using plain YAML syntax.

First: you can create standards for all pipeline definitions, instead of having a different pipeline structure for each project, templates allows you to define a set of standard pipeline and reuse for multiple projects.

Second: you have automatic updates: thanks to the ability to reference templates from other repository it is possible to just update the template and have all the pipelines that reference that template to automatically use new version (reference a branch). You keep the ability to pin a specific version to use if needed (reference a tag or a specific commit).

Third: you lower the barrier for creating pipelines for all team members that does not have a good knowledge of Azure Pipelines, they can simply copy the build, change parameters and they are ready to go.

If you still have pipelines defined with graphical editor, it is the time to start upgrading to YAML syntax right now.

Happy Azure Devops.

Retrieve Attachment in Azure DevOps with REST API

In a previous post I’ve dealt on how to retrieve image in Work Items description or Comments with a simple WebClient request, using network credentials taken from  TfsTeamProjectCollection class.

The solution presented in that article is not complete, because it does not works against Azure Devops, but only against a on-premise TFS or Azure DevOps Server. If you connect to Azure DevOps you will find that the Credentials of the TfsTeamProjectCollection class are null, thus you cannot download the attachment because the web request is not authenticated.

To be completely honest, TfsTeamProjectCollection class is quite obsolete, it uses old webservices, but it is really useful if you have lots of code accumulated on the years that uses it and it works perfectly with newest version of the service.

Azure DevOps has a different authentication scheme from on-premise version, thus you have no Network Credentials to do a simple web request for attachment if you use old TfsTeamProjectCollection class.

The key to the solution of the problem is using the new HTTP REST API and the good news is that you can use old C# API based on SOAP server and new REST API in the same project without a problem. Here is the correct code for the connection

image

Figure 1: Connecting to the server.

Code in Figure 1 is valid for on-premise server or for Azure Dev Ops server and if you are running the code from a program with a UI (like a WPF application) it will show the Azure DevOps login page to perform the login with azure Authentication. This is the coolest part of the API, few lines of code and you can connect to the service without worrying of authentication method

Once the application is connected, the VssConnection class can be used to grab references to a series of clients dedicated to access various sections of the service. After connection I immediately retrieve a reference to the WorkItemTrakingHttpClient class. Remember that all services/client that contains the Http string in the name are based on the new REST api.

_workItemTrackingHttpClient = _vssConnection.GetClient< WorkItemTrackingHttpClient >();

Thanks to this client, we can perform various query to the WorkItemStore and we can use this object to download any attachment. The only thing I need to do is to use a regex to parse attachment uri to grab two information, fileName and fileId (A guid).

The great benefit of using a client, instead of raw WebClient call, is that you does not need to worry about auth, everything is handled by the library.

A typical attachment url has this format https://dev.azure.com/accountName/3a600197-fa66-4389-aebd-620186063db0/_apis/wit/attachments/a92c440e-374e-4349-a26c-b9ba553e1264?fileName=image.png  and we need to extract file name (image.png) and file id (a92c440e-374e-4349-a26c-b9ba553e1264) the portion of url after attachments part. One possible regex is _apis/wit/attachments/(?<fileId>.*)\?fileName=(?<fileName>.*)  and it allows me to extract fileId and fileName from the url of the attachment. Once you have fileId and fileName parameters you have a dedicated call to download the attachment.

using (var fs = new FileStream(downloadedAttachment, FileMode.Create))
{
    var downloadStream = ConnectionManager.Instance
        .WorkItemTrackingHttpClient
        .GetAttachmentContentAsync(new Guid(fileId), fileName, download: true).Result;
    using (downloadStream)
    {
        downloadStream.CopyTo(fs);
    }
}

The variable downloadedAttachment is a temp file name where I want to download the attachment, I simply open a writer stream with FileMode.Create, then call the GetAttachmentContentAsync method of the WorkItemTrackingHttpClient that returns a Task<Stream> and finally I copy attachment stream to destination stream (temporary file name) to physically download the file.

When you interact with Azure DevOps with API, you always should try to use the official client instead of using raw WebClient class, this will save you time and headache.

Gian Maria.

Export Work Item Information to Word Document

This is a series of posts on how to export data from Azure DevOps to a Word Document, composing word templates with Open XML Sdk.

The project is open source and available Here: https://github.com/alkampfergit/AzureDevopsWordPlayground

Post in the series:
1) API Connection
2) Retrieve Work Items Information
3) Azure DevOps API, Embed images into  HTML
4) Create Word Document For Work Items
5) Retrieve image in Work Item Description with TFS API
6) Retrieve Attachment in Azure DevOps with REST API in C#

Gian Maria

Retrieve image in Work Item Description with TFS API

When you try to export content of Work Item from Azure DevOps (online or server) you need to deal with external images that are referenced in HTML fields of Work Item. I’ve dealt in the past on this subject, showing how you can retrieve images with Store and Attachment Work Item Property.

Sadly enough, I’ve encountered situation with on-premise version of TFS where I found this type of image src inside HTML fields.

https://nameoftfsserver/NameOfCollection/WorkItemTracking/v1.0/AttachFileHandler.ashx?FileNameGuid=AB6fc2e0-c449-4090-ab98-fac6c87fc219&amp;FileName=temp1554203067610.png 

As you can see the image is stored inside TFS as attachment, because it is served by AttachFileHandler, but you do not find any information of this image in Work Item Attachments property.

Tfs  / Azure DevOps has different technique to attach images to Work Item Description and image file is not always a real Attachment of the Work Item

This format has no FileId to retrieve the image with the Store interface, nor is present in the Attachments collection of current Work Item, so we need to download it with a standard WebClient, instead of relying to some specific API call. The problem is authentication, because if you simply try to use a WebClient to download the previous url you will got a 401.

The solution is to populate the Credentials property of WebClient with the current credentials used to connect to the TFS, in my situation I’ve this value into an helper class called ConnectionManager.

image

Figure 1: How to correctly retrieve image attached to a work item.

The code is really simple, just get the credential from Connection manager, generate a temp file name and use WebClient to download image content.

TfsTeamProjectCollection class, once connected to TFS / Azure Devops instance, contains an instance of used credentials in Credentials property. This can be used to do standard request with WebClient to the server.

The GetCredentials() method of ConnectionManager is really simple because, after connection is stabilished, the instance of TfsTeamProjectCollection class has a Credentials property that contains credentials used to connect to the server.

Armed with correct credentials, we can use WebClient standard class to download images from the server.

Gian Maria