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

allow build vNext/preview tasks to be conditionally enabled or disabled.

I would like as much as possible to have a single build definition handle multiple different build scenarios. Something as simple as being able to disable or enable a task based on an expression evaluation would go a long way. For example only running a package push step when "$(Build.SourceBranch) in ('master','dev')" would allow me to restrict the push step while preserving all the others.

179 votes
Sign in
Check!
(thinking…)
Reset
or sign in with
  • facebook
  • google
    Password icon
    I agree to the terms of service
    Signed in as (Sign out)

    We’ll send you updates on this idea

    Aaron DandyAaron Dandy shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

    36 comments

    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      I agree to the terms of service
      Signed in as (Sign out)
      Submitting...
      • Hamid ShahidHamid Shahid commented  ·   ·  Flag as inappropriate

        Tasks can now be executed conditionally but NOT when they are part of task group. This is not good. We make use of task groups widely to keep our builds manageable and inability of tasks to be run conditionally in task groups make this new functionality not usable to us

      • George WilsonGeorge Wilson commented  ·   ·  Flag as inappropriate

        This would be very helpful for my automated tests because we have 4 different builds that my BVT runs against. Having this would allow me to have 1 build definition instead of 4 and growing.

      • Anonymous commented  ·   ·  Flag as inappropriate

        Is this in the works still? How soon can we expect it? Really a show-stopper...

      • Aaron DandyAaron Dandy commented  ·   ·  Flag as inappropriate

        As it has been a over 12 months now since this was posted I wanted to check in with some more community perspective with respect to this issue and maybe get some information from your teams with respect to when we may be able to expect a practical workaround or solution to this. On our end we have had a good deal of time to try different workarounds that we could come up with to this problem but all have had negative impacts on other things such as our artifact storage or our SCM process. Because the community can't help contribute solutions to this problem directly we have been forced to look inward and solve the problem by adding hacks to community projects. That does not work either though, as our hacks have often been correctly rejected for being hacks (ex: https://github.com/OctopusDeploy/OctoTFS/pull/70#issuecomment-265626620 ). We really do need something to simplify and unify our deployment process and are open to other work arounds you may suggest if this functionality is too much to get completed in the near term. On your end, would it be possible to get some kind of update on the status of this functionality and if there is a beta channel where we can try it out to offer more feedback on it?

      • Greg RGreg R commented  ·   ·  Flag as inappropriate

        Can you share the likely direction on this? From my point of view it should have keywords and macros, e.g. a macro references a number of keywords - tasks
        @buildonly => fetch, compile, quick_test
        If the task for compile it has logic like
        if bDoAll or flag_eixts("compile") then run
        In this way you can setup a master build project that covers all aspects then mix and match for variations using these macros.

      • Anonymous commented  ·   ·  Flag as inappropriate

        Same here. We would like to build all branches but only want to trigger a release for master builds.

      ← Previous 1

      Feedback and Knowledge Base