0

We are in the progress of upgrading from TFS2013 to TFS2018. I have decided to re-create our XAML build definitions in VSTS (on-premise).

All is going well and I am able to replicate all the existing steps as required.

Our Agent is installed to c:\Agent using c:\Agent\Builds. However, I started with one definition, using MSBuild, this created a sub folder c:\Agents\Builds\1 with the a, b & s folders within as expected. All was well.

I then cloned this build to create my next, amending the required properties. This is where I ran into problems.

The new build created a new sub folder c:\Agent\Builds\2!

In TFS2013 XAML builds the "1" folder dictated the build controller number. With VSTS I only have 1 build agent so I expected to have the "1" folder re-used for all build definitions. All of my references to the build folder is via $(build.sourcesDirectory). My workspace mapping uses $(build.sourcesDirectory)$(build.sourcesDirectory) as the local path so each build uses a seperate sub folder. $(build.sourcesDirectory) seems to include the numbered folder.

What can I do to get all my build definitions to create in the same sub folder?

I have gone through all of the properties and even exported the definition to json to look in the source for references to the numbered folder.

Daniel Mann
  • 57,011
  • 13
  • 100
  • 120
Andrew Northcote
  • 21
  • 1
  • Each build definition that the agent handles will have its own folder. Each build definition may be using completely different repos and tooling. By design, build definitions are kept separate. (My recollection was that the old XAML build system also separated build definitions.) Why do you want different build definitions to share the same folder? – Jonathan Dodds Aug 01 '23 at 17:23
  • Your agents *should* have separate workspaces. This is intentional and cannot be changed. In the shared scenario you're proposing, what happens if you have two simultaneous builds running for two different branches on two different agents? Well, what's going to happen is both are going to fail because they're trying to read and write to files in use by the other agent. – Daniel Mann Aug 01 '23 at 19:14
  • Thank you for your input. OK, I understand that the builds need separate workspaces to build in to cater for multiple builds. I tried mapping my workspace to $(Build.DefinitionName) (Local path under $(build.sourcesDirectory)) thinking that the "1" folder was the build controller. If this is the way it is then I guess there is nothing I can do. Are you aware of a way I can change the name of the numbered folder to something more recognisable? – Andrew Northcote Aug 02 '23 at 07:40

0 Answers0