Is it possible to get the values for custom variables being used in the build? I know they can be dumped to the console output as per what this example describe. But still want to find an easier way to archive it.
http://www.codewrecks.com/blog/index.php/2017/08/04/dump-all-environment-variables-during-a-tfs-vsts-build/
There isn’t the easier way then the way you provided to retrieve build variables, the value of variable can be changed during the build time (Logging Command), so it’s better to retrieve the variable at the end of the build (the way you provided).
Note, the secret variables can’t be output as general text.
Related
I'm trying to set up a variable in the Azure Build Pipelines Classic Editor to use conditional functions to determine its value. YAML is not an option (unless there's some way to inject YAML as part of a Classic build...?).
In my current scenario, the idea is that the variable would return one of a few possible string values (or empty string) depending on the branch that triggered the build.
I want something along the lines of this:
I fear this may be a YAML-only thing, but hopefully someone can tell me I'm wrong about that.
Like Matt mentioned in the comment, the best approach for this would be to use a script (powershell or bash) that will have the logic to set the variable.
For more details about how to set a variable, have a look at this documentation.
i have a bitbucket classic build pipeline and i need to have the ability to set the build clean option at queue time. it seems like this used to be possible via the Build.Clean variable but that has since been deprecated.
When editing a build pipeline the Clean option uses an editable drop down but anytime you try and type something, it erases what you just wrote. i would like to set this option to a variable like $(CleanBuild)
Assign build clean option at queue time
Indeed, the variable Build.Clean is already deprecated. But the document Use predefined variables provided another variable Build.Repository.Clean, which will help us to clean the Sources:
Besides, if you want to clean other options fields, like All build directories:
I do not believe there is a way to assign the clean options at queue-time. Even if we use deprecated Build.Clean variable, we still can clear Sources only.
You could check the similar thread for some more details.
Hope this helps.
I have a release pipeline with a variable, but there doesn't seem to be any way to set the value of that variable to something that's evaluated at release time. For example, another variable.
Here's a real example:
All I want to do is set the value of MyExpressionBasedVariable to the value of MyOtherVariable.
All the docs and examples online seem to suggest it's possible, but I can't get it to work. I always end up with the literal string rather than the evaluated value.
I've tried using these different syntaxes:
$(MyOtherVariable)
$[variables['MyOtherVariable']]
${{variables['MyOtherVariable']}}
I've seen that you can define custom tasks to set variable names as part of the pipeline but this seems massively overkill.
Essentially all I want to do is rename a key vault secret to a different variable name for convention-based XML variable replacement in config files.
E.g. I have a secret called this-is-a-secret-name-which-is-a-different-naming-convention-to-my-connectionstrings but I need it in a variable called MySecret-ConnectionString.
How do I use the value of another variable in a release pipeline variable?
How do I use the value of another variable in a release pipeline variable?
As I test, what you set should be work. You can try to follow below steps to check if you still have this issue:
Create a new release pipeline without link any variable group.
Set the Variable like following:
Add a Run Inline Powershell task to output the value of the Variable:
Write-Output 'The value of MyExpressionBasedVariable is $(MyExpressionBasedVariable)'
Write-Output 'The value of $(MyOtherVariable) is $(MyOtherVariable)'
Then we could get the log:
So, what you set should be work, if this still does not work for you, then you need to make sure that the variable you describe in the question is the variable your actual test.
Besides, at this moment, the value of nested variables (like $(TestVar_$(Release.Reason))) are not yet supported in the build/release pipelines, check this thread for some details, so make sure there are no such nested variables in your project.
Hope this helps.
I'm looking through the Octopus powershell library and trying to identify a way to output all the variable names and their values used in a deployment - not the project overall, but only for a deployment.
So say I have 3 variables like the below
VariableOne Value1
VariableTwo Value2
VariableThree Value3
And I only use the first and third and want those printed with their names (VariableOne, VariableThree) and their values (Value1, Value3).
There is an option for outputting all the variables into the deployment log for debugging purposes.
Set one (or both) of the following in your project variables list:
OctopusPrintVariables True
OctopusPrintEvaluatedVariables True
I find that the latter of the two is generally sufficient.
This feature is written up at https://octopus.com/docs/how-to/debug-problems-with-octopus-variables
<TL;DR>
No. It can't.
It's something we tried as well, but Octopus Deploy has so many ways in which Variables can be used, from XPath to .config files, JsonPath to json files, direct references and inline scripts in the workflows as well as direct references in the #{var} syntax.
None of these options track which variables were actually transformed or referenced, plus, some optional expansion may actually shortcircuit.
I've asked Octopus whether they could actually extend the object model to detect the requests to the values of a variable, so we can see which values have actually been found. But that is currently not in place.
And they came back with the problem that the step scripts may actually change or override the values of variables between steps, so the value may actually change during the workflow, making tracking them even harder.
Given this command:
MSBuild.exe build.xml /p:Configuration=Live /p:UseMerge=true /p:EnableUpdateable=false
how can I form a string like this in my build script:
UseMerge=true;EnableUpdateable=true
where I might not know which properties were used at the command line.
What are you going to do with the list?
There's no built in "properties that came via the commandline" thing a la splatting in PowerShell 2.0
Remember properties can come from environment variables and/or other scripts.
Also, you stripped on of the params out in your example.
In general, if one is trying to chain to another command, one uses defaulting (Conditions on elements in PropertyGroups) and validation (Messages Conditional on presence of options) and then either create a new property or embed the params you want to pass into a string.
Here's hoping someone has a nice neat example of a more general way to do this but I doubt it.
As covered in http://www.simple-talk.com/dotnet/.net-tools/extending-msbuild/ one can dump out the parameters passed by doing /v:diag on the commandline (but that's obviously not what you're after).
Have a look in the Common.targets files - you'll find lots of cases of chaininign involving manaully building up lists to pass onto subservient tasks.