Improve your Azure Pipelines with the new Runtime Parameters

The Azure DevOps team has finally released Sprint 166. It's a very small update but introduces a new neat feature that was way too long overdue.

Chances are high that you are familiar with some true madness like this:

It takes you three clicks to modify a single value for every single variable. Tedious and annoying.

---

Runtime Parameters Enter the Game

Microsoft’s latest release notes state this:

Runtime parameters
With this update, we’re adding runtime parameters. Runtime parameters let you have more control over what values can be passed to a pipeline. Unlike variables, runtime parameters have data types and don’t automatically become environment variables.

This is a real godsent because we turn the screens above into something beautiful like this that will save you a lot of time:

Let me quickly show you how so you don’t need to dig through the DevOps documentation.

---

My previous Pipeline definition used to look like this at the beginning of the YAML file:

trigger:
- master

variables:
  buildConfiguration: Release

And in the variables pane I had to set additional variables for them to show up in new pipeline run blade:

Why do we need to set variables in two different places?

First of all, let’s get rid of the variables in the variable pane and the YAML file.

Afterward, include the parameters key that takes a list of parameters. Let’s replace the build configuration variable with this:

trigger:
- master

parameters:
- name: buildConfiguration
  displayName: 'Build Configuration'
  type: string
  default: Release
  values:
    - Release
    - Debug

Parameters are very versatile and can be restrained to many types you’re already used to such as strings, booleans, numbers, objects, but also steps, jobs, and stages from your pipeline definition. Wowzers.

A neat addition is that you can also set default values to it.

Moving on to the other variables, we can simply introduce two additional boolean parameters that are simpler than the one before:

parameters:
- name: buildConfiguration
  # ...
- name: runDockerBuild
  displayName: 'Run Docker'
  type: boolean
  default: false
- name: pushDockerImages
  displayName: 'Push Images'
  type: boolean
  default: false

Easy peasy. Now let’s replace all current variable references to parameters.

For this, you can simply swap out $(variableName) or variables.variableName to ${{parameters.parameterName}}).

It’s important to know that parameters are only available at template parsing time and must be surrounded by ${{}}.

---

There is a special declaration type for all condition: keys. These don’t work for parameters, so you will need to replace declarations like these

  - job: DockerBuild
    displayName: 'Docker Build'
    condition: variables.runDockerBuild
    pool:
      vmImage: 'ubuntu-latest'
    steps: # ...

To this:

- ${{ if eq(parameters.runDockerBuild, true) }}
  - job: DockerBuild
    displayName: 'Docker Build'
    pool:
      vmImage: 'ubuntu-latest'
    steps: # ...

Actually, I’m lying, you can make use of template variables and surround them with ${{}} like this:

- task: DockerCompose@0
  displayName: 'Push Images'
  condition: ${{parameters.pushDockerImage}} # <--
  inputs: # ...

But hear me out: This is probably something you are not used to and kinda feels weird at a first glance, but in the longterm, it helps you to organize and navigate to conditional steps in your definitions with ease because they are easier to spot than conditions and foremost they aren’t part of the parsed template and hence won’t show up in the jobs summary:

---

Voilá. Now it’s time to save and commit your modifications and run your facelifted pipeline. You’ll be greeted with this handsome blade:

And that’s how you could enhance your Azure DevOps Pipelines within 2 minutes. Worth it.

---

Here are some possible use cases for you to try out

• Pass a Docker image tag as a parameter
• Select the environment you would like to deploy to
• Determine whether or not you would like to run integration tests
• Set the version of your assembly/library/whatever
• Pass your current mood as parameter and print with echo so your mates know how you are doing because why not

Cheers and have fun. Feel free to follow me on Medium or my dev.to for future posts.

---

Further references

• Runtime parameters docs: https://docs.microsoft.com/en-us/azure/devops/pipelines/process/runtime-parameters?view=azure-devops
• Azure DevOps Release Notes Sprint 166: https://docs.microsoft.com/en-us/azure/devops/release-notes/2020/sprint-166-update

Comments

[Sam Critchley]

A sorely needed feature that they failed to support in the REST api. This essentially means you cannot use runtime parameters in an automation scenario.