I am using a pipeline variable to define a path for a deploy script. There is the danger that someone forgets to define the variable. What would be a good way to detect this and give the appropriate error message in the yaml script file?
I could create a PowerShell script that would fail if the variable is not defined. But I would prefer to keep it all in the yaml file.
The PowerShell script to examine the variable value can be tiny and can still live in the YAML as the inline script of the PowerShell task:
- powershell: if (!$env:MyVar) Write-Error "The variable is not set"
displayName: Check Prerequisite Variable
failOnStderr: true
errorActionPreference: stop
I might be mistaken on syntax, but it describes the idea.
Related
I currently have a variable in my release pipeline and need to set its value through a Powershell script. The purpose is to have its value available to be used for postman collections in next tasks.
I'm trying to do that in this way but not working.
$content = Get-Content -Path .\token.txt
Write-Host "RP token found: $content"
Write-Host "##vso[task.setvariable variable=readingProgressToken;]$content"
Write-Host "Variable value in pipeline: $(readingProgressToken)"
And this is the variable
variable
Using the set variable command will make the variable available for all the task steps that follow. It will not be available within the scope of the same task. If you break your task into two steps, one set then one test display, I'd expect you would see the setting is probably going to be as-expected for your postman step.
From the documentation:
To set a variable from a script, use the task.setvariable logging
command. This doesn't update the environment variables, but it does
make the new variable available to downstream steps within the same
job.
In the script task (PowerShell, Bash, etc..), if you use the logging command SetVariable to create or update a variable with the specified value, this variable with the new value is only available to the subsequent tasks in the same job.
For the script task which runs the SetVariable command, the new value is not available.
So, if you want to print the new value of the variable, you should print it in another task after the script task.
I have Azure DevOps release pipeline job having 4 tasks inside it.
I would like to set the environment variable in the first task and to use that value as input to the second task for parameter: Display name.
We can assume all 4 steps are PowerShell scripts.
Task 1 Powershell:
Write-Host "##vso[task.setvariable variable=myvariable;]abcdefg"
Task 2 Powershell:
PowerShell inside task 2:
Write-Host "$(myvariable)"
How could I set a variable in task 1 and access it as an input variable to task2?
My output was:
Task2 - $(myvariable) as display name
but PowerShell script itself output was:
abcdefg
Write-Host "##vso[task.setvariable variable=myvariable;]abcdefg"
That's because the variable this script created is not a pre-defined variable.
As the execution logic, after you queue the pipeline, you can see that the pipeline name, task name are displayed firstly, even though the script does not be executed. So, if these names are using variable to define them, the variable just can get the value from the pre-defined variable. Because the compile of variable value get in pipeline/task name are always firstly than the script executed.
In addition, the script in task just create a script variable, and this script variable only live for the lifetime of the Phase and are destroyed after execution.
How could I set a variable in task 1 and access it as an input
variable to task2?
As you what want, if get it in another script, just use $(xxx) or $env:xxx. But, for name, $() just can get the pre-defined variable value, instead of the script variable value.
I'm dealing with a very weird anomaly in Jenkins that makes absolutely no sense to me. Essentially Jenkins is behaving differently for a powershell command than for a batch command.
My goal is to pass an environment variable (or parameter) from one Jenkins Job to another. However this variable to be passed is generated during the runtime of the first job.
I made a fake project to test passing variables and I was able to do so by adding a build step to echo out the variable into an env.props file on the node and then used the parameterized trigger plugin to call the next job. I was able to get this to work great in this test scenario but when I tried to implement the same steps in the actual build job (which relies on powershell scripts) it did not work.
After, a lot of trial and error I have found that when I use a windows batch command to echo the variable into a props file and then inject the variable into the job - it works perfect. But when I do the exact same thing with a powershell command it does not inject the variable back in to the job even though I use the exact same line of code. It still writes the variable to the file but Jenkins will not "reinject" this variable back into the job's env variable even though I am using the exact same step to do so.
The command is essentially this:
echo Testvar=Somevalue > C:\Jenkins\env.props
Both sucesffuly write the string to the props file, but when done with a powershell command, Jenkins will not absorb the txt from the run. Almost as if powershell is encoding it in a way that Jenkins cannot read but looks the exact same to me.
Any ideas?
Turns out, it was the encoding!
echo "string" > file.txt
does not produce the same result in batch as powershell.
Switching to
echo "string" | out-file -encoding ASCII file.txt
did the trick.
I am trying gitversion /output buildserver in both powershell and command prompt and neither modify the environment variables with GitVersion.SemVer (for example). How can I use it in a script?
According to the documentation:
By default GitVersion returns a json object to stdout containing all the variables which GitVersion generates.
So if you want to run it as part of a standalone script rather than a build task, just grab the json output from stdout and convert it to an object:
$GitVersion = gitversion |ConvertFrom-Json
$GitVersion.SemVer
I'm trying to set up a new build configuration in TeamCity using the Powershell runner. However, I can't seem to find a way to access the TeamCity System Properties in the build script. I've seen hints that it is possible, but cannot find documentation on how to do it.
I have tried accessing the system properties using Powershell variable syntax, $variable. I have also printed out all variables in memory and see no teamcity variables to use.
Is this possible with the Powershell runner, and if so what is the syntax necessary to get it working?
TeamCity will set up environment variables, such as build.number (you can see a list of these within TeamCity).
In Powershell you can access environment variables using the env "provider", e.g.
$env:PATH
TeamCity variables are accessible by replacing the . with a _, so the build.number variable can be accessed as
$env:build_number
As it says in the TeamCity documentation, the system parameters are passed to the build script runner, but not all build script runners know what to do with them. In the case of the Powershell script runner, when using a script file, they don't propagate down to your scripts.
It's occurred to me to write a psake-optimized build runner that does, but in the meantime you can do one of the following:
explicitly map any of the TeamCity build properties to script parameters using the parameter expansion that's available within the Script Source box. eg .\build.ps1 -someParam:%build.name%
use environment parameters, which can be accessed explicitly within PowerShell using $env:NAME_IN_TEAMCITY syntax, eg $env:TEAMCITY_VERSION, or looped over and pushed into variable scope
access the build properties file that TeamCity makes available during the build. The file is available at $env:TEAMCITY_BUILD_PROPERTIES_FILE, and if you load the XML version it's fairly easy to loop through and push them all into scope (though you do get everything as a string of course). I posted a gist on how to do this (https://gist.github.com/piers7/6432985). Or, if using Psake, modify the script above to return you a hashtable which you can pass directly to Psake's -properties argument.
It is posible. Here is example how to pass system properties into PSake script:
& .\psake.ps1 -parameters #{build_number=%build.number%; personal_build=%build.is.personal%}
If you don't use Psake, you can define your variables like this:
$build_number = %build.number%
The %build.number% part will be replaced with TeamCity provided data. I think, it works only in Source code script input mode.
I created a meta-runner that will pass through System parameters to parameters declared in the Powershell script. It's not perfect (if you put '# in your source it will break) but it works for what I needed, you can find it here: https://gist.github.com/anonymous/ef60ada3f48f0fb25093