I have a requirement where I need to "compose" my project together, and therefore, the "output path" is where the composed output is placed. Then, there's the real output path of my published "package". It would be nice if, when invoking Set-BuildEnvironment, one could add their own custom variable, something along the lines of:
(NOTE: It's OK to have a plural parameter name when the value of the parameter is a hashtable, where there may be 1 or more items. This is a rare exception to the rule that parameter names should be singular. See, for example, Invoke-RestMethod and its parameter -Headers.)
In the "custom variable" hashtable, you only need to define the variable name and it's value. The name will be pre-pended with the VariableNamePrefix, if any, resulting in this case, the environment variable MYPROJECT_BUILDARTIFACTS being defined. And for the value, you can use the same syntax as we are already accustomed to for ensuring variables are "expanded" appropriately (e.g., $ProjectRoot).
I have a requirement where I need to "compose" my project together, and therefore, the "output path" is where the composed output is placed. Then, there's the real output path of my published "package". It would be nice if, when invoking
Set-BuildEnvironment, one could add their own custom variable, something along the lines of:(NOTE: It's OK to have a plural parameter name when the value of the parameter is a hashtable, where there may be 1 or more items. This is a rare exception to the rule that parameter names should be singular. See, for example,
Invoke-RestMethodand its parameter-Headers.)In the "custom variable" hashtable, you only need to define the variable name and it's value. The name will be pre-pended with the VariableNamePrefix, if any, resulting in this case, the environment variable
MYPROJECT_BUILDARTIFACTSbeing defined. And for the value, you can use the same syntax as we are already accustomed to for ensuring variables are "expanded" appropriately (e.g.,$ProjectRoot).