Skip to main content

Add Git Commit Hash and Build Number to a Static React Website using Azure DevOps

While working on a React based static website recently, there was a need to see exactly what was deployed in the Dev/Test environments to reduce confusion amongst teams. I wanted to show something like this:

A quick look at the site's footer should show the Git Commit Hash and Build Number which was deployed and click through to actual commits and build results. Let's see how we achieved this using Azure DevOps.

Git Commit Hash

Azure DevOps exposes a variable called $(Build.SourceVersion) which contains the hash of the commit. So I defined a variable in the Build Pipeline using it.

Build Id and Build Number

Azure DevOps also exposes two release time variables $(Build.BuildId) and $(Build.BuildNumber) which can be used to define custom variables in the pipeline.

So we have a total of 3 variables defined:

Next we use these variables in our React App. I created 3 global variables in index.html and assigned a token value to them.

<script type="text/JavaScript">

These variables are used in App.js to create the footer. Notice the use of hard-coded links as I like to keep things simple.

<footer className="App-footer">
          Deployed from commit{" "}
              "" +
          </a>{" "}
          via build{" "}
              "" +

Next I used Azure DevOps Pipeline and excellent "Replace Tokens" task to replace the tokens. You may need to import this task in your Azure DevOps organization if you haven't used it before.

This is the complete YAML of my CI/CD pipeline.

# Node.js React Web App to Linux on Azure
# Build a Node.js React app and deploy it to Azure as a Linux web app.
# Add steps that analyze code, save build artifacts, deploy, and more:



  # Azure Resource Manager connection created during pipeline creation

  # Web app name
  # Environment name

  # Agent VM image name

  displayNameBuild stage
  - jobBuild

    - taskNpm@1
      displayName'NPM Install'
    - taskNpm@1
      displayName'NPM Build'
        customCommand'run build'
    - taskArchiveFiles@2
      displayName'Archive files'

    - upload$(Build.ArtifactStagingDirectory)/$(Build.BuildId).zip

  displayNameDeploy stage
  - deploymentDeploy
          - taskExtractFiles@1
          - taskreplacetokens@3
            displayName"Replacing Tokens"
          - taskAzureRmWebAppDeployment@4
              azureSubscription'MSDN Platforms (xxxxx)'

That's it! You can now show your commit hash and build ids in your live static React website helping you test team to certify a particular build and reduce confusion.


Popular posts from this blog

Integrating React with SonarQube using Azure DevOps Pipelines

In the world of automation, code quality is of paramount importance. SonarQube and Azure DevOps are two tools which solve this problem in a continuous and automated way. They play well for a majority of languages and frameworks. However, to make the integration work for React applications still remains a challenge. In this post we will explore how we can integrate a React application to SonarQube using Azure DevOps pipelines to continuously build and assess code quality. Creating the React Application Let's start at the beginning. We will use npx to create a Typescript based React app. Why Typescript? I find it easier to work and more maintainable owing to its strongly-typed behavior. You can very well follow this guide for jsx based applications too. We will use the fantastic Create-React-App (CRA) tool to create a React application called ' sonar-azuredevops-app '. > npx create-react-app sonar-azuredevops-app --template typescript Once the project creation is done, we

Centralized Configuration for .NET Core using Azure Cosmos DB and Narad

We are living in a micro services world. All these services are generally hosted in Docker container which are ephemeral. Moreover these service need to start themselves up, talk to each other, etc. All this needs configuration and there are many commercially available configuration providers like Spring Cloud Config Server, Consul etc. These are excellent tools which provide a lot more functionality than just storing configuration data. However all these have a weakness - they have a single point of failure - their storage mechanism be it a file system, database etc. There are ways to work around those but if you want a really simple place to store configuration values and at the same time make it highly available, with guaranteed global availability and millisecond reads, what can be a better tool than Azure Cosmos DB! So I set forth on this journey for ASP.NET Core projects to talk to Cosmos DB to retrieve their configuration data. For inspiration I looked at Steeltoe Con


Have you recently tried to shop on any Indian e-commerce website? If you have, you too would be frustrated by the constant nagging done by these sites to download their app. Myntra has gone ahead and shut its website down completely! Others like Flipkart won't let you browse any product in peace and will immediately try to "connect" you to their app - even when you are already at their site and trying to buy a product. Amazon India will release "app-only" offers and discounts. All this is done in the garb of making customer experience better. @mayankMSFT We direct users to the mobile App in order to provide better shopping experience. We have passed your feedback along. — flipkartsupport (@flipkartsupport) August 7, 2015 Only problem is that it makes user experience even worse. These companies are trying to lure the consumer into a walled garden so that they make bad, misinformed buying decisions . Let me elaborate. On a desktop browser