Why you need to use vNext build tasks to share scripts between builds
Whilst doing a vNext build from a TFVC repository I needed map both my production code branch and a common folder of scripts that I intended to use in a number of builds, so my build workspace was set to
- Map – $/BM/mycode/main - my production code
- Map – $/BM/BuildDefinations/vNextScripts - my shared PowerShell I wish to run in different builds e.g. assembly versioning.
As I wanted this to be a CI build, I also set the trigger to $/tp1/mycode/main
The problem I found was that with my workspace set as above, the associated changes for the build include anything checked into $/BM and below. Also the source branch was set as $/BM
To fix this problem I had to remove the mapping to the scripts folder, once this was done the associated changes shown were only those for my production code area, and the source branch was listed correctly.
But what to do about running my script?
I don’t really want to have to copy a common script to each build, huge potential for error there, and versioning issues if I want a common script in all build. The best solution I found was to take the PowerShell script, in my case the sample assembly versioning script provided for VSO, and package it as a vNext build Task. It took no modification just required the addition of a manifest file. You can find the task on my vNextBuild Github repo
This custom task could then be uploaded to my TFS server and used in all my builds. As it picks up it variable from environment variables it required so configuration, extracting the version number for the build number format.
If you wish to use this task, you need to follow the same instructions to setup your development environment as for the VSO Tasks, then
- Clone the repo https://github.com/rfennell/vNextBuild.git
- In the root of the repo run gulp to build the task
- Use tfx to upload the task to your TFS instance