2

According to https://learn.microsoft.com/en-us/azure/devops/pipelines/build/variables?view=tfs-2018

These variables are automatically set by the system and read-only. (The exceptions are Build.Clean and System.Debug.)

Nonetheless, if one tries to create a vnext build with the following tasks

  1. Inline Powershell - Write-Host $env:BUILD_SOURCEVERSION
  2. Inline Powershell - Write-Host ("##vso[task.setvariable variable=build.sourceversion;]"+'someNewValue')
  3. Inline Powershell - Write-Host $env:BUILD_SOURCEVERSION

Task 2 won't fail, and the last task will output something like

2018-10-24T07:37:23.1232438Z someNewValue

instead of the expected original source version (the value printed in the first task).

So,

  1. Either I am misreading the docs / they are unclear on that account
  2. Or is it some genuine defect in TFS that one should pursue with MS?
Eugene Podskal
  • 10,270
  • 5
  • 31
  • 53
  • 1
    One of my colleagues said it is by design. For example this way you can overwrite the build name. You should ask Microsoft for clearance instead, but I think the docs are wrong. – Daniel Habenicht Oct 24 '18 at 08:02

1 Answers1

0

That's expected behavior.

The predefined variables are automatically set by the system and read-only.

However if you have defined a pipeline variable of the same name as an environment variable (for example, PATH), your pipeline variable value overrides the agent host's environment variable.

See Environment variables for details.

So, in your scenario actually you defined a new pipeline variable with the same name as the pre-defined one, but not really overwrite the predefined variable. And they can only be used in the pipelines...

UPDATE:

Well, the documentation is somewhat misleading about the Environment Variables and makes some slightly contradictory claims about their readonlyness. Actually all variables (*predefined, build, environment...) basically work as the environment variables mentioned here.

BTW, you can get all the available environment variables by get-childitem -path env:* in pipeline.*

PowerShell script for example:

$environmentVars = get-childitem -path env:*
foreach($var in $environmentVars)
{
 $keyname = $var.Key
 $keyvalue = $var.Value

 Write-Output "${keyname}: $keyvalue"
}
Andy Li-MSFT
  • 28,712
  • 2
  • 33
  • 55
  • 1
    That's what I think is probably is the case here. But the problem is that the [section](https://docs.microsoft.com/en-us/azure/devops/pipelines/process/variables?view=tfs-2018&tabs=yaml%2Cbatch#environment-variables) you've quoted here deals with **Environment** variables (as OS environment, not the build/agent environment). So the documentation is not clear on that point. Well, it's even worse actually - https://docs.microsoft.com/en-us/azure/devops/pipelines/process/variables?view=tfs-2018&tabs=yaml%2Cbatch#system-defined-variables `As a pipeline author or end user, you cannot set...` – Eugene Podskal Oct 25 '18 at 07:58
  • Well, actually it includes the OS and build/agent environment variables. Basically you can get all the environments variables by `get-childitem -path env:*` in pipeline. – Andy Li-MSFT Oct 25 '18 at 08:41
  • 1
    Yeah, that's probably the case... Just that the documentation is at least moderately misleading. I'll accept this answer if you mention something like `all variables (predefined, build, environment...) basically work as https://learn.microsoft.com/en-us/azure/devops/pipelines/process/variables?view=tfs-2018&tabs=yaml%2Cpowershell#environment-variables ,despite that the documentation makes some slightly contradictory claims about their readonlyness and etc.` - you probably don't object to the correctness of that statement, do you? – Eugene Podskal Oct 25 '18 at 09:57
  • https://github.com/microsoft/azure-pipelines-yaml/blob/master/design/readonly-variables.md - we are on Version Dev18.M170.6 and we can't change readonly variables anymore in the build agents. – Prof. Falken Jul 20 '21 at 15:02