Use isOutput=true when writing variables in Azure DevOps

[goldsam]

Using variables written in one job/stage in Azure Devops from a later job/stage currently requires re-exporting NBGV_* variables resulting in needlessly complex azure pipeline files. Would it be possible to add a cli flag to that variables written in a devops environment will include isoutput=true?

Nerdbank.GitVersioning/src/NerdBank.GitVersioning/CloudBuildServices/VisualStudioTeamServices.cs

Lines 39 to 44 in 981ef2a

	public IReadOnlyDictionary<string, string> SetCloudBuildVariable(string name, string value, TextWriter stdout, TextWriter stderr)
	{
	Utilities.FileOperationWithRetry(() =>
	(stdout ?? Console.Out).WriteLine($"##vso[task.setvariable variable={name};]{value}"));
	return GetDictionaryFor(name, value);
	}

[AArnott]

That's a great idea. I don't think we need a flag for this, since converting a variable to an output variables only expands scope AFAIK. Would you care to send the PR?

[goldsam]

Unfortunately, output variable references must include the name of the step in which they were written. This is different from standard variable references which don't required any qualifier. The following pipeline snippet demonstrates this:

steps:
- bash: |
    echo '##vso[task.setvariable variable=myCondStandardVar]true'
    echo '##vso[task.setvariable variable=myCondOutputVar;isOutput=true]true'
  displayName: "settting variables"
  name: myStep
- bash: |
    echo myCondStandardVar: $(myCondStandardVar)
    echo myCondOutputVar: $(myStep.myCondOutputVar)

I believe simply adding isOutput=true would introduce a breaking change. Aside from introducing a flag, the only solution I can think of would be to write each variable twice as a standard and output variable (using distinct names). That idea seems unclean to me. What are your thoughts?

[AArnott]

I think writing it out twice is a fine idea. We certainly don't want to break backward compat, and offering an option that gives the output variable but at the expense of breaking whatever the user has that depends on regular variables is sad too. I just wonder why AzP doesn't allow for writing out a variable that does both jobs with one log command, but I don't mind if we do it twice.

[ronaldbarendse]

What about checking an environment variable to switch to output variables instead, e.g. NBGV_CloudBuild_IsOutput? And maybe add the possibility to specify specific variables to set as output, so besides true/false, also allow setting NBGV_VersionMajor;NBGV_NuGetPackageVersion to prevent outputting all variables?

jobs:
- job: A
  variables:
    NBGV_CloudBuild_IsOutput: true
  steps:
  - script: dotnet tool install --tool-path . nbgv
  - script: ./nbgv get-version
    name: getversion
- job: B
  dependsOn: A
  variables:
    versionMajor: $[ dependencies.A.outputs['getversion.NBGV_VersionMajor'] ]  
  steps:
  - script: echo $(versionMajor)

Implementing it this way will only require changes to the build pipeline to opt-in to writing output variables and changing the syntax to use the task name...

[AArnott]

That requires more work on the user's part. What risk are we mitigating by doing that?

[goldsam]

I've been experimenting. Simply using the same name and outputting twice works fine without risk of conflicts.