DevOps Build Notes

devops-build-notes.md

• Important links
  • Variables : https://docs.microsoft.com/en-us/azure/devops/pipelines/process/variables?view=azure-devops&tabs=yaml%2Cbatch
  • Predefined Variables : https://docs.microsoft.com/en-us/azure/devops/pipelines/build/variables?view=azure-devops&tabs=classic
  • Logging commands : https://docs.microsoft.com/en-us/azure/devops/pipelines/scripts/logging-commands?view=azure-devops&tabs=powershell
  • Expressions : https://docs.microsoft.com/en-us/azure/devops/pipelines/process/expressions?view=azure-devops
  • Conditions : https://docs.microsoft.com/en-us/azure/devops/pipelines/process/conditions?view=azure-devops&tabs=yaml

1. Build variables should be named starting with a non-reserved prefix, such as triple underscore ('___'), to avoid conflicts...

   • This helps, from other task contexts, to see that this is a custom build variable and not a conflicting devops built in variable or task sub process variable.
   • In example, 'PackageId' is used by dotnet restore... but using '___PackageId' will not conflict.

2. Build variables are string typed environment variables.

   • Storing 'true' and '1' into a build variable stores as string, not as bool or int, even if the value being pushed into the var is non-string.
   • The resulting $env var string value must be parsed/treated accordingly when being read back out.

3. Build variables are referenced via the $env: syntax in powershell.

   • In example, build variable named Object1.Object2.Member becomes $env:Object1_Object2_Member in powershell.

4. Build variables have both an inner task level scope and an outer job level scope, simultaneously.

   • Each job is a process with env vars which copies those vars into each launched task as sub-process.
   • Hence, on task exit, to save the changes to a task var copy back to the job var copy, a save command must happen like so...
     • Write-Host "##vso[task.setvariable variable=___VarName]$env:___VarName"

5. Build variables, via $env:, should be used to both 1) get job global values, and 2) set task local values...

   • If there is a build var to hold a value used across tasks, then use the $env: var instead of creating a new local var.
     • This minimizes extraneous variables and lessens instantiation calls... simply call via $env: everywhere!
   • In example,
     • $env:___VarName can be referenced the same way across all tasks under same job
     • instead of
     • $___VarName which can only be referenced within the same task, otherwise needs to be instantiated again for each new task consumer and creates yet another var

6. Build variables MUST be saved before task end.

   • This pushes the task scoped var value back to the outside scope so later tasks can consume it.
   • Use 'task.setvariable' command:
     • Write-Host "##vso[task.setvariable variable=___VarName]$env:___VarName"
       • Note the 'variable=' varname value must not be prefixed with '$env:'.

7. Write-Host does not output to the devops task log.

   • If you simply want to see values or messages during a task...
     • Use 'debug' command
       • '##[debug]Message goes here'
     • If an error or warning is preferred instead...
       • See 'Logging Commands' link
       • Use 'task.logissue' command
         • Write-Host "##vso[task.logissue type=warning;]Message here"
         • !! BE AWARE !! This will output to devops log as well as throw an error or warning to task, agent, and build pipeline!