Build status is index instead of value

[Alin-Dumitrescu]

Hello,

We are using the following template, however the build.status appears to be a number rather than the actual status (e.g. 2 instead of completed. How do we show the actual status instead of it's id?

Associated Builds ({{builds.length}})

Repo Name	Build Id	Build Name	BuildNumber	Build Status
{{#forEach builds}}
[{{build.repository.name}}]({{replace build.repository.url "ASSU%20-%20EY%20Helix%20Process%20Mining" "9c07fa8e-276a-45c1-93ff-800ac22d12fa"}})	{{this.build.id}}	{{build.definition.name}}	{{this.build.buildNumber}}	{{build.status}}
{{/forEach}}

[rfennell]

It is a problem that some of the REST API calls return a string for the status and other calls the enum int value. The enumvalue mapping can be found here, the summary is

Enum	Status
None = 0	No status.
InProgress = 1	The build is currently in progress.
Completed = 2	The build has completed.
Cancelling = 4	The build is cancelling
Postponed = 8	The build is inactive in the queue.
NotStarted = 32	The build has not yet started.

So you could put a handlebar {{#if}} block, or write a custom extension, to convert the int into a string.

However, I would ask why you want to show the status, what value is there?

• For any pipeline artifacts referenced by your pipeline/release the release notes the status will be completed. They have to have been completed successfully else why cant be used.
• And the actual pipeline containing the generate release notes task will always be in the In progress state, it can't have finished as it is running a task
  So what value is the status in a table?

[Alin-Dumitrescu]

Yes, it does seem it doesn't have any value - but the customer wants to see status instead of id. How would the if block work or maybe can we do a lookup?

[rfennell]

As I said there are two options...

The 'dirtier one' is using one of the Handbars Helpers I include in the task. You could add a block eq checks to match the status and return a string

{{eq build.status 1 'In progress'}} 
{{eq build.status 2 'Completed'}} 

The other, neater, option is a custom module as detailed in the WIKI in the modules section. This can be stored as a file under source control or an inline parameter (as below). The code will be something like the following

- task: XplatGenerateReleaseNotes@3
   inputs:
      outputfile: '$(Build.ArtifactStagingDirectory)\releasenotes.md'
      # all the other parameters required
      customHandlebarsExtensionCode: |
         module.exports = {BuildStatus(num) {
                switch(num) {
               case 1:
                   return "In Progress"
                  break;
               case 2:
                   return "Completed"
                  break;
               case default:
                   return "This state cannot occur"
                  break;
                }
         }};

In your template you would then call {{BuildStatus build.status}}

But again I would stress - I think the best answer is telling the client that they have asked for meaningless data, as I said above. Much better to educate them, rather than use this rather pointless blocks of code.