Reading parameters from $BuildInfo (i.e. the Build.yaml file)

[falkheiland]

Problem description

suggestion to create an alternative to the use envrionment variables such as $Env:HelpSourceFolder inside the Config if not set via param input, and using a default as last resort.

Verbose logs

n.a.

How to reproduce

n.a.

Expected behavior

n.a.

Current behavior

n.a.

Suggested solution

have Vars section in the build.yaml as alternative to env vars

e.g.

Vars:
  HelpSourceFolder: docs/subfolder

Operating system the target node is running

OsName               : Microsoft Windows 11 Pro
OsOperatingSystemSKU : 48
OsArchitecture       : 64-Bit
WindowsVersion       : 2009
WindowsBuildLabEx    : 22000.1.amd64fre.co_release.210604-1628
OsLanguage           : de-DE
OsMuiLanguages       : {de-DE, en-US}

PowerShell version and build the target node is running

Name                           Value
----                           -----
PSVersion                      5.1.22000.282
PSEdition                      Desktop
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
BuildVersion                   10.0.22000.282
CLRVersion                     4.0.30319.42000
WSManStackVersion              3.0
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1

Module version used

Name    Version Path
----    ------- ----
Sampler 0.112.0 C:\Users\fheiland\Documents\PowerShell\Modules\Sampler\0.112.0\Sampler.psd1

[johlju]

Parameters in the tasks that uses property uses the value passed to the parameter, or uses the value on the environment variable that matches, or uses the value in a variable in the parent scope. Can you explain how the change would benefit your pipeline process if neither of the previous can be used.

[falkheiland]

i would not need to set environment variables and use the existing config file for a config.

[gaelcolas]

Yeah, agreed it should be readable from the build.yaml. Not being able to do so is just an oversight. using the InvokeBuild property feature to read from environment variable is not a competing feature, just another way of achieving this feature.

[gaelcolas]

Also, to @johlju's point, one of the problem is that for the property to be settable by parameter to build.ps1, the parameter should exist in build.ps1, which I can't recommend (best to keep it generic to all Sampler projects).

[johlju]

I'm guessing you both mean that the build.ps1 would read variables from the config (Vars: or BuildVariables: for clarity). Then build.ps1 set them as environment variables unless there already exist an environment variable with that name, and it wasn't passed as a parameter to build.ps1. 🤔

Labeling it as an enhancement, happy to review a PR for this.