I met a problem about build definition.
Now there are almost 50 Gated build definiton.
Every sprint we will create a branch after we release a version.
We still want to add the GATED mechnism on branch, So there will be >100 build definitions in the list.
It is too many build definitions.
Is there a may to make some folders and put them in different categories(trunk , branchs) in the list?
Depends on what version of TFS you are using.
For TFS 2010, there's an addon you can install called Inmeta.VisualStudio.TeamExplorer.BuildExplorer. It allows you to "build" a treeview of your build definitions based on a chosen separator character (default is ".").
I haven't seen anything like that for TFS 2012, but in there you can select favorite build definitions, and also filter the list of definitions.
Related
We've been using TFS 2015 for a few years. I've got TFS 2018 installed on a test server and am experimenting with it. I want to make a new build definition to a project I have in an TFVC repo, in TFS 2018. So, creating a new definition I have selected the source as TFVC. Next it asks for a Workspace mappings, which I'm not clear as to what that is in this case. It defaults to the team project in the TFS repo, in this case it's $/RodTest. However, I don't want to choose that, because there are several projects within the RodTest team project. Instead I want to only create a build definition for one project named FindNonAscii. So, I figured I could do one of two things:
$/RodTest/FindNonAscii
$/RodTest/FindNonAscii/FindNonAscii.sln
Which is the correct mapping I should use?
Mappings are recursive. Map the root folder and anything underneath will be downloaded.
Motivation
PreBuild to disable compilation of redundant projects for faster compilation cycle.
Background
I have a VS15 ALL solution that contains many projects.
I have a single project, PreBuild, that all the other projects are dependent on, meaning, this PreBuild compiles first.
In addition, we also have a PostBuild project that do some more work once binaries are ready.
All projects are configured to build in Release mode (which is desired).
When a team member wants to release some binaries, he hits F7, Build Solution.
Now, the PreBuild, activates a separate dedicated process that calculates which projects should be released. The nature of the calculation is irrelevant to this discussion.
Problem
Out of the many many projects, it is often the case that only a few projects needs to be released. However, once the PreBuild process is done, ALL the projects are will compile which is very time consuming.
Question
Is it possible, after a solution build had started, to change the released projects?
Suggested unwanted approaches
A developer handpicks only the relevant projects and only build those.
PreBuild Kill & Revive. Once desired projects are calculated, PreBuild kills the VS15 process and activate a cmd compiling only the relevant projects.
Suggested approach
Change file ALL.sln and remove the the unwanted projects.
This would work had I changed that file prior to the process start but I'm not sure it would work if this change occurs during the process.
The simplest way I can think of, while still keeping most of the current infrastructure in place: have a dedicated project which invokes the release build (by calculating dependencies and invoking msbuild) and configure VS so it can be select just that project for a build. All from within your ALL.sln so the rest of the features remain. Steps:
Get rid of the PreBuild/PostBuild projects. I assume the PostBuild you mention is also meant for the actual release builds; if not just leave it there. Note by not requiring all projects to depend on the PreBuild project you already got rid of one maintainance burden.
Add one single project which will do the release building, say ReleaseBuild. Such name is also better than having PreBuild/PostBuild projects since it clearly states the intent of the project. A Makefile project is suitable, though technically it could be as simple as an msbuild file with just one Build target. Configure the build command line to do whatever is needed, i.e. figuring out what to build then build. For the sake of an example: say you use Powershell to do this you would configure the build commandline to be
Powershell -NoProfile -File BuildRelease.ps1 $(Platform)
and BuildRelease.ps1 contains something like
$projectsToRelease = CalculateMyProjectsForRelease()
$platform = $Args[0]
$projectsToRelease | %{& msbuild $_ "/p:Configuration=Release;Platform=$platform"}
In Configuration Manager add an extra Configuration called Deploy or so. This will be used to select what to build: you probably have Debug and Release configurations now already. Those stay in place, and are simply used to build everything. The idea is this extra configuration will take care of building the actual release. This is fairly consistent with the standard way of working in VS and easy to discover and understand for newcomers. Using the checkboxes, make it so that when the Deploy configuration is selected only the ReleaseBuild is built and none of the others whereas when Debug or Release is selected the ReleaseBuild project is not built. Looks like this:
To build a release, select Deploy from the configuration drop down menu in the VS toolbar and hit F7 (or whatever way you use to invoke Build Solution). Any build errors/warnings will be parsed and shown as usual in the Error List.
This is also easy to extend: suppose you only have a couple of release build versions just add more configurations like DeployA DeployB DeployC and adjust the build command line for them.
I am creating a build definition in VSTS 2015 and have a series of build steps. Based on certain Variable values I have in my build definition set at queue time how can I make it choose to preform certain Build steps.
This Build definition, builds and packages the installers of about 15 different components and each component has it's own release definition. I am trying to make it so if at queue time the variable flagging componentA is set to true it will run the build step that calls the release definition of ComponentA
I haven't been able to find any information of adding logic to run a build step based on certain values
I recently noticed I needed to reuse a build step in many projects. So I created a template where I only defined that build step, and had the projects that needed it associated with that template. That worked perfectly.
But then I realized that none of the affected projects were generating their artifacts, even though all of them were building successfully. When I went to look at the General Settings, the Artifact Paths box was grayed out and Team City told me that I could only change it inside the template!
I want my builds to have different artifact paths (some don't even generate artifacts at all), but I don't want to duplicate my build step. Is there some workaround for this?
Team City Version: 6.5.6 (build 18130)
This is how I workaround the issue:
Create a configuration parameter in the build parameters section of the template. I just call it Artifacts.
Then reference the property in the Artifacts Paths box in the template, e.g %Artifacts%
Then for each configuration which inherits the template you can override the artifacts configuration parameter with a path that is relevant.
HTH
This is an old question and apparently only affects users with TeamCity versions less than 8.1 (as pointed out in the comments to the accepted answer).
According to the offical documentation:
Since TeamCity 8.1, the following settings can now be overridden in a build configuration inherited from a template:
build number format
artifact paths
build options (hanging builds detection, status widget, number of simultaneously running builds)
VCS checkout mode
checkout directory
clean all files before build
show changes from snapshot dependencies
execution timeout
all common build failure conditions, including execution timeout
So I have main.cpp and main2.cpp with int main in each. I want to get 2 exes out of it. Is it possible and what would be instruction to create such project?
Nope, Visual Studio's project model is rigidly built around the assumption that "one project generates one output".
If you need two executables, you have to create two projects. You can keep them in the same solution to make things easier for yourself, but they have to be separate projects.
Edit
Ok, as other answers have pointed out, it can of course be done, if you're desperate. You can add a custom build step, which does anything you like, including building another executable. (However, the build system won't understand that this file should be considered project output, and so some scenarios may fail: for example the file won't be automatically copied to the output folder, and when checking dependencies before a rebuild, it might not be able to understand which files to check, and what (or how) to rebuild.)
Visual Studio (at least up to 2008, not sure about 2010) also allows the use of nmake files, but then I think you're stretching the definition of "a Visual Studio project".
But under "normal" circumstances, one project implies one output. And in order to get two executables, you'd normally create two projects.
You need a solution which includes two projects. Have a read of the Visual Studio documentation on solutions and projects.
Here's my solution, since nobody in a Google search seems to suggest this method. It's quite simple and I've used/seen it used in other IDEs (like Code::Blocks).
Within your project, create a configuration for each output that you want. Then, only include one main source file in each configuration.
In VS, this means for each source file with main: right-click -> Properties -> Excluded From Build = Yes. So, once you're done, only one main source is built for each configuration. You can then specify a different output for each configuration in the Project Properties. I did this on VS 2010, but it should probably work with other versions.
I'm using this approach so that I can have several tests for one project, without cluttering the solution with more test projects than actual code projects.
I don't know if it can be done ,but the only change you have ,to do this ,is with custom build step.
EDIT: Since someone downvoted this ,i did a test making a dummy configuration.
In the custom build step I two Link-cmds (copied form original link-cmdline and modified it a bit) taking as input main1.obj resp. main2.obj and outputting App1.exe resp. App2.exe.
It's executed after Compiling and before linking.
It worked !
The downside is I cannot prevent (yet) the linking ot the orinal exe (which errors on duplicate main function).
Solution to this could be to have a lib project excluding the sources with main()from build and build them in the custum-step too.
So the answer to the question should : Yes ,it can be done!
You can't have more than one main() function in a single visual studio project. So you can't compile 2 executables, the only way is to make two different project in the same solution
You can create a solution with two project one for each output you want. Then head to Build menu and select Batch Build.. and select both projects.
If you want both exe files to be in one place you can specify a custom Post-build action:
For both project:
view the project properties page and in Build events select Post-Build events, then in the Command line field enter the command that will copy the output to the location you want, something like:
copy $(TargetPath) c:\yourlocation /Y
Then after you build the solution the output files will be copied to that location.
Another option you have is to use conditional compilation with sth like
main()
{
#ifdef VERSION1
call_main_logic();
#else
call_main2_logic();
#endif
}
and then define different configurations within the project. For each configuration you will then need to define preprocessor symbols appropriately (in: project settings -> configuration properties -> C/C++ -> preprocessor).
Please note, that it will be only one executable created at a time, but with switching configurations you'll get the one that does what you want at the moment.
... which may suit your needs or not, depending on more specific situation that you are in.
Edit: In addition, since different configurations create their separate output folders, you will have your both execs as outputs.