How to I set environment variables using gitversion? - powershell

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

Related

How to read release pipeline variable and use as environment variable in Azure DevOps in Azure CLI task?

I am using one powershell task and one Azure Cli task in release pipeline of Azure DevOps.
I have some release pipeline's variables. I want to read those variables as they will be required by my script in above two tasks. I used powershell core in Azure cli task
I tried to read them in the inline script directly as $(variableName) or $env:variableName but none of the above worked.
I tried to set read the variable in Environment variables option in the task and then use in the inline scripts using $env:variableName but it also didn't work. On printing the variableName in the script using Write-Host, the value I got is $(valueName) instead of the correct value.
How to read those variables inside these scripts?
The pipeline variables can be reference in the Azure CLI inline script by using the syntax $(variableName). I tested by adding the following in a script
write-host "The variable value: $(variableName)"

Can I access Azure App Configuration inside a script called in a pipeline task?

Using Azure App Configuration I can make the variables available to the entire pipeline. However, if the following task is running a PowerShell script, called Script.ps1. Are the configs vars going to be available in that script or do I have to pass them as input to the script?
The key-values that are fetched from App Configuration are set as pipeline variables, which are accessible as environment variables. To use environment variables in your PowerShell script file you can refer to the following.
Use environment variables in PowerShell script file:
Use PowerShell task in pipeline:
The result in the pipeline:

How to set Azure DevOps pipeline variable with Powershell

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.

How to use AzureDevOps predefined variables in Bash/Powershell scripts

In an AzureDevOps pipeline, I have tasks written in Bash/Powershell script.
If I choose to use Inline scrpit, I can use predefined variables directly, such as
cd $(Build.SourcesDirectory)
However, if I choose to use a file path to call a script, I can't use predefined variable directly in the script file. I have to pass the predefined variable to an environment variable in the task definition, like in the example below, so I can use $SourceDirectoy in script.sh,
Is there a better way to call predefined variable direclty in the script?
I believe the variables are also made available to scripts, but the formatting to reference them in the script might depend on script type. Reference the documentation.
Notice that variables are also made available to scripts through
environment variables. The syntax for using these environment
variables depends on the scripting language.
The name is upper-cased, and the . is replaced with the _. This is
automatically inserted into the process environment. Here are some
examples:
Batch script: %VARIABLE_NAME%
PowerShell script: $env:VARIABLE_NAME
Bash script: $VARIABLE_NAME
Predefined variables that contain file paths are translated to the
appropriate styling (Windows style C:\foo\ versus Unix style /foo/)
based on agent host type and shell type. If you are running bash
script tasks on Windows, you should use the environment variable
method for accessing these variables rather than the pipeline variable
method to ensure you have the correct file path styling.

Is there a way to access TeamCity system properties in a Powershell script?

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