I need to pull from a specific label in TFS and then build it in TeamCity. Is there any way to do this? I've done it before in SVN with custom steps, I was trying to avoid this. I assume a custom step like the below would work, but wanted to avoid it if possible.
Any ideas? Maybe a way through the fetch URL or appended to the collection URL that I don't know about.
tf get * /r /version:Lyourlabelname
See https://youtrack.jetbrains.com/issue/TW-7370
You can run a build on a specified change[set] manually using Run
Custom Build dialog.
Edit:
Another way is to run tf.exe using the Get command.
See https://msdn.microsoft.com/en-us/library/fx7sdeyf.aspx
Synchronize a workspace to match a labeled version of the team’s codebase
c:\code\SiteApp\Main>tf get /v:LLastKnownGood
Synchronizes the workspace to match the items in the codebase that are labeled LastKnownGood
Edit 2
Also see https://teamcity-support.jetbrains.com/hc/en-us/community/posts/207091635-Checkout-TFS-Label
TeamCity does not support getting labeled sources at this time. The feature request is addressed by TW-5061, please vote for it.
Related
We are using TeamCity 9.x as are main CI server. I'm looking for ways to run a script (PowerShell, Python, ...) when a build is tagged. Is this possible?
The only thing I can think of is to write a simple service which polls the REST API for the last x builds and reads the <tag/> information.
We are using TFS for source control, so labeling the sources is not an option (because a label is unique in TFS).
Are there any other (simpler) ways to do this? Or is there any other way to define build quality and execute something?
Yes you can
In the build trigger definition, you can mention specific subset of tags(using regex patterns) on which teamcity targets are trigeered. In your case, you have to set the triggers to run on tags only
I know this doesn't answer your question but figured I'd mention it anyways since you have TFS in your environment already.
If you were using TFS Build it has a drop down on each build to indicate quality. And there's a free tool called TFS Deployer that allows you to run scripts when the quality is changed.
I'm trying to write a very lightweight "build" script which will basically just get a few files from TF (based on a Changeset number). Then I'll run those files in SQLCMD.
I'm using this:
tf.exe get c:\tfs\ /version:c2681 /force /recursive
However, this appears to get EVERYTHING, not just the files in changeset #2681. I'd like to be able to point it to the root of my tfs workspace, give it a changeset number, and have it just update those few specific files. Also, it appears to be getting older versions (perhaps what was current when changeset #2681 was checked in)?
Is there a way to get just those specific files, WITHOUT needing to call them out specifically in the tf get itemspec?
EDIT: I actually had to add the /force option in order for it to do anything at all. Without force, it doesn't appear to even retrieve from the server a file I deleted locally, that's definitely in the changeset.
thanks,
Sylvia
Everything mentioned in Jason's and Richard's posts above is correct but I would like to add one thing that may help you. The TFS team ships a set of useful tools separate from VS known as the "Team Foundation Power Tools". One of the Power Tools is an additional command line utility known as tfpt.exe. tfpt.exe contains a "getcs" command which is equivalent to "get changeset" which seems to be exactly what you are looking for.
If you have VS 2010, then you can download the tools here. If you have an older version, a bing :) search should help you find the correct version of the tools. If you want to read more about the getcs command, check out Buck Hodges's post here.
The TFS server keeps track of what each workspace contains1. Any changes made locally with non-TFS client commands (whether tf.exe, Team Explorer or another client) will lead to differences between the TFS Server's view and what actually exist.
The force options on the various clients just gets everything removing such inconsistencies (effectively resetting both what is on the client and what the server thinks is there).
When you perform a get against a specified version (whether date, changeset or label) you get everything up to and including that point in time, whether on not specifically changed at that point. So getting
tf get /version:D2012-03-30
will get changes made on or before that date.
To get only the items included in a changeset you'll have to do some work yourself, using a command to get a listing of the content of a changeset and parse that to perform the right actions (a changeset can include more than just updates and adds of files2).
It seems to me that if you want to perform a build at each changeset affecting a particular TFS folder you would be better off looking at using TFS Build which is all about doing exactly that – avoid reinventing the wheel – and focus on the build part (other continuous build solutions are available).
1 This will change with TFS11 local workspaces.
2 Eg. handing the rename of a folder will take some non-trivial work.
The command will get all the sources for the given changeset. By default it will only get the files that it thinks are different between your workspace and the server. However, by using the /force option you are asking it to get everything regardless of the state it thinks your workspace is in (which is much slower but has the benefit of ensuring your workspace is fully in sync with the server).
So just removing /force will probably achieve what you want.
edit
As I said above, tfs will get all files that it thinks are different from the server. If you manually delete a file from your local workspace, TFS won't know that it is missing from your local version, so it won't think it needs to update the file. There are three solutions to this:
Use /force to make sure things are in sync, and put up with it being very slow.
Don't modify files in your workspace with anything other than TFS tools (tf.exe, Visual Studio, TFS power tool for the explorer shell). You shouldn't just delete files on your local hard drive - if they really need to be deleted, then delete them in source control.
Go offline in TFS before you make changes manually. Then when you go online, TFS will search for all the changes you have made and add them to your pending changes so that TFS is aware of them.
Currently we are using StarTeam to perform the build as well as versioning. we planned to migrate startteam to TFS2010. We have some script for perform the build. i wanted to change this script according to my requirement. i gone through the TFS but i had lot more confusion.
in StarTeam, we will get a files from "Ready to Build" label and perform the build. In TFS, how we are going to get a files from TFS? What concept should i use to get a files and perform the build? i have gone through the lot of commands like get, check-in, checkout etc..
If we use "tf get" command, we can get all the files from TFS but i have a clarification on that. shall i get all the files from TFS for every build? i hope, this is unnecessary headache.. correct me if i am wrong..
how we perform the build in TFS? i have read some types of build such as manual, gatedcheckin, Continuous Integration and schedule.
Is there any relationship between branch and build activities?
In TFS, What is the meaning of Workspace?
As said, many questions in one. Hope this helps along the way:
A workspace is a mapping between the server and a local storage,
similar to checkout in Subversion, view in ClearCase, etc.
"TF get" normally only fetches those files that have changed since
last update. You can force it to fetch everything - and sometimes
have to - but its not normally done.
Team Build is the recommended system to build with when using TFS. It can take some time to get into (Windows Workflow-based), but is quite powerful. There are default process definitions that set up the most common actions for you.
By default, you can't control whether to build by setting a certain label, but you can define that only this label should be used when builds are triggered. Labels in TFS work a little differently compared to other VCS, though, so maybe there's an 'opportunity' to re-think your build process along the way. If you're set on using a label as before, you'll need to build a Custom build activity.
I know that the short answer is "you can't". Desktop builds are no longer a part of TFS 2010.
However, I figure that I can somehow, if I install a build agent on my machine, and direct the WF to not get the latest version or a shelveset, and use the existing workspace, I should be able to fake it.
The problem is that between the theory and practice is a large gap in my knowledge. Can anyone think of a way this could work?
What is it, exactly, that you're trying to accomplish? Why not just setup a build agent on your machine and configure an incremental build to run on it? You could pass shelvesets into it via the Queue Build dialog or use a separate branch to keep your sources separate from the rest of your teams.
I finally came up with a solution:
A client that wants to build locally (i.e. desktop-builds) needs to install a Build Controller and Build Agent on his desktop machine. Then he needs to pick that controller for the build.
In the build template, the Get activity needs to be deleted, and the Create Workspace activity needs to be replaced with a Get Workspace, to use an existing one.
Finally, remove the command to copy to a drop folder. You're building locally. Not necessary.
Assaf
I've seen the question related to the error message you get from TFS when a workspace is already mapped. The accepted answer for removing the workspace is alright as a workaround, but it's already getting tedious to run a delete command each time this error occurs.
What do I need to change in order to get out of having to use this workaround? I've got two builds (continuous integration and nightly deploy), and need to add at least one more build type. I followed this URL to see if there was a possible resolution there, but I'm not sure I understand it completely.
I am not sure how this is accomplished in TFS 2010, as I have not gotten to work with Team Build in 2010, yet. In 2008, though, if you expand the Builds node in the Team Project and right-right click on either of the builds, you will see a "Manage Build Agents..." option. Click into that, and it will bring up a dialog. One of the things on that dialog is an option called "Working Directory". Do you have the same hard-coded path in both of them?
By default, when you create a new build definition, it provides a calculated folder for this value. This is where the build agent will do the checkout from TFS for the build attempt. The default value is, $(Temp)\$(BuildDefinitionPath), I believe (I am not connected to TFS at the moment).
The article you link to is basically saying that you should include either that $(BuildDefinitionPath) value or the $(BuildDefinitionID) value as part of that path in that dialog so that the two builds do not try to use the same workspace. Changing the working folder to include one of those values should resolve your issue, going forward.