How can we improve Visual Studio Team Services (VSTS)?

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.

193 votes
Sign in
Check!
(thinking…)
Reset
or sign in with
  • facebook
  • google
    Password icon
    Signed in as (Sign out)

    We’ll send you updates on this idea

    Anonymous shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

    18 comments

    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      Signed in as (Sign out)
      Submitting...
      • Bryan Johnson commented  ·   ·  Flag as inappropriate

        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.

      • Kenig commented  ·   ·  Flag as inappropriate

        This is a regression and still doesn't exist in TFS 2017 RTM, Microsoft wants us to move to Git?

      • NN commented  ·   ·  Flag as inappropriate

        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  ·   ·  Flag as inappropriate

        This does not seem to work with the XAML build process. Does it work with anyone who have migrated to TFS2015?

      • Bhavik Vora commented  ·   ·  Flag as inappropriate

        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.

      • Tim Berry commented  ·   ·  Flag as inappropriate

        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  ·   ·  Flag as inappropriate

        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  ·   ·  Flag as inappropriate

        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  ·   ·  Flag as inappropriate

        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.

      • Phil commented  ·   ·  Flag as inappropriate

        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  ·   ·  Flag as inappropriate

        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.

      • LxL commented  ·   ·  Flag as inappropriate

        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  ·   ·  Flag as inappropriate

        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  ·   ·  Flag as inappropriate

        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  ·   ·  Flag as inappropriate

        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.

      Feedback and Knowledge Base