Donocode Blog

Having reliable testing in your development and deployment pipeline is essential when working in large and small projects alike, however recently I have started to run into issues with reliability when using karma-webpack to run my client side tests for a current project. The issue is that karma-webpack generates a bundle for every single test file, when the browser connects to karma it loads all of these test files in one go and also has to parse and execute them immediately, now on a powerful development machine and a modern browser this is no problem, but on your CI driven test targets you might start to run into issues when trying to load and parse hundreds of MBs of javascript in a reasonable time.

In preparation for seeking new opportunities I have completed my yearly site refresh. This year opting for the NodeJS based static site generator metalsmith, utilising flexbox and responsive design to keep the content looking good across devices. The site uses Bitbucket pipelines and AWS S3 to automatically build and deploy on git push.

While writing some batch scripts I needed to pull the msbuild tools path from the registry and into a variable, simple I would have thought but due to the way REG QUERY returns results, not so easy. I had varying levels of success with solutions found on StackOverflow however it seems that at some point Microsoft changed the delimiter in the REG QUERY return string to be four spaces instead of a tab character and it's possible for the key value to have a space in, so splitting on a space is out of the question.

In Team Foundation Build every build definition is linked to a workspace, the workspace, like the one on your dev machine holds the source and manages files that are checked out. Sometimes you may want to check files in and out on the server during a build, for example when incrementing application or assembly version numbers, this is possible, however it requires the current workspace to be known. The only tfs activity available to get a workspace requires the name of the workspace to be known, tfs names the workspaces automatically so this isn't very helpful for a generic build process.