We have lots of feature branches, and we don't want to manually create a build definition for each of them for continuous integration.
Is it possible to create one build definition in TFS Build 2015 that will build solution from the branch when code is checked in to it? We are using TFVC for source control.
Preferably, only the active branches should be downloaded to the build agent, as we have a lot of old branches that don't get any check-ins.
There is a similar question about old TFS Build system, but since build system was completely changed in TFS 2015, the answer would be different too - TFS build, one build for many branches
Short answer: No.
This works for Git, not for TFVC, unfortunately.
Actually, it would appear to work out of the box with TFS 2015 Update 2, according to a test I just ran with the following simple structure...
$/Project
$/Project/Product1/Solution1/
$/Project/Product1/Solution1/solution1.sln
: (and everything below it)
$/Project/Product1/Solution1-branch/solution1.sln
: (and everything branched below it)
$/Project/Product1/Feature2/another-solution1.sln
: (and everything below it)
Build settings:
Build tab | Solution should be "**\*.sln", Repository tab | Repository should be "Project" and Mappings should include "$/Project/Product1/".
The ** in the Solution field causes it to search recursively for *.sln files, which it then builds in sequence.
I just tried this and it built all branches one after the other.
Excluding "old" branches might be more difficult if you use the single recursive approach, but you could always simply list the desired branches in the Mappings area - the nett result should be the same.
Hope that helps.
If I understand your question, this might work for you.
This will build all feature branches, plus the develop (default) branch as part of CI.
Not sure why, but if you reverse the order of these it does not work.
Related
Our builds generally have a mish mash of work items and commits associated with them and I cannot tell how TFS determines what to add. We are using TFS 2015 update 3 and TFVC.
When a build runs, it gets code from a location somewhere in the branching and folder of TFVC. Typically, something like "root\dev\src\component name" in this way we avoid getting all of the code in our repository and we have CI set up to run so that any changes in this folder will result in a CI build running.
We also run daily builds which run more tests and create a release package that is used by TFS Release Management. I would expect that any changes to code inside of the folder defined in setting up the repository for this build to be included in the associated change-sets of a build. I also expect that any changes checked-in outside of these branches would not be associated. But this is not the case. We see commits from across the entire project.
Does anyone know how this is supposed to work?
I am not sure if this should go in the question or the answer but I have found some additional information, thanks to the hints provided in the answers below.
It appears that the source settings will take the common root between mapped folders of the repository settings, so if I have 2 folders $/Relo/Dev/B1/src/Claims.Services and $/Relo/Dev/B1/src/PSScripts it will take the common root $/Relo/Dev/B1/src as the source settings and include any changes from that folder down within the build. Can anyone confirm this? Of course thats not what I want to have happen. In the History tab of the build definition if I looked at the diff I can see a field "defaultBranch" in the json which seems to be the value that controls this, is there any way to update this field directly?
TFS determines what changesets should be mapped to a build based on the Source Repository Mappings (Build vNext) in the build definition and the last successful build.
So, you will see a list of the changesets with files committed in the lowest common base of any of the mapped folders including all their descendents, since the latest successful build. Whenever you get a successful build (I hope that it happens more often than failing ones ;-)) the list will shorten and only show the last check-in.
Example mappings below will result in any changeset made to anything below $/Relo/Dev/B1/src (because it is the lowest common base):
$/Relo/Dev/B1/src/Claims.Services
$/Relo/Dev/B1/src/PSScripts
Similar it will pick up all the related work items to the above changesets.
This is what should happen. If you see something else, I would have a closer look at the Repository Mappings or Source Settings of the build definition.
#Noel - I guess you are using vNext build and not XAML builds. Or are you using a mix of XAML and vNext?
In general a scheduled TFS build will associate all changes which were not associated in the last successful run of the same build.
I suggest you check once again if the source folder locations are the same for CI build and Daily build?
We use TFS source control and have two build controllers (one VS2010 the other VS2012). We use the default build workflow template bar a few custom changes.
As we have many branches, how would we go about changing the workspace based on the desired branch?
I was thinking of adding a parameter for the branch ($\oursourcecontrol\branches\main) and then just passing it as a variable in to the get workspace part of the workflow.
Or is there a better way of doing it?
You currently can't and it is really a shame. It would completely break the Trigger support for CI and Gates checkins. You can use the TFS Community Build Manager to quickly clone and adjust build definitions to support multiple branches though.
What you could do, is to fetch more than you need (say $/Sourcecontrol/Branches/*) and then use a string-replace on any path parameter (like solutions to build, test settings file etc) to point them all to the correct solution. You'll probably need to do some templating like {BRANCH} so that you can easily replace these tokens.
The Git build template does support this on a Git repository, but you'd need TFS 2013 to make use of server side Git support.
I mapped the server path in the Repository tab at higher level that TFS branches are contained. Cloak rest of the branches not required for Get sources step except the branch to be built. And create variable to pass the branch name, check allow at queue time. Use this branch variable in build steps to make the build definition work for all the branches. You may need more than one variable based on your branches structure in TFS.
At my work, we have a number of separate TFS projects that are combined together to form our Visual Studio solutions. These separate TFS projects are maintained so that we can reuse code across multiple solutions. Admittedly, this was a bad idea, as now when we have to branch we must branch each TFS project individually (we even wrote an app to do this). We end up with a project structure that looks like this:
$/Production/[superproject]/MAIN
$/Production/[superproject]/dev/[branch]
$/Production/[dependency1]/MAIN
$/Production/[dependency1]/dev/[branch/
where [superproject] requires [dependency1] within the solution. We end up mapping all these projects to the same workspace.
I would like to use Git-TFS in order to use Git in my day-to-day development. So far, the best way I have found to do this is to have a "master" git repo with a submodule for each TFS project. This way I can branch, diff, etc by using git submodule foreach.
Unfortunately, our policy regarding checkins is to have one changeset for a task, even if the changeset spans multiple TFS projects. This is fine if all my changes are constrained to one TFS project (i.e. one git submodule), but when I have changes across multiple submodules for one task then I don't know what to do. My current plan is to shelve each individualy using git submodule foreach 'git-tfs shelve mytask_$name' and then pull each into my TFS workspace, checking in from there. That only works for whatever TFS branches I have already mapped, which defeats half the purpose of using Git in the first place.
Has anyone encountered a similar problem? Are there any solutions already out there, perhaps using the TFS command line & a script? If not, I suppose I will spend some time creating a pull request for git-tfs. I am open to using Git-TF if the problem is solved there.
Thank you all in advance.
I think there is an effort in this way here : https://github.com/git-tfs/git-tfs/pull/350
you could have a look and contribute ;)
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.
Here is my situation.
I setup a build definition for continuous integration using the new workflow system. Then I targeted this definition to a particular solution. I checked-in my solution many times without a problem and the builds have all passed flawlessly on the server.
This morning, I notice that it has been executed but I did not checked-in the solution. I finally discover that when a colleague checked-in another solution, it executed the definition for the solution I am working on.
I am using the original ProcessTemplate.xaml file. I only want this build definition to be executed when I check-in a particular solution or a set of solution I chose. What do I miss here?
Thanks.
There are two things you need to do,
1. Edit build defination and click on the process tab, change the 'Items to Build' to the solution that you are interested to be build as part of your build.
2. Click on the workspace tab and point it only to the branch or specifically to the folder which logically excludes the solutions that you would like to exlude from this ci build.
Make sure you carry these steps across your build definations.
HTH.
Cheers, Tarun