I use TeamCity as a Build Server and want to pass the revision number from
svn to my msbuild script. The reason is that I want to create a directory on
a test / staging server with this number.
I've googled with bing (and google ;)) but couldn't find a solution.
Any ideas?
As far as I know the build number is already passed to msbuild have you tried the retrive it with:
$(BUILD_NUMBER)
Another option is to use build parameters:
Configuring Build Parameters
From the page above:
.... a convenient way of passing generic or environment-specific settings into the build script.
The build parameters are automaticly append to the msbuild command line, for example:
msbuild.exe test.sln .... /property:foo=bar
The variable %build.vcs.number% contains the svn revision number.
Under command line parameters for an MSBuild runner you can pass this value.
You actually need both of the above answers to achieve what you want. You need to set you teamcity build to use %build.vcs.number% so that when you parameter BUILD_NUMBER is set to that value.
Related
I am trying to deploy specific changeset using the SourceVersion variable in the Azure pipeline with no luck. Every time it is anything other than latest build task fails with below error, but works perfectly fine for latest code (no value for SourceVersion):
[error]C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\MSBuild\Microsoft\NuGet\16.0\Microsoft.NuGet.targets(186,5):
Error : Your project does not reference ".NETFramework,Version=v4.6.1"
framework. Add a reference to ".NETFramework,Version=v4.6.1" in the
"TargetFrameworks" property of your project file and then re-run NuGet
restore.
I am not sure where to even check for the issue. Really appreciate any input.
Thanks!!
You can try to specify /p:TargetFrameworkVersion=v4.6.1 in the MSBuild Arguments column of the MSBuild task.
MSBuild lets you set properties on the command line by using the -property (or -p) switch. These global property values override property values that are set in the project file. This includes environment properties, but does not include reserved properties, which cannot be changed.
For details ,please refer to this document.
After I updated value for "Clean" under "Get Sources" to "true" and "Clean Option" to "Sources Directory", that did the trick.
I am trying to get the Source Version Changeset number from TFS. I am using a PowerShell script to add the AssemblyInformationalVersion. I have tried using $env:TF_BUILD SOURCEGETVERSION but this dosen't work it just return blank. We are using TFS 2012 with a custom build template calling the PowerShell scripts (http://www.colinsalmcorner.com/post/build-script-hooks-for-tfs-2012-builds)
I really want to keep everything within the PowerShell Script
No, this can't be achieved simply by an environment variable in a powershell script . You need to create a custom task, follow the steps below to have a try:
Get the latest changeset number in your TFS version control. You can
just get it by using TFS API. Please see this thread for
detailed information: Programmatically retrieve the latest changeset number available in a workspace
You can write another small program to modify your FileVersion field
in the .rc file be the changeset number you get in Setp1.
Or you can try the method descried by Ivan's answer in this question Versioning .NET builds
Add more similar quesitons in SO for your reference:
Getting TFS to put the changeset in the assembly version
TFS and msbuild version number with last changeset
Take control of assembly numbering during a tfs build
The answer is in the article you referred to(The Challenge 2 – Environment Variables).
When I created a script for a 2013 build to version the assemblies, I
relied on the fact that the 2013 build sets some environment variables
that you can use in your scripts.You can see I’m getting
$env:TF_BUILD_BUILDNUMBER. Well, in the 2012 workflow, these variables
aren’t set, so you have to add an activity to do it.
That's why $env:TF_BUILD SOURCEGETVERSION returns blank, so you just need to follow the steps in Challenge 2 to set it.
I have a project which I want to deploy via team city but when it builds I want to generate a number of different artifacts.
In my app.config file I have an app setting called "platform" which I want to change the value of for each artifact. For example on build I would get three artifacts, dev, test, staging which would have had the "platform" setting changed to the corresponding value.
I have created the powershell script and run it successfully outside of team city, but I have not been able to work out how to set the file directory where the app.config exists within team city.
Is there a system variable I can use to target the current builds app.config file? Or is there a different / better way that I can accomplish what I want to do?
Thanks
Or is there a different / better way that I can accomplish what I want to do?
While this sort of question can lead to an argument over which is better... Based on what you have described, I believe that Octopus Deploy would be a good fit. Octopus Deploy integrates very nicely with TeamCity, and it handles the transformation configurations that are required to allow deployment to each of your environments, i.e. Dev, Test, and Staging. You would simply configure these as Environments within your Octopus Configuration, and during installation, Octopus can modify the configuration files as required, based on variables that you define.
I would recommand to create 3 build steps inside your TeamCity configuration :
Inside the Parameters tab, you can define configuration parameters. Just define here the 3 values : ie: PlatformDev, PlatformTest, PlatformStaging
Using Visual Studio Runner
You might be using Visual Studio runner type. So, here you can add specific values from MSBuild properties:
Dev Step:
Passing the parameter Dev, and executing your code
/p:CustomPlatform="%PlatformDev%"
Test Step:
Passing the parameter Test, and executing your code.
/p:CustomPlatform="%PlatformTest%"
Staging Step:
Passing the parameter Staging, and executing your code.
/p:CustomPlatform="%PlatformStaging%"
Then, the value CustomPlatform would be accessible inside your MSBuild scripts.
Using Powershell hand-made scripts
If you are using a powershell script to run your compilation/artifact creation, you can just add this CustomPlatform as a parameter of your script, and use it directly.
Using XSLT
Another way to do this might be to use XSLT to transform you app.config file, using a specific value.
I have my build number format specified as :
$(BuildDefinitionName)_$(Year:yyyy).$(Month).$(DayOfMonth)$(Rev:.r)
This creates build Numbers in the format of "BuildDefinitionName_2015.11.11.1"
Where revision seems to be the number of times the build has run for that day.
I would like to be able to use this value in further build steps.
For example I am creating a nuget package with the nuget packager step and am using the option "Use build number to version the package"
This creates me packages similar to this "PackageName.2015.11.11.1.nupkg"
I then want to use the nuget publisher build step to publish this, but the problem is that over time you get more than one package in the package folder and the nuget publisher step uses a pattern for matching packages to publish.
ie
"PackageName.2015.11.11.1.nupkg"
"PackageName.2015.11.11.2.nupkg"
"PackageName.2015.11.11.3.nupkg"
Without being explicit about the file to publish, the publisher step will publish all these files.
I don't want this, I just want it to publish the file which matches the current build number.
So I would like to be able to set the build number parts in the pattern.
ie PackageName.$(Year:yyyy).$(Month).$(DayOfMonth)$(Rev:.r).nupkg
But it appears that these variables do not get substituted in the search path and come through as a literal match.
It seems strange that in the nuget package step it gives you the option to create packages by build number, but then does not allow you to match this in the nuget publish build step.
Nuget Packager step use PowerShell script to get the build number. The source code is here: https://github.com/Microsoft/vso-agent-tasks/blob/84746169f19b7c3e3f67c0efa1a546c4107055fa/Tasks/NugetPackager/NuGetPackager.ps1
If you do want to transfer the build number to Nuget Publish, you can add a PowerShell step in your build process to get the build version number. Refer to the build version related code in the Source Code for details.
And in the end of the PowerShell script, add code:
Write-Host "##vso[task.setvariable variable=bversion;]$NewVersion"
This code create a variable “bversion” with build version number filled. Then you can use variable $(bversion) in your Nuget Publish step.
I would suggest to do a clean checkout of the source code in each build, which will solve the problem of having old package files lying around in subsequent builds.
Otherwise there's the $(build.buildnumber) variable which contains the expanded value of the build number, but as long as you have additionally the $(BuildDefinitionName) in the build number you won't be able to use it for the file name. See here for a list of available predefined variables.
In TeamCity using their Service Message feature, one can set value to TeamCity variables from any script environment:
echo ##teamcity[foo 'booya']
If you run this in batch/Powershell, we can set TeamCity variable foo to booya.
How can I do something similar like this in Bamboo? I would like to format build number in certain way.
Thank you.
this feature is not available in bamboo. It's an open feature request.
https://jira.atlassian.com/plugins/servlet/mobile#issue/BAM-10282
I deal with this by outputting an html build info page with build artifacts. This includes bamboo number and our actual number. It also links back to bamboo site.
Hth
Av