I got two build definition that is mapped to some common folders. When I do check in it prompts me the selection box to pick up either of the build definition.
It gives me the option. Can I change my build definition to select the default based on what is triggered and show it as the first option without need for user to select the right one?
If you have two build definitions configured for the same source control folder then you will always get a choice. There is no way to set a default.
It is recommended to have only one gated-checkin configured to avoid confusion.
Related
We use Teamcity 2018 together with TFS.
We have one project in which the structure is following
Root <---- We want to checkout the whole Root-directory
\ProjectA <---- We want to show changes only from the sub-directory
\ProjectB
\ProjectB
We would like to watch changes from Root\ProjectA-directory and display only changes that were done under that directory.
However, we would like to checkout the whole Root-directory and run our build from there.
Is there any way to do this?
Trigger rules can help you accomplish this. Within your VCS trigger, you can specify a collection of rules to filter in or out various conditions that will cause your build configuration to trigger. These are independent of your VCS rules and those rules will handle what you choose to checkout as normal. The rule syntax is as follows:
+|-[:[user=VCS_username;][root=VCS_root_id;][comment=VCS_comment_regexp]]:Ant_like_wildcard
The Ant_like_wildcard is the element of particular interest to you in this case, as you can use them (among other things) to filter in or out a particular directory.
Here is an example from the TeamCity Documentation:
"-:lib/**" prevents the build from triggering by updates to the "lib" directory of the build sources
Using your example, your trigger rule would look something like:
+:ProjectA/**
You can use a single inclusion rather than multiple exclusions because of the way TeamCity handles those types of rules:
When specifying the rules, please note that as soon as you enter any "+" rule, TeamCity will change the implicit default from "include all" to "exclude all".
You can find the full TeamCity VCS Trigger documentation here
Our TFS 2013 admins have given us one build definition to build our solution and run all unit tests and they are not willing to create any more build definitions. We are following feature branch strategy and would like to use this build definition for our gated builds. I am trying to find how to use this one build definition with multiple branches.
I know, I can add all branches to Source settings and build them whenever a check-in is made. But I want to find out, if there is any way to add branches to Source settings, but only compile the solution that has been checked in. For example if we add 5 solutions to the Source settings, we want to compile only the solution that has changed rather than all 5 solutions.
You will need to setup an incremental build that only builds the solutions that have changed.
Ideally you will want to setup a build for every branch. You would still use the one build template given to you, but you would define the work-spaces and behavior differently for each branch depending on your needs. However if you do not have that option you can still implement what you are trying to do.
For example if you only want to build the solution that has changed you will set up your build to be an incremental build like the following:
In the "Process" tab update the "Items to build" section to any *.sln or *.*proj
In the "Workspace" section, select only the source control paths of each branch if setting up a build for every branch or select the entire source if that is how you have to do it ($/).
Change the build to an incremental build by changing the Build Process Parameters on the "Process" tab - CleanWorkspace=None
Tag one of the build agents, so that it is the only one used for these incremental builds. Set the build to only use this tagged agent. It is important that the same build agent or set of agents is used for the builds if incremental builds are to work.
In the TFS 2010 build definition window, under “Process” there are two required items. They are “Configurations to build” and “Projects to build”. Under projects to build, it will allow me to enter something like:
$/TeamProject/Area1/Area2/*
However, this doesn’t seem to do what I expect. The build fails because it’s looking for:
$/TeamProject/Area1/Area2/Sources/*
What I am trying to achieve by this is to build all the solutions held under this area. For example, I have:
$/TeamProject/Area1/Area2/Solution1/Solution1.sln
$/TeamProject/Area1/Area2/Solution2/Solution2.sln
$/TeamProject/Area1/Area2/Solution3/Solution3.sln
There are many more solutions than this, which is why I’m looking for a way to build all solutions under the specified path recursively. Is there a way to do this in TFS 2010?
You can modify the process template. Expand it with the Matching files (I don't have the exact naming now) activity. Add a parameter that passes the information you set in the build defintion to the MachingFiles actvity. Then pass into the build solution activity instead of the argument that you enter in the build definition the files that is found by the MatchingFiles activity.
Now add a dummy solution in the build definition for the solution to build (it is not used anymore).
See the blog post series on the build customization for more information on customizing the build process template.
FWIW,
I've got: "configurations to build" blank
and under "projects to build" I've added my solutions via the ellipsis button
I would setup mappings for
$/TeamProject/Area1/Area2/Solution1/
$/TeamProject/Area1/Area2/Solution2/
$/TeamProject/Area1/Area2/Solution3/
Then in the build definitions enter the three projects to build
$/TeamProject/Area1/Area2/Solution1/Solution1.sln
$/TeamProject/Area1/Area2/Solution2/Solution2.sln
$/TeamProject/Area1/Area2/Solution3/Solution3.sln
You can leave the configurations to build as blank, or if you want to do a certain build you can set it to (for example) something like Debug|Mixed Platforms (check your Configuration Manager... for the solutions you are building to see what is valid)
Alternatively, you can just map the following (depending on how much you have in this folder, if you have Solutions 4+ that you don't want to trigger builds on, don't do it at this level)
$/TeamProject/Area1/Area2
And have one solution which contains the Solution1, Solution2 and Solution3, and build that instead.
By default building your Solution1 which is mapped to
$/TeamProject/Area1/Area2
On a build agent with a working directory that is going to looks something like:
$(SystemDrive)\Builds\$(BuildAgentId)\$(BuildDefinitionPath)
You'll end up with it being build under
C:\Builds\1\Solution1\Binaries
C:\Builds\1\Solution1\Sources
C:\Builds\1\Solution1\TestResults
Which is why you want to make sure that your OutDir's etc are all correct and not hard coded!
If you have a look while building, you'll see the build agent populating the Sources folder, and it should (if configured correctly) put all outputs into the Binaries folder (and then copy them to the Drop Folder configured under Build Defaults in TFS.
Does TFS offer a way to save, track, and later redeploy builds by build number, or can you only deploy .dlls compiled from the current codebase? I'm looking for functionality similar to what you find in Changeman DS.
Yes. Every build definition in Team Build has a "retention policy" that defines how many historical builds should be kept, depending on certain criteria. You can also mark individual builds as "keep indefinitely." Kind of like a Tivo...
Example walkthru with screenshots: http://blogs.msdn.com/buckh/archive/2007/08/14/tfs-2008-a-basic-guide-to-team-build-2008.aspx
If you need to recover a build that has already been deleted from the drop share, you can do that too -- you'll just have to rebuild it. Simply queue up the build definition, but before you hit Go, type /p:GetVersion="XXX" in the text area at the bottom labeled "additional MSBuild arguments." XXX can be any versionspec, just like you'd use at the tf.exe command line. Examples might be "C12345" or "D1/10/2010" or "LsomeLabel".
Does anybody know how can I configure TFS Build to build a set of projects in a solution instead?
The solution I have, has 16 projects but for one of my build definitions I want some of them to be compiled.
The easiest way in my opinion is to create a new solution file. There is nothing stopping you from having several solutions that reference the same projects (or some subset).
The other way is to create a new configuration. In Solution Explorer, rightclick the root node -> Configuration Manager. In addition to standard configs like "debug" or "release" you can create your own custom ones. For each combination of config + platform, you can use the checkboxes below to define which projects will be built and what settings they'll use.
Whatever you choose, you'd edit your TFSBuild.proj file to point to the desired solution and/or configuration. MSDN instructions: http://msdn.microsoft.com/en-us/library/bb399127.aspx
Once you create your build it will make a TFSBuild.proj file in source control (you can right click on the build in Team Explorer and select Configuration Folder to find it.
Open this file and find the tag that has "SolutionToBuild". That tag has sub tags for specifying targets. I think if you enter the projects you want to build in there (semicolon delimited) then it will just build those.
If you have not made your build yet then (as John Saunders said) you can specify the projects in the setup of the build. (After you have set it up you cannot do that again.