4

I like the concept behind MultiConfiguration via the "Options" tab in TFS 2015 TeamBuild. But I don't want the resulting "matrix build" to apply to every step in the build definition.

We generally want to run custom "post VS SLN compile steps" only once after every configuration has been compiled. And we want the artifacts generated from those steps to be "dropped" only once after the post-compile steps have completed.

Right now, using this MultiConfiguration feature causes every single step in your build recipe to be repeated for each combination (typically BuildPlatform and BuildConfiguration).

Is there are way to make MultiConfiguration apply to just the Visual Studio Build steps? I guess as a fallback, we can just not use MultiConfiguration and add a Visual Studio Build step for each combination of BuildPlatform and BuildConfiguration. That's kind of lame though.

jessehouwing
  • 87,636
  • 19
  • 214
  • 286
Keith Hill
  • 173,872
  • 36
  • 316
  • 347

2 Answers2

4

Well, as you can see the expand description under Multi-configuration: Build multiple configurations with the same steps.

enter image description here

So either to add the custom step with multiple times built or not add the step. For now, you may have to use the fallback you mentioned in the question.

If you think it's a necessary feature request, you could add this in uservoice. The TFS administrator and PM will kindly review it.

Uservoice: https://visualstudio.uservoice.com/forums/330519-team-services

PatrickLu-MSFT
  • 44,639
  • 4
  • 24
  • 52
  • The deal is that I want the build platform/config matrix applied to some steps like Visual Studio Build but some steps like PowerShell script to run InstallShield needs to be a one time thing that happens after *all* all platform/configuration combinations have been built. Thanks to the link on uservoice. I'll submit something there as well as via our account rep. – Keith Hill May 03 '16 at 19:09
1

This is currently not possible. MultiConfiguration always builds all steps.

There has been talk of a Build Chaining feature from which one build an trigger a subsequent build definition. Once that's available your start build could trigger the parallel/multi-config build.

It's already possible today to continue the build process in a Release Definition. By treating the first Release Stage as a point in time to "finish up" the build steps, you could have it trigger additional steps when the parallel steps are completed.

It's not ideal, but it's what's available today.

jessehouwing
  • 87,636
  • 19
  • 214
  • 286
  • I'd be happy with a checkbox on each step like we have for Control Options that says "Apply MultiConfiguration" or some wording like that. Heck this checkbox could probably even go under Control Options. – Keith Hill May 03 '16 at 19:11
  • No such option. Remember that when parallelized these builds actually execute on multiple servers in different workspaces. There wouldn't be just one location to gather the results from. – jessehouwing May 04 '16 at 07:29
  • But it is logically a single build. I want my test results/coverage to be associated with that build. The XAML build template make this trivial. I find it hard to believe that this is not a common user scenario where you want to build/test your code in various platform|configuration combinations but need to run steps to package up all of those binaries into a ZIP or MSI file. I would be perfectly happy with the limitation that this would support parallelized builds only on the *same* machine. That shouldn't present a problem. – Keith Hill May 04 '16 at 17:40
  • FWIW we can't use the farm feature because our builds tend use licensed software and we don't want to shell out the $$ for more licenses than we need. Even if we were willing to pay, some of these packages don't support side-by-side versioning which presents a problem. So, for the vast majority of our builds the first demand is on Agent.ComputerName. This also winds up being useful for troubleshooting builds on the build machine because we know which build machine to RDP to. Looking at team build gen3, I really wonder if the MS did enough requirements gathering from their on-prem customers. – Keith Hill May 04 '16 at 17:49
  • 1
    One last comment, sorry if it seems like I'm dumping on you. I'm not and I appreciate your answer and responses!! I'm just a bit frustrated about features I'm losing from gen2. Most of these I can workaround but the workarounds make the build recipes unnecessarily repetitive. I've got one with 8 VS Build steps and 4 VS Test steps because I can't use multiconfiguration. :-( – Keith Hill May 04 '16 at 17:53
  • I feel your pain. Submit feedback on Connect, user voice and the vso-agent-tasks GitHub repository. – jessehouwing May 04 '16 at 19:45
  • 1
    I submitted a few items on UserVoice - https://visualstudio.uservoice.com/forums/330519-team-services/suggestions/13734039-the-multiconfiguration-feature-should-be-configura and https://visualstudio.uservoice.com/forums/330519-team-services/suggestions/13734129-visual-studio-build-should-be-able-to-accept-multi – Keith Hill May 04 '16 at 23:22