I have my automated builds working but I want to be able to go back to a specifc labeled version and build from that source. The build definition under "Process" has the item "Get Version" but this is for a specific changeset which seems fairly useless. Does anyone have any idea how I would go about doing this?
The Get Version accepts what TFS calls an versionspec which can be either a changeset or a label. To specify a label just prefix it with an L.
LMyLabel
#Dylan Smith: Is right. You can specify in the advanced Get Version parameter the label by: LmyLabel or CmyChangeset in order to queue a specific version. There are other options like date, "W" (Version last fetched to your workspace), or "T" (latest version) as well.
For more information: Building a Specific Version with Team Build 2008
During your build process, label the code (In my case I use the build number as part of the label).
Then when you want to build a specific labeled version, pass the label to the build script, get the code from the library by label, build the code, and deploy.
See http://msdn.microsoft.com/en-us/library/fx7sdeyf.aspx for how to get a labeled version.
Related
I have a custom TFS Build template that includes a procedure that runs a process that involves getting some data from a server and checking it into TFS before moving onto the main build process.
The steps are as follows:
Set build number
Run our custom script - get data, check into TFS
Initialize environment
Get sources from Team Foundation Version Control
Associate the changesets that occurred since the last good build
Compile, Test and Publish
The issue I appear to be having is that all change sets since the last successful build are included, except, the change set associated with the script run at step 2.
Does anyone know what could be going on here? my guess is that the logic that is looking for the change sets since last build is using a cut off that is set at the moment the build is requested (hence why the last change set is ignored) but this is just an uneducated guess.
Thanks in advance for your help.
Trying the steps below:
Edit your build definition and go to "Process" tab.
Enter "T" under "Get version" option.
Queue the build and check the result.
I would have two builds chained: the first build generates and check-in the files the second simply pulls them down.
I know that the AssemblyInfo class can be set to auto increment the build number as such:
[assembly: AssemblyVersion("1.0.*")]
But this works only for building the app myself (i.e. from the IDE). I use TFS to build my solution (multiple projects). The assemblies in the build drop location are all still set to version 1.0.0.0.
What is the path of least resistance for getting the build or revision number into the AssemblyVersion?
Ideally, TFS already has a $(BuildID), an auto-incrementing integer, that I use as my Build Number Format for defining my drop location...can't that just become the version build number in the AssemblyVersion and AssemblyFileVersion?
Well, gave up on native TFS. This was the closest to a configuration-only solution (no coding). The documentation on this site shows clearly how to modify your TFS server and build to use this dll to get an incrementing number in your assembly's product and file build and rev (it's a Julian date and rev).
http://tfsversioning.codeplex.com/
I think creating your own custom build activity to update the version number is the easiest way to achieve this. Here is a good post on that:
http://www.ewaldhofman.nl/post/2010/05/13/Customize-Team-Build-2010-e28093-Part-5-Increase-AssemblyVersion.aspx
We're using Team Foundation Service instead of a local TFS.
Our solution was created on Visual Studio 2012.
My problem is now that we want all assemblies to have the same version number (this part is already solved by using a CommonAssemblyInfo.cs that is linked into all projects).
The issue I'm facing right now is that we need the tfs changeset number at the last digit of the assembly version (e.g. 1.0.0.4711 where 4711 is the changeset number).
I've found several examples, but none of them worked for me.
And yes, I especially searched here on stackoverflow a lot.
I also have to admit that I've never looked into the MSBuild scripts...
Can anyone please give me a hint on how to accomplish this?
Is it for example possible to use the MSBuild Extension Pack on Team Foundation Service (not local TFS) and if, how to do that?
As always, time is my worst enemy...
Note that from 2010 Tfs employs Windows workflow for building the package the workflow calls msbuild for compiling the projects only - while its possible to pass changeset this way to msbuild its rather more hops.
Following deals with your problem, however the linked solution is more complex that needed:
Can assembly version been automatically updated with each TFS 2010 Build?
This is one of best series of tutorials on the custom build activities, the author is on stack as well i believe, one specificly about versioning
http://www.ewaldhofman.nl/post/2010/05/13/Customize-Team-Build-2010-e28093-Part-5-Increase-AssemblyVersion.aspx
In short you need a custom activity to run before compilation on source files, find all CommonAssemblyInfo.cs files, feed this list to your custom activity, it modifies the values inside with passed value of full version number or only the changeset and optionaly check in the change (probably not since your changeset will be out of sync then).
You can also take a look at https://tfsbuildextensions.codeplex.com/ set of activities there is TfsVersion activity among them, at the very least it will provide examples.
Functionality need for this should be available through Team Explorer and source control - The Custom activity assemblies and build templates usually are located in folder in your team project root - the location of this folder is defined for build controller you can change this through team explorer build section.
Changeset is available from value BuildDetail.SourceGetVersion, not sure if this was fixed/changed in 2012 however there were 2 issues about this value in 2010
Its doesnt respect GetVersion override in default build template - you will manualy need to update if override is used
When running latest build (no override) it will get the last changeset number from tfs - depending on your branches this may not be the same as 'last' changeset for the branch of build. You will either have to live with this, provide overrides for each build or implement activity that checks branch history for last changeset value and overrides it again.
It should be noted that GetVersion should be able to accept any sourcespec version - changeset, date, label etc. I havent played around with this enough to provide more details to you.
Colin Dembovsky wrote a great overview of doing version embedding using the new pre-build script setting in TFS 2013 build definitions.
The Changeset number is easily accessible within the pre-build process in the environment variable TF_BUILD_SOURCEGETVERSION. I was able to use this to embed the Changeset value in our binaries using a script based on Dembovsky's work above. (I used Perl, not powershell, so you probably don't want to see it ;-)
This approach doesn't require any changes to the build workflow which makes it a big win for me.
I've used Wintellect's solution - MSBuild-only, no TFS magic needed. I also added to the auto-generated CSharp file:
[assembly:AssemblyInformationalVersion("$(BuildNumber)")]
So I get the TFS build number.
I have a Build Definition to build a solution on my TFS.
This works well, but it always builds the latest version.
How can I force to build a specific changeset from the past?
How can I use/pass this number to the "MSBuild Arguments" to use it there for deployment?
When you queue up the build from Team Explorer, in the Parameters tab one of the Advanced arguments is get version.
Note: I think you need to specify this in the form C123 where 123 is the changeset number.
The answer to your first question is clearly what #Dylan has stated.
To your second part:
The important argument is GetVersion.
Navigate to activity "Run MSBuild for Project" within your Build Process Template, by default this has a value CommandLineArguments equal to
String.Format("/p:SkipInvalidConfigurations=true {0}", MSBuildArguments)
You can change it to something like
String.Format("/p:SkipInvalidConfigurations=true {0} /p:DeployIisAppPath=/changeset/{1}", MSBuildArguments, GetVersion)
and get where you need to go.
If you use the changeset number, then it will only make sense for CI builds, since they typically build a single changeset.
For any other kind of build, I recommend using the build ID, which is unique, and covers the case of a build that builds multiple changesets.
I'm trying to apply Label on a file, but I obtain this error because Label already exists on an old version of file:
TF203007: Cannot create the label because the version controlled item $/MyProj/MyFile.cs already exists or has been specified more than once.
I want move Label from an old version to Latest.
Is it possible?
Thanks a lot!
A very easy workaround (if it's allowed in your case) to resolve this error mesg is (especially when everybody is standing behind you to fix this issue on urgent basis):
Just change the buildnumber.txt file (The file which holds the last successful buildnumber "number" in it) and bump the number to a new value i.e. if you are getting an error that TFS>. ... can't label ... file and during that build time the build label that TFS was trying to apply (lets say) is : TFS_RELEASE_BUILD_5, then, just bump the build number to 10 or 20 or 50, i.e. the next build number your build script will generate automatically will be either 11, 21 or 51.
Problem resolved.
My case:
I created a branch "11.0" sometime 2 weeks back. On this branch, we created builds from 1 to 10. Build label was in format: TUD_COR_11.0.0.1 ..to 10.
Yesterday, I deleted 11.0 branch.
Yesterday, we had to recreate this branch again from a new source branch so what we did was:
a. deleted 11.0 branch. checked in the change so branch is gone now.
b. Deleted all the builds that were created by the build defintion and finally deleted the build definition (as other team members wanted me to create a new build definition for the new 11.0 branch (to be created from a new source branch) again from scratch. While creating the build definitions, I successfully saw the "tick" marks against labels/etc/anything related to existing build definitions were going to delete as per the Delete operation.
Now I created new 11.0 branch again from latest data from the source branch as of today.
Created the build definitions again.
Created COR build again with build label TUD_COR_11.0.0.1. Now TFS gave me the similar "error mesg" as mentioned in the thread above.
Possible resolution:
A. Delete the file "as per the build log" where TFS Label operation is failing. You can use sidekick -OR TF label command. Note: This can be time consuming as what if you delete the label from the file (OR delete this file under this label i.e. this label is not applied to this label anymore).
*NOTE: Here we are NOT deleting the file from source control. just removing the file from the label concept
B. OR just increase the buildnumber.txt .. that the build script uses to generate the build label i.e. if my buildnumber.txt (which is somewhere in the source control branch tree), it contained a value of "0" and it was creating build "1" with label: TUD_COR_11.0.0.1 (where branch is 11.0 and build series is 11.0.0.1) i.e. ... format. Now if I just change the value of this buildnumber.txt to "10" (why as that was the last build number we successfully created when we HAD 11.0 branch earlier (before we deleted it).. so I bumped the buildnumber value to 10 i.e. now if I run the build definition again (i.e. queue the build), build script will generate a new build with number: 11 i.e. with build label "TUD_COR_11.0.0.11". Problem solved in few SECONDS here. Nobody in the company raised any doubts in doing this as this was a development branch so they didn't care what build number we(SCM team) are providing to them. They just wanted a successful build.
It sounds like it is trying to apply the label to a version of that file that already has that label. If you use tf label, it will move the label if it can, so you're doing that the right way.
One thing to check is whether the version in the workspace is the version that you want to label. Otherwise, specify the versionspec (e.g. the following will label the latest version of the file regardless of what you currently have in your workspace):
tf label "$/MyProj/MyFile.cs" /version:T /server:http://tfs:8080
If you could post the tf label command line you're using it might also help.
(edit: the tf command above would work for tfs 2005 and 2008. You'll need to specify the project collection instead of server for tfs 2010).