TFBuild 2015: Run sheduled build only when source has changed
In the new Team Foundation Build 2015 (https://msdn.microsoft.com/Library/vs/alm/Build/feature-overview) we can either add CI triggers that trigger a build with every check-in or we have the Scheduled triggers. It would be nice to have an option in the Scheduled Triggers that it only runs if there were changes since the last run (new ChangeSet).
We could use this since we build our Xamarin app with the new build server and publish it to the alpha track in the PlayStore, but we only want to do this once a day and only if there were changes since the last build.
As @ggirard pointed out this has been completed. You can see the release notes here:
Bryan Johnson commented
Is this feature available in TFS 2017 on-premise, or any of its updates? My team is currently on 2017 RTM. Is see it is available in VSTS.
This is available now on VSTS since December 11 release :)
This is a regression and still doesn't exist in TFS 2017 RTM, Microsoft wants us to move to Git?
This is already possible with TFS2017 vNext builds and release management
you have to split the actual compile steps and publish steps
this way you can set a CI trigger on the build and a scheduled release on the release definition, with only latest
Roger Fernandes commented
This does not seem to work with the XAML build process. Does it work with anyone who have migrated to TFS2015?
Bhavik Vora commented
This is very ideal scenario for us, where we don't want to run build on every commit, but want to have a rolling build which runs every 2 hours if there are any changes in this window.
Matthias Kolbe commented
would be interesting in general not just for scheduled builds...
Tim Berry commented
Our teams need to switch away from Xaml builds to adopt a toolset based around Visual Studio 2017, but this issue is blocking us. We have 20+ branches that require build definitions, but can only afford to rebuild them overnight if the source has changed. It would also be nice to skip the build if a developer has manually triggerred one already.
Vaughn Hughes commented
We finally moved to TFS 2017.1 from 2015 and are now migrating our XAML builds (because they're deprecated!), except this is now blocking us! I'm really surprised this wasn't done long ago when vNext was rolled out. Such a simple thing to have a checkbox for it and look at the SourceVersion for the previously scheduled build.
Microsoft, please let us know if this is anywhere on your backlog for near-term implementation. We've got to have this solved.
Thuc Vo commented
I'm out of votes but this is a feature in the XAML build that was essential for our team. To be able to schedule a build that only runs only if anything has changed since the previous build is saving time and resource!
Brett Jacobson commented
With continuous inspection tools like SonarQube being integrated into builds, this feature is really necessary to execute SQ inspections nightly, but only if source has changed. Java SonarQube is slow enough that it severely impacts build times when its included in a normal CI build.
Yep, we need this. Our team works on multiple projects at a time, but if a project's repo doesn't have any check-ins for a few days, it's still building (and deploying) every night as per the schedule. The option for builds to only take place if check-ins have been made (with a path filter, essentially combining the CI and Scheduled build triggers) would fix this.
Nick Nightingale commented
This runs hand in hand with the inability to clean drop folders. Unless we disable builds from branches which are only updated occasionally the drop folders build up very fast.
Torben Lund Pedersen commented
Need the same for VSTS! Now please!
I'd appreciate if this feature also take all of the triggers into consideration. In the previous version (XAML build), the scheduled trigger doesn't take the manually triggered builds into consideration.
Myles Arkell commented
I really hope we can either integrate this or have a way of exiting builds gracefully. We are currently forced to run a script to check if there have been any code checkins and if not raise an exception to stop the build. This works but we end with a large number of seemingly broken builds, if we can't get the old feature to build only if code changes reinstated then what we need is a way to exit a build without throwing an exception.
Dom DeMaio commented
With a large number of repos that don't change often, this is a must have for many of us. In the current system we see 60 builds a night for some code analysis jobs and in reality only 3-5 of them have changed.
Deavon M. McCaffery commented
This is a must have for many reasons, including publishing builds to any number of package managers (NPM, MyGet, etc). With build systems like Travis-CI and AppVeyor, we can do this with tags (from git), but there isn't any way to run a scheduled build only when the source has been modified since the last build fired.