I have our Solution on CI build. That works.
When dev's check in changes, the solution builds, but only for changes to that solution.
How do I get the build definition to build on changes to OTHER folder changes outside of the solution?
Yes, I can add a workspace in the workspace sources tab. But that means all that code is downloaded on every build.
Our solution has over a dozen dependencies. I would like to trigger a build if any of those dependencies change. We don't need the dependency source code to download into the build workspace at all. That's just pointless.
Yes, we have a folder in TFS for our Nuget Packages. We check them in automatically on build (Thank you TFS).
I could just add the NugetPackage workspace to the solution's workspace list, BUT that would result in every version of every dependency getting downloaded into the build workspace.
How can I trigger a build on a change that I do NOT list in the workspaces list of the build definition?
Btw, we are using TFS 2012
I was hoping the Cloaking feature would allow for this, but if it's cloaked, the automated build does not trigger. The automated build only fires if the workspace folder is set to active. Which also means download every NugetPackage in that same folder!
It's not able to trigger a CI build on a change which not list in the workspaces list of the build definition.
A few other things to know
Make sure the folders you include in your trigger are also included in your mappings on the Repository tab(the same to
workspace mappings).
Source Link
As a workaround you could set clean workspace to false, which will not get other unchanged files every time.
If your build process does not require a clean workspace or
repository, you can significantly reduce the time that is required to
run the build setting this parameter value to False.
Related
Actually first code is built and deployed after some updates developer changed the code and check-in the files now I want to build that files or folder and get that files artefact in drop folder? as well as how to deploy those files? in Tfs 2017 and it will automatically build only check-in files.
What you would like is to have an incremental build. When you add a Visual Studio Build / MSBuild task to build the project, just uncheck the Clean option. Thus it will sync the source and only get the changed files from the second time to build. See
Build task Arguments for details.
Clean Option : Set to False if you want to make this an incremental build. This setting might reduce your build time,
especially if your codebase is large. This option has no practical
effect unless you also set Clean repository to False.
Set to True if you want to rebuild all the code in the code projects.
This is equivalent to the MSBuild /target:clean argument.
However for artifacts, TFS always delivered all files - changed and unchanged.
It does copy all of the project output (subsequent projects that
depend on it may depend on these assemblies and files being there).
This causes incremental builds to be much faster, but it doesn't "only
deliver the changed files". It always delivers all files whether they
are changed or unchanged.
You could take a look at jessehouwing's reply in this question about this part: Incremental Builds issue in Team Foundation Server
Each time i generate my build through jenkins, my existing jar file in the target folder is overwritten by maven. For example: i have a existing version of 1.0 in jenkins target folder, now if i create a new build with version 1.1, the previous version in my target folder gets overwritten.
I don't want that to happen, i want to archive all the versions (because we might provide some of the old features to certain set of customers). i am just trying to understand is there way to do this in jenkins pipeline. I don't prefer plugins, it would be nice to do it declarative way using jenkins file.
First of all, it's not the best solution to store your artifacts just in target folder without any copying to other place. Usually all needed build artifacts are stored in Nexus or Artifactory repositories (of course, you can copy them to some local directory also). You can do that in pipeline Jenkinsfile as well, but you still require to install needed plugin. For example, for publishing artifacts to Nexus repo, you can use Nexus Platform Plugin, see this answer for details.
About overwriting your target folder, I'm not sure if it's cleaned by Jenkins by default. To clean workspace, you need to specify Discard old builds option in job configuration first.
Seems to be that you just execute mvn clean ... command, that's why target folder is cleaned, so I would recommend to check that first.
I have three builds.
Build A
Build B (cloned from A)
Build C (cloned from B)
Build A builds our entire environment, Builds B and C were cloned, but then stripped to only build specific parts and from different branches. Since doing this, we've seen the build time on Build A triple. It is running tf vc workspace /delete on every build.
Build C also deletes it's workspace, but build B does NOT. On the repository tab, all three have Clean set to false.
Is there anywhere to view/set options for the Get Sources task? What would cause one build not to do this and the other two to do it?
There are only three TFVC options in get source step of TFS build pipeline.
No any other extra option to control the get source task.
First suggest you check whether you set Clean = true in Visual Studio Build task, you need to uncheck it here.
If you do not check Clean option and the build always refreshed workspace on local build server and build agent always cleans TFVC Repository. Try this solution: completely wipe the agent directory and start again, this may fix the problem. Another way is reconfigure your build agent and trigger the build again.
Besides, you could also disable the default get source steps in the build definition. And use your own script to do the get source/pull files to bypass workspace mapping issue. How to, please follow: Is it able to ignore/disable the first step Get source in vNext Build?
I found my answer. By adding the System.debug = true I was able to get a view of the actual mappings in the workspace. Then I matched that up against a list of all the mappings in the repository of the build. What I found was that when we map a folder and one of its sub-folders as well, only the parent folder mapping is created in the workspace definition.
When Get Sources runs, it looks for a workspace name that matches and then first does a simple count check. When the number of mappings in the repository doesn't match the number of mappings in the workspace it fails out and immediately deletes and rebuilds the workspace.
By removing the sub-folder mappings, my Get Sources task dropped from 11+ minutes to seconds.
I have a TFS Build that runs overnight. The build source can be found on the agent in c:\build\3\poject\build def\Sources.
The \Sources folder was accidentally deleted (guilty). I would have expected TFS to "Get" the latest source prior to the next build. It seems that it doesn't do this - it just complains that it can't find any of the sources to build.
Can anyone please tell me how I force TFS to get the latest sources to the build agents \sources folder?
Under the Build Definition -> Process what is the Clean Workspace parameter set to? If it is set to All it should cause the entire source to be downloaded on each build.
There should be a way to cause a full redownload of source from the build definition but I am not seeing an option right now. You should be able to fix this on the build machine itself. If you cd into the Source directory and then run tf get /force it should redownload all of the content. Subsequent builds after this should work.
I have some Libraries added in my TFS 2010 project in a Lib folder.
Each time I check In a dll in the Lib folder, all the build that reference that Lib folder trig automatically (more than 20 Build).
I can use the ***NO_CI*** to prevent that. But I prefer to have something automatic.
Is it possible to have an event handler on TFS to prevent that.
Ex. If the check in is on that folder, do not scan all the CI Build Workspaces to trig the build.
The workspace mapping in the build definitions defines which files/folders are part of that build. You can use cloaked folders to explicitly exclude folders from the workspace.
However, the workspace mapping is used for 2 purposes: to determine which files get downloaded to the build server as part of the build, and to determine which files trigger CI/Rolling/Gated builds.
If you exclude folders from the workspace (e.g. using cloaked folders) it will stop the builds from being triggered but it will also stop those files from being downloaded as part of the build.
If you want to have a build download a certain folder as part of the build but not have builds triggered by check-ins to that folder I don't believe it is possible without customizing the build workflow.
When you include a folder in a workspace, you're saying that changes to that folder affect your project. This is the same for changes to shared source code as for shared binary. If it changes, then the affected applications should be built (and their automated tests should be run) so taht it can be determined whether the changed files have broken anything.
Make sure each library in the lib folder has it's own folder + version folders beneath
lib
EntityFramework
4.1
EntityFramework.dll
4.2
EntityFramework.dll
Then modify your builds to only reference specific folders for the library a project references.
It takes a lot of work to setup builds, but will ensure the build only triggers when a file needed for the build is changed.
Alternatively a copy of each library in the projects directory, which you could manage with a package manager like NuGet or OpenWrap