I have created 3 continuous integration builds under same source control folder i.e under one TFS folder, there are 22 projects and 3 solutions under this folder, each solution contains some shared projects. I have created a continuous integration build for each of the 3 solution files. The problem is whenever anyone checks in under any solution all 3 builds are triggering. Is there any way to trigger the related build only if there is any check-in under the any solution ? Please let me know how to configure 'Items to build' and source setting tabs in TFS 2012 ?
TFS 2015u1 and older
The Source Control Folders in the mapping govern when a CI build triggers, nothing else. A custom Activity might be able to check that no changes were made in specific folders and prematurely stop the build, but that requires you to create a custom activity and customize the workflow.
Normally you'd place each solution and its projects in their own folder in Source Control, that way you can create a source control mapping for each specific CI build.
TFS 2015 update 2 and onwards:
The new build engine supports separate definitions for workspaces and triggers.
Related
We have a very long running build and we are trying to break it down into incremental builds. The code is c#/.net with jenkins as the build manager and TFS (visualstudio online as the source control)
So the architecture would look like:
Area 1 (1 or more solutions)
Area 2 (1 or more solutions)
Area 3 (1 or more solutions)
So the idea is that if code is checked in in Area 1, the associated solutions for only that area are built and the tests for that area are run.
We would then also have a nightly build that builds everything.
My question is, is it possible for Jenkins/TFS to detect which area of code has been checked in and pass a variable (or list of variables) into the build script which tells it which items to build/test?
Visual Studio Team Service (Visual Studio Online) supports Git and Team Foundation Version Control(TFVC).
If you are using TFVC for version control, it is possible for VSTS to detect which area of code has been checked in. However, it cannot tell Jenkins which area is updated and to build. So the alternative way would be create three Jenkins jobs for the three area and triggered by three VSTS service hooks.
For example, you have three area in "Test" project, so the folder structure will be:
$/Test
---/Area1
------/Porjects&Solutions
---/Area2
------/Porjects&Solutions
---/Area3
------/Porjects&Solutions
You can create a Jenkins Service Hooks for Area1 as following to trigger the Jenkins job for Area1:
And in the Jenkins, update the setting for Area1 job to just get the source file for Area1:
Now, only when the code in Area1 is checked in, the Jenkins job for Area1 can be triggered. And repeat the steps above to configure the settings for Area2 and Area3.
If you are using Git for version control. There isn't any way to trigger the build by the area folders in the Git repository, you need to separate the three area and put them into three Git repository.
We have a Visual Studio solution containing about a dozen class library projects. They're our team's main internal framework. In Jenkins we would like to automate the building of these projects as soon as a check-in is made, and also publish a new version to our local NuGet repo.
The problem: We would like to trigger the build by polling SVN at the class library level, e.g. ..trunk/OurSolution/OurCoreProject. Changes in one project should not trigger a build on all the other projects. But the checkout needs to be done one level higher, e.g. at ..trunk/OurSolution, and I cannot figure out how this can be done.
We've tried and contemplated a few solutions already:
Checking out at project level and then send the .csproj file to
MsBuild.exe instead of the .sln file. This fails because the project
expects a sibling folder named .nuget.
Looking into the Multiple SCMs
plugin, but it seems to mainly add the ability to use different SCM
providers in the same project(?) I would like to avoid adding this
plugin until I know it solves this.
Splitting all the projects up into separate solutions. Doesn't feel very optimal...
Is there a way to solve this in Jenkins? Have a missed any viable solution?
Yes you have missed something... the Advanced... button on the Subversion checkout configuration.
Do your SVN checkout on ..trunk/OurSolution
Click Advanced...
Under Included Regions, type ..trunk/OurSolution/OurCoreProject/*
For more info, click the ? icon next to relevant text area on the UI
If set, and Jenkins is set to poll for changes, Jenkins will ignore any files and/or folders that are not in this list when determining if a build needs to be triggered.
I have a solution file with multiple projects that I am trying to configure for continuous integration on a development server using Team Foundation Server. I would like to customize this to only deploy the changes that were checked in.
Scenario example
Projects
My Project (MVC app)
Logic Layer
A user checks in a new Home.cshtml file and updates a code file in the Logic Layer. I would like to configure the automated build to just build the following package:
My Project
bin/MyLogic.dll
Views/Home.cshtml
What steps are done to achieve this scenario?
You want an incremental build, though I don't recall if it was supported back in TFS 2010.
Try configuring the build to not clean the workspace. Set the "Clean Workspace" property in the "Basic" section to "None".
Then, it will keep the binaries from the previous build, and, just like Visual Studio, will only build targets for which the inputs have changed.
Ok so I have to admit, I'm very new to all of this build automation stuff. But basically what I'm wondering is if there is a way to wire up my build definitions in such a way that if I have a case like so
ProjectA produces ComponentA.dll
ProjectB references ComponentA.dll and produces ComponentB.dll
ProjectC references ComponentB.dll
then when I make changes to ProjectA and check them in, the build process would automatically also build ProjectB, and finally ProjectC, and report any errors.
So is there a way to accomplish this, or should this type of thing be handled somehow completely differently in the first place?
The process you are referring to is the crux of the practice known as Continuous Integration.
TFS does it very well: simply set your build definition Trigger to Continuous Integration and set the Workspace working folder to the parent folder of the three projects. This way, any change in one of the projects will trigger a build.
MSDN: Build and Deploy Continuously
You can use a visual studio solution and use project references between the projects. Then build the solution on your build server.
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.