Recently I have been using Visual Studio Team System for builds and unit testing. I’ve actually really enjoyed getting back to working with builds and testing again, and I’m amazed at just how different it is running builds on VSTS instead of on-premises TFS build servers. Whereas I was used to use massive MSbuild files with tasks etc, or those awful Workflow builds that I never really adopted, the build process online is ridiculously straightforward, and the hosted build process machines have pretty much every piece of software you could hope to have running on a build server.
Recently I’ve been creating some unit test projects using tSQLt, the SSDT unit test projects, and MSTest. I’ve been chopping and changing which one I was using based on the tests I needed to run, so I deleted a unit test project that was wrapper for my tSQLt unit tests. I used a unit test project to wrap run the tSQLt tests as opposed to a post-deploy script that contained something like “tSQLt RunAll” because I wanted to get the test results on my build. I used this excellent tSQLt Test Runner unit testing framework, which was so easy to set up and get running.
Anyway, to get to the point of this post, despite the fact that I had deleted some unit test projects the build was still trying to run them and so the build kept on failing. This was not a hosted build server, which is built up and torn down every time, but a build server hosted in Azure. Clearly the build agents workspace was not being cleaned every build, and i needed the old files purged before the build would pass. I remembered from the times managing builds in on-premises TFS that a clean out of a build agents workspace is required…so some things are reassuringly familiar! But rather than jump on the build server and delete the data, it’s possible to get a build to clean out the previous workspace and start over. This may make builds slower, as purging lots and lots of tiny files can cause problems, but I had little choice in this case.
First, select the build tab on VSTS and select the build, and then click “edit”
Then in the Repository tab, alter the “clean” property from “false” to “true”. Make sure you hover over the “(i)” because depending on what you have installed on your build box you may need to make further changes to the variables.
But hold on, aren’t there “clean” options on both the “build” and “repository” tabs? Well yes they are, but the option on build are very different. The “clean” option on the build tab is the same as running a “clean solution” from Visual Studio.
You can always verify whether the build is cleaning the workspace first by checking the log files post build. Download the log files and check the “1_Build” file and search for “clean”.
That’s it for today, Happy Building!
 Workflow builds were xaml files that visualised the build process in a drill-down type file. They were awful. Imagine the film Inception, except every level is a nightmare. Some SSIS files can get as bad as this. There was a default template that you would have to copy if you wanted to customize a build, which invariably you’d have to do 100% of the time. I shied away from them when they first arrived with Visual Studio 2010 and was glad I did, as the templates from VS 2010 were not compatible with VS 2012. I did create a few workflow builds on 2012, but never really got away from the monolithic MSBuild files because they worked really well and were robust, and I never really found that I had the time to port MSBuild files to Workflow builds for 0% benefit.