I'm using TFS2013.
Do you know if there is a way to chain a gated check-in build, then a classic continuous integration build?
I currently have only one gated check-in build doing 2 actions. The problem is that the 2nd action cannot be done if the source code has not been effectively checked-in.
Any advice would be greatly appreciated...
Thanks in advance for your help.
For those who are interrested in knowing the 2 actions I try to do:
get shelved code, check code quality and compilation (classic gated check-in).
get latest source code, compile it, copy to production the compiled files that has been changed.
The comparison fails if I do it in gated check-in because the source code is retreived again on the next gated check-in -> the binary is different (contains the compilation date) -> the binary is copied again to the production folder
I found the solution.
In the xaml build file, the step getting the source code from TFS has an option named "nocioption".
By default, this value is set to true, preventing CI builds to be triggered...
Related
I have two build definition "A" and "B". I marked "A" to be triggered (Gated Check-in) when the check in include files under "src\ProjectA" and "B" to be triggered when the check in include files under "src\ProjectB".
It's working as expected when the chech-in include only one of the folders.
When the check-in include both of the folder and I click the CkeckIn button in Visual Studio I have to select which build I want to run (I choose "A") and only this build running and all the files are getting in, meaning that some code get into the repository that can break the build that didn't run ("B").
How can I make TFS run both builds whenever such a checkin will be delivered and not accept the change if all of the depended build get passed?
Each gated check-in build definition can have only one running build at a time. If you have two build definitions configured for the same source control folder then you will always get a choice. Your situation is very likely configured for the same source control folder.
It is recommended to have only check in each Project fold instead of check in include both of the folder together to avoid confusion. As a workaround you could first check in files in folder src\ProjectA and then exclude others, after the gated check-in build completed, include other files again.
For more info of the TFVC gated check-in, you could take a look at James Reed's answer in this question Can we build multiple gated check-ins in parallel?
To prevent unexpected build breaks and test failures, We have been using gated check ins. This works very well for our core solutions, and has helped improve our quality.
As part of our overall architecture, we have a certain section of our code with many micro-services, each of which is a new solution. New solutions are added to this part of the code base regularly. These are important parts of the system, and I need to make sure they get compiled as part of a gated check in without the chance for developer error.
Is there a way to configure TFS to find ALL solutions under a certain path and include them in a gated check in build?
Thanks
Not without modifying the build process template, which is almost never a good idea. The new build system in TFS2015 does allow that, however.
TFS 2015 vNext builds allow wild cards to search for all solutions. I haven't had success getting this to work with Visual Studio build steps, which you would need, but it works well with NuGet Installer and other build steps. We will not see gated builds in vNext builds until we get update 2 see TFS feature timeline
I have TFS continuous integration set up, where every check-in triggers a build. But I also want some scripts to automatically modify specific files as part of the build process. This causes a cascade of builds, because files modified by scripts cause another build to be queued. How do I enable continuous integration, but except some check-ins from triggering the build?
UPDATE Solution is: put the ***NO_CI*** into comments when checking in.
If you look at the way a Gated Build works it bypasses any configured CI by spending ##NOCI## or something similar to the checkin comment. I would think that you could do the same to bypass.
Switch to a Gated Build for one build and see the created comment tag.
Is it possible programmatically to on a Gated -Check in build in TFS 2010 to not trigger a Gated Build when checking in a specific file type, i.e. ".config"? How can I accomplish that?
Not that I know of, you can only configure the workspace mappings which controls when the build triggers. so you can include or cloak folders, but not file types.
Presumably you don't want to run the Gated Build because a config file won't affect the build. But still running the build anyways shouldn't really hurt anything, you just waste a little bit of resources on your build server.
If it's really a concern, you can customize the build template, to look at what files are in the linked changeset (using a custom activity and the TFS API probably), and if it's just config files abort the build (with a successful result).
I would go down the route of seeing what messages TFS processes when performing a gated checkin. It might be possible to some how write a TFS server side plugin to hook the event, inspect the changeset and stop the build while allowing the shelf set to commit.
You are swimming pretty far out of Microsofts swim lane on this one so I'm not sure how much work and what the side effects would be on this one.
FWIW, I would want the build to run even on a config file change because I always want to be able to deploy the latest build and see the state of my project.
Is there a way to create a build definition, in TFS 2010, that uses continuous integration trigger, and only builds the project who's code changed.
To clarify, what I'm searching for is the following scenario:
1 Solution
x Projects in Solution
1 Build Definition per Project
All Builds are CI triggered
When a check-in occours in a project only that project gets built and tested.
Place in your build definition's "Items to build" section of the "Process" tab any *.*proj instead of a *.sln.
In the "Workspace" section, select only the source control paths that relate with this project.
In the process tab, set "Clean Workspace" to "None", use "/t:Build" on the "MSBuild Arguments" and properly configure your projects and their dependencies in the solution. This way on each build, you will be getting the latest code, and then building whatever was modified, and anything that depends on it. This is much more dynamic and requires only one build definition. Let the build system operate as it was designed and leverage the optimized build process.