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.
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?
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.
we have setup TFS Build for our project, but on every build the system copies the whole repository and then compiles our solution. How can we make sure TFS Build only downloads the files needed for the solution without having to cloak each un-needed directory manually ? Now it downloads over 2GIGs of data just to compile a project that is less then 100mb in size (source files). The other data are test databases and files that are not needed for the automatic build.
EDIT:
some further investigation let me to some keywords for searching. These posts are helping out:
Team Build - Get Workspace - get latest from specific paths, NOT everything
TFS Build and workspace
still investigating though. Any comments are welcome.
EDIT:
An option is to replace CreateWorkspace in the Build process definition with my own extended activity. I'm hoping to find out that somebody already did.. basically you would use the VersionControlServer object to download the necessary files instead of the whole workspace.
EDIT
There is currently no real good answer / solution to this. I gave some options and the people that responded gave some alternatives, but you can't easily change the TFS Build process to just download the data that is part of the solution instead of the whole repository. So be aware when you are building your repository.
You want to set the Build Definition mapping to only include the source you wish to compile. This means that you don't have to cloak any thing.
Edit Build Configuration
Click on Source Settings (VS 2012), Workspace (VS 2010)
An example specific mapping would look like this:
StatusSource Control Folder Build Agent Folder
Active$/Path/To/The/SolutionOrProjectFolder $(SourceDir)\
This will make the workspace for this build be limited to the solution that you wish to build. Therefore only AssemblyInfo files under that will be visible to your build activity.
If you cannot do this due to how your source control is setup, then I would suggest restructuring your folders within your Source Control.
If you have more than one Build Agent, you should limit the number of agents that the build definition can run against. That will stop multiple copies of the same source been downloaded on to the build machine(s).
The next part you have already answered in you question, by changing the "Clean Workspace" option in your Build Definition to None the build agent will only download the changesets between the current and last build.
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.
I'm currently working on creating a build template for TFS2010 builds. However, I notice that I'm currently 'spamming' the source control with every change I make to the template (and lots more for all the fixes for those changes).
I wonder what the easiest way is to test the build templates I'm creating?
Is there a way to change the template file and custom activity dlls that doesn't involve checking them in?
I currently have a build controller and agent running on my developer machine, which I'm using to test the template (test = start a build and hope for less errors than last time).
Why is 'spamming' a problem? Anyway, I have a separate Team Project for doing this kind of work, that way I can check in to my hearts content without affecting the developers who need to have a stable build. once I've done my testing I check the template in to the team project(s) used by the developers.
I want to test my builds against the teams latest code-base without having to branch it over to a trial project.
Instead, I do the following:
Create a separate build definition called 'Infrastructure'
clone a production definition
Set the trigger on the Infrastructure build definition to manual.
Set the Infrastructure definitions permissions to allow only [Project]\Build group members to have full control of it.
keeps the notification of broken builds away from the bulk of the team).
Create a separate build process template, called 'Infrastructure.xaml'.
Point the Infrastructure build definition at the Infrastructure process template.
Now when I want to iterate on a new build feature for the team:
Check out the build process template I want to update, and lock it.
Copy the build process template I want to update overtop of the Infrastructure.xaml.
Add my build feature to the Infrastructure.xaml file, and check that in.
Use the Infrastructure build definition to test my changes.
Iterate over 3-4 until I get it right.
Complete the feature and have my changes verified by another Infrastructure team member.
Copy Infrastructure.xaml over the build process template I locked in (1) and check it in.
This still results in 'spam' in the TFS source control, but it keeps the build definition iteration out of the eyes of the team. My build process templates are located out of the main source tree (under the Build Process Templates folder, or in the branches themselves under a 'Core/Build' folder where no-one else on the team is typically paying any attention) so that the team is largely unaffected by it.
#d3r3kk: Why not just branch the template and merge changes back when ready instead of creating copies? That way you can preserve source history in a cleaner way as well.
Ideally, there should be a way to have a build process template that is in progress by having it on your local file system and pointing the build definition to it temporarily. Not sure if something like this exists in later versions of VS/TFS. I haven't seen it available via the UI anyway.