I'm using TFS 2017, and regarding to title I found a term: Incremental build - but, I can not find out where to set it. I tried to add Incremental parameter in ' build parameters' (/p:IncrementalBuild=true) but always got error which says that this is wrong parameter.
Is possible to deliver (or build and deliver) only changed files?
Lets assume how I solved this problem (if anyone has similar problem):
Since TFS 2017 always delivered all files - changed and unchanged, but I need only changed, I solved this as follows:
Since files that are transferred to Artifact keep timestamp (unchanged files have last_edited timestamp, and edited files have new, current timestamp) I decide to create FIXED Artifact directory (not depending on build version, but always the same). Then I wrote PowerShell script (as a first Release step ) which deletes all files (recursive) which have timestamp that is < (Now - x min), and all empty directories after that.
On this way Artifact directory contains of ONLY CHANGED files (entire file structure (of changed files) is kept). Now Release will deliver only these files to destination.
Cheers! :)
If you want 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.
Assuming you want to deliver the only changed files to a specific location, you can add a Copy Files step to copy the changed files to the location.
Related
I have a .NET Core project that is auto-built in Appveyor and deployed to Nuget. By default, every successful build causes a new Nuget release.
However, there are many cases when a new release is meaningless because the library's actual code has not changed:
Readme updated
Unit tests added
Appveyor configuration changed
Other cases
It is possible to configure the build so that Nuget publishing only runs if there are changes in the actual code (for example, in folder X)?
There are a few options.
Commit filtering. Note that with it the whole build, not just deployment will be skipped if nothing in folder x changed. You may need a build without deployment at least when unit tests added. As a workaround consider adding separate AppVeyor project which will build and deploy only if folder x changed and keep current project to build every time, but not deploy
Inspect changed files with script. Please check this sample on how to check those files if you use GitHub. So if you see that files in folder x changed, you can set some custom environment variable (lets say you call it deploy_nuget) to true, and use it with a conditional deployment.
In TFS Builds component I try to do this for instance, to put these files:
Main\Folder1...\bin\file1.dll
Main\Folder2...\bin\file2.dll
In one file such as: \Main\dll
I can do manually, for each folder, but if I have so much files I don't want to do that manually.
What I'd like
Thank you for helping me!
Add a Copy File step after the VS Build step. And in the Copy File step, set like the picture below: the Contents could be **\bin\$(BuildConfiguration)\*.dll and make sure that the Flatten Folders is checked.
Note:
The Flatten Folders only exists in TFS 2017 Update1 and upper version for on-premises. VSTS also has it. But in TFS 2017 and TFS 2015, it doesn't have.
So, if you are using lower version of TFS, you need to use 2 Copy File steps and copy the 2 dlls to the Main Folder separately. Or you could download the latest source code(it has the FlattenFolder option) of that step from here. Then package it and upload to your TFS as a custom build step.
You can use the MSBuild Arguments to achieve this. Just add the OutDir argument to the Build Solution Step like this:
/p:OutDir=$(Build.BinariesDirectory)
In this case, all of your files will end up in the Binaries Directory of your Build Agent. e.g. "C:\Agent1_work\1\b"
Of course you could also use a different target folder than whats inside the variable $(Build.BinariesDirectory).
I got two solution setting at same location. This two solution are sharing some of the projects along with some dedicated ones.
I have created two separate build definition with gated check in trigger but issue is that when I make any change in one solution it triggers both the build definition.
Can I somehow control the triggering of the build definition based on the solution that I am checking in?
You need to configure your workspace correctly for this to work. Any change in a Build definition's mapped workspace will cause a build to trigger. Due to this, it completely depends on your source control layout, whether it's possible to setup a build that only triggers when something changes that belongs to either solution.
This setup will become very hard to manage quite quickly, as such I recommend you put each set of projects in their own subfolder, that makes it a lot easier.
So ensure that you build definitions won't both trigger, open the Source Settings panel of your build definition and apply a cloak rule to each file or folder by changing "active" in the first column to "cloaked".
To cloak a file you need to enter its full path in TFS, the UI will only offer you a folder picker, but entering a path to a file will work.
These files should:
Not be needed to build the solution
and changes to should not trigger the build.
Do note that the cloak will cause Team Build to not get these files on the Build agent, so it's not possible to have files your build depends on, but not trigger the build when these files change.
You should create gated check-in build definitions per project not per solution.
When doing a get-latest from TFS, all timestamps are set to the time at which the get operation was executed. When doing running msdeploy to perform a sync, the timestamps in the source are compared with the timestamps on the target server. Of course, this means that with TFS + msdeploy, every file will be pushed to the target servers after every build, unless
You use incremental builds
You have only a single build agent in the build controller's pool.
If the build definition is set to do Clean builds, or if you want to utilize multiple build agents, then this no longer works.
This topic comes up all the time, and once every couple of years I cast out new lines in case something has changed. This could be fixed in a couple of different ways:
TFS sets timestamps on workspace files to the last checkin time.
TFS sets timestamps on workspace files to the last modified time from the files themselves when they were last checked in.
msdeploy uses some content-based comparison method (e.g. MD5) to compare files, rather than timestamp comparisons.
Something else?
I never know where to go to search for this stuff since both of these teams are pretty opaque--the webdeploy team in particular. Is this a problem that has been solved yet?
The TFS and visual Studio teams are entirely transparent and you can submit feature requests through http://visualstudio.uservoice.com and bugs through http://connect.microsoft.com.
However all files within a server workspace are set to the date the file was last modified on the server. Local workspaces physically compare the file contents to determin changes. You can change from local workspace to server workspace in the workspace properties.
In the end, we got around this by writing a powershell script to wrap the .cmd file produced by the Web Publishing Pipeline, and passing the -useChecksum flag in the command that invokes the .cmd script. Since the boilerplate .cmd created by WPP allows for passing additional arguments to msdeploy, we were able to accomplish this with a line like the following.
& "MyProject.cmd" /u:agent /p:P#ssw0rd /m:$ComputerName /y -useChecksum
In this way, even though TFS is creating workspaces with timestamps set to the get-latest time, msdeploy is now instructed to use checksums instead.
I'm trying to get continuous integration working using Hudson, Maven & Perforce (with an scm poll used to trigger each build)
One of the requirements is to automatically update POM snapshot version numbers following each successful build.
This is trivial using the Maven release plugin, but the act of checking in the newly versioned POMs triggers another build - which continues ad infinitum.
Is there any way of checking in version updates without triggering another build? There doesn't seem to be any way of excluding specific user checkins, specific changelists, or specific files when the scm poll makes the decision to rebuild.
This seems like a basic requirement - been doing it for years using Cruise Control / Ant / Perforce,
Cheers,
Mark
I have been contemplating a move to Hudson, but the inability to exclude specific files from the scm poll would be a deal breaker. Did you also ask this question on the Hudson mailing list?
users <at> hudson <dot> dev <dot> java <dot> net
The only workaround I can see from reading through the docs seems to be triggering builds based on p4 triggers, where you could then programmatically do whatever you want, but that doesn't seem to be a very simple approach.
I don't believe there is any way to configure Hudson to omit part of a Perforce workspace when polling. You may have better luck by setting up two different workspaces - one for build test using a default POM and one for your releases with the auto-updated release POM. The two workspaces could differ on just this one file and modifying the release POM would not trigger a new build.
Check out how to do individual file mapping in a workspace in the P4Guide.
Its possible to update the description of a changelist after it has been submitted, so if you build to a certain changelist number you can then update the description of that changelist to include your build number. This shouldnt trigger a new build.
What is "POM"?
You can have Hudson "Create or Update Label in Perforce" (see near the bottom of your project's configuration.) You could use that along with the BUILD_NUMBER environment variable that Hudson provides, giving you unique build numbers and stamped P4 labels of said build.
I have all tagging, ChangeLog updates, and packaging done by our checked in build code. This allows us to:
Create RC and appropriate tags without starting anther build
Allows us to debug all aspects of our build on any dev machine, not just those with Hudson.
Allows us to exactly recreate how a package, tag, etc was done in at any point in the past.
I had a similar problem checking in compiled src. I was able to find an alternative but i did consider the following.
In hudson specify a child folder of your project to poll. I.e. don't actually have hudson check out your project, just an incidental folder.
Add a shell script to check out your project proper.
Run you normal scripts.
check in your pom. The trick here is that the folder being polled won[t have changed at this point.
Not ideal, but works.
The perforce plugin has had polling masks for a while now. It's in the Advanced section under "View Mask".
Basically, you list a subset of files that you want polling to check for changes. Unfortunately there's no easy way to exclude files, so you'll have to create a list of file specs that specify everything BUT the file you want to exclude. So if the version is contained in a pom.xml, I would need to specify the files and directories that don't contain it.
For example, if your directory structure looked like this:
./pom.xml
./lib/
./src/
You would specify,
//depot/project/lib/...
//depot/project/src/...
as the view mask, and check the checkbox to use it only for polling. There are a few limitations with this feature, such as not being able to use '-' to exclude file specs, but it's still a workable solution for now.