I am using default build template with TFS 2013 and want to pass the name of the person, who initiated the build, as a variable to a post build powershell script.
I know, that there are a couple of "env:TF_BUILD..." variables, that are filled during build process, but I couldn't find a variable, that holds the "user", who triggered the build.
The variable I am looking for is suppose to be something like "$BUILD_REQUESTEDFOR".
I try to put a -user "$BUILD_REQUESTEDFOR" into section 2.5 as Post-build script arguments in a build definition, but it seems, that it wouldn't be filled or interpreted.
Is there something i have missed or is there an other way to get my problem solved.
Any help appreciated.
The predefined variable "$BUILD_REQUESTEDFOR" is only available for vNext build (TFS 2015 and later version). See Build variables for details.
For xaml build, there isn't the variable to get the current user who triggered the build within the build process. See Team Foundation Build environment variables for details.
Related
In Azure DevOps I have a Pipeline variable "package version" and I set it using 0.1.3$(Rev:.r)-alpha .
I use that variable to replace the "Version" in the .net core project file.
In the Build tasks the dotnet build give me this error:
so I assume the Pipeline variable cannot use a nested variable.
There is a nother way or a different syntax to do it?
[Edit]
The nested variables should work.
I think the error was the dotnet pack using Automatic package versioning set to "Use the build number" that contain the wrong $(rev:.r) (lowercase!).
Using a custom string for Version in the VS project file gives noise on VS (error if the file is open, warning otherwise) and now the Pipeline Build give me an error on dotnet nuget restore because of the invalid Version.
I decided to use a simple clean version, <Version>0.1.2</Version>, that I can choose and document.
Then I want to find a way to read it in the build pipeline and create a custom variable attaching the Build Revision:
0.1.2$(Rev:.r) => 0.1.2.123
That is the result I want.
I found this: https://marketplace.visualstudio.com/items?itemName=tmarkovski.projectversionasvariable
I'm using it with the default settings.
I'm using the variables it creates to compose a new variable, "package version":
and I use that in the nuget pack task:
but it does not work.
The resulting variable still contain "$(Rev:.r)" not parsed.
I'll try to use again the "Automatic package versioning" and create the build number in the Options...
[Edit 2]
Set the build version number in the Pipeline Build Options worked.
It's not the optimal solution because the Build Number is not parsed and looks awful.
[Solution]
$(Rev:.r) is not available outside Build / Options.
I used $(Build.BuildNumber) and I'm able to create a composed variable:
$(Version.MajorMinor).$(Build.BuildNumber)-alpha
Build.BuildNumber is valorized in Build/Options: $(Build.DefinitionVersion)$(Rev:.r)
Version.MajorMinor is created by the Project Version As Build Variable add-on.
I don't know how to obtain the same result without using a third party component.
I'm glad my extension helped and thanks for the nice review. If you want more control and have a little time to spend to play with PowerShell, you can easily achieve what you want in two steps, without using third party extensions.
Read and parse the .csproj file as XML
Set build variables
Here are couple of links on reading XML files and working with build variables, it's actually pretty easy.
https://www.business.com/articles/powershell-read-xml-files/
VSTS: Pass build/release variables into Powershell script task
[xml]$XmlDocument = Get-Content -Path $env:project_file
echo $XmlDocument.Project.PropertyGroup.Version
https://learn.microsoft.com/en-us/azure/devops/pipelines/process/variables?view=vsts&tabs=yaml%2Cbatch
Write-Host '##vso[task.setvariable variable=package_version;issecret=true]0.1.2.'
Note: my answer wouldn't fit in a comment, I had to post an answer.
consider the following in my powershell step:
-source "c:\builds\$(Build.BuildNumber).zip"
result is "c:\builds\20171005.1.zip"
If I try and set the following in the configuration tab of my release variables of release like this
Name=MyBuildNumber Value=$(Build.BuildNumber)
If I change my poweshell to look like this
-source "c:\builds\$(MyBuildNumber).zip"
result is "c:\builds\$(Build.BuildNumber).zip"
What am I a doing wrong here? I have tried a few different flavours of stored variables all with the same effect. Could really use some advice.
---------AS PER ANDY-MSFT----
I can confirm I am using Version 14.102.25423.0. I installed the variable extension pack.. no difference. The logs show the literal output. I am pretty sure I am using the exact same setup you are. Please check the screenshot of my definition variable and powershell syntax.
What's the exact version of TFS 2015 and the anent version do you use?
I tested on TFS 2015 Update4 (Version 14.114.26403.0, Agent.Version:1.95.4), everything works as expected.
So, please check What version of Team Foundation Server do you have, if you are using earlier version, you can try to upgrade to Update4 or later version, then try it again.
Besides, if you still want to keep your current version, you can use the VSTS Variable Tasks extension: Variable Toolbox to expand the build/release variables. (And the source code here for your reference.)
When you define a variable in the Variables screen and use other variables as value, they won't be expanded (as you may have expected). Instead the literal text is passed to the tasks in the workflow. Without this little task the following configuration won't work:
Variable Value
Build.DropLocation \\share\drops\$(Build.DefinitionName)\$(Build.BuildNumber)
By adding the Expand variable(s) task to the top of your workflow, it will take care of the expansion, so any task below it will receive the value you're after.
PS: The new agent (version 2.x) auto-expands variables now.
And this similar thread for your reference:
TFS 2015 Can build variables access other build variables?
UPDATE:
Based on your TFS version, it should be TFS 2015 update3 (You can upgrade to Update4 or later version if that's an option, also upgrade the build Agent accordingly). To check the agent version : Go Manager Server (gear icon) >> AgentPool >> Select a pool >> select an agent >> Switch to Capabilities, you will see the agent version in that page.
I'm changing the build number of the TeamCity (9.1.4) build with service messages (Build Script Interaction) like this in Powershell:
Write-Host "##teamcity[buildNumber '$version.$arg2']"
This is working absolutely fine.
The problem is that the AssemblyInfoPatcher doesn't want to use this updated build number.
So I tried to use a variable/parameter for it but this also doesn't work.
I defined the following variable "Major.Minor.Patch" as a "Configuration Parameter" or as an "Environment Variables". The AssemblyInfoPatcher is using these variables just fine and changes the file version of my files with the version defined in TeamCity in the build.
If I try to change the variable/parameter with a service message it doesn't work. The AssemblyInfoPatcher is still using the old value.
Example with environment variable
Write-Host "##teamcity[setParameter name='env.Major.Minor.Patch' value='$version']"
Example with configuration parameter
Write-Host "##teamcity[setParameter name='Major.Minor.Patch' value='$version']"
Am I doing something wrong or is it just not possible? The only thing I want is that my files have the same version number as my TeamCity build...
The AsssemblyInfoPatcher runs before any of the build steps (and then runs again to revert your AssemblyInfo files after all your build steps). Thus, if one of your build steps sets Major.Minor.Patch using a service message, it's really too late to the game.
Maybe you could string multiple build configs together. The first config (A) would set up the parameter like you're doing now, and then trigger the second config (B), which would use the AssemblyInfoPatcher. B would have a snapshot dependency on A (in addition to the finish-build trigger) and thus its AssemblyInfoPatcher would be able to refer to %dep.A.Major.Minor.Patch%. This parameter, of course, would already be available when B's AssemblyInfoPatcher runs.
In TFS post build script of a .proj file I want to find whether the project build is happening through TFS triggered build or manually triggered build.
Can someone suggest me how to do this using macros in Post Build event.
Short answer: you can make use of the IsDesktopBuild MSBUILD property within your csproj file to differentiate between TFS and local build.
Long Answer:
Developer or Team Build?
To differentiate the build environments we have to implement a mechanism that detects in which environment the build is being executed. In other words, we need to know if we running a local build that is executed by the developer or a team build running on the build server.
In fact, there are 3 different build environments we need to consider:
· Visual Studio Build – a build executed by a developer, on their own development machine inside the Visual Studio IDE
· Team Build – a build executed by TFS (manually or scheduled), on the build.
· Desktop Build – a build explicitly executed manually, on the development workstation using the command 'msbuild.exe tfsbuild.proj'.
A ‘DesktopBuild’ and a ‘TeamBuild’ are very similar in nature except that ‘DesktopBuild’ does not perform a ‘GetLatest’ function from source repository, will not ‘Label’ the source tree and will not determine the change set.
When using MSBUILD tasks (as we will use primarily in following sections), one common way to achieve this is to use the ‘IsDesktopBuild’ and ‘BuildingSolutionFile’ properties as conditions to test in the tasks.The ‘IsDesktopBuild’ property is declared in the ‘Microsoft.TeamFoundationBuild.targets’. The ‘BuildingSolutionFile’ property is declared and assigned automatically by MSBUILD.
The following table lists the values of each of these properties in each of the build environments.
Environment IsDesktopBuild BuildingSolutionFile
Visual Studio Build (empty) (empty)
Desktop Build true true
Team Build false true
One caveat with using the ‘IsDesktopBuild’ property is that it is not defined in many target files by default. This property will have an ‘empty’ value in a Visual Studio build, so we initialize it to a value of ‘true’ as the default value. Therefore we need to be explicitly define it in all MSBUILD target files where it will be tested.
We simply add the following element to all target files where we need to differentiate between a build on the development machine and a build on the build server (within the first section).
<IsDesktopBuild Condition="'$(IsDesktopBuild)' == ''">true</IsDesktopBuild>
Update: thank you #dbardakov. Starting VS 2012 we can use the property to find if the build is happening within Visual Studio:
BuildingInsideVisualStudio
MSDN SOURCE - for BuildingInsideVisualStudio
MSDN SOURCE
I am deploying web application to azure using TFS CI automated build deployment.
In our config maintain build version like 2014.05.19.1 which is $(Date).$(rev) format.
All I want to update config each time build is deployed.For that I am passing value to 'BuildVersion' parameter in template to powershell script which actually performs publishing to azure.
I tried using $(Date:yyyyMMdd)$(Rev:.r) but it is considered string as it is.
I want to get current build version just like IBuildDetail.BuildNumber
within template.
My question is how to get the build version?
If you are using Invoke Process, instead of passing value for BuildVersion parameter you can directly use 'BuildDetail.BuildNumber' in parameters for process like
String.Format("-BuildNumber ""{0}""",BuildDetail.BuildNumber)
This would give the required build number.
If your PowerShell script is being executed from your TFS build, it should have access to the environment variables specific to the TFS context of the build. If that is the case, you actually don't need to pass the $(BuildVersion) parameter to the script, as it already is accessible to the PS script in the $env:TF_BUILD_BUILDNUMBER environment variable. Try testing something like $env:TF_BUILD_BUILDNUMBER | Out-File "D:\Dev\BuildNumber.txt" in your script. You should hopefully see the file containing your build number after running your build.
(I am assuming you are using a relatively new build process template...one that contains the "Post-Build script path" parameter, such as TfvcTemplate.12.xaml)
Hope this is helpful.
I would recommend that you use the right tool for the right job. The build system, is really only for building (compile & test). We have been using it for other things for years coz we did not have another integrated solution. However Microsoft recently bought InRelease and rebranded as Release Management for Visual Studio 2013. I have successfully integrated this with TFS 2012 as well.