Category Archives: programming

tips on fixing a broken build

Leave a reply

When builds break on the build server, it can be hard to figure out what the problem is. I’ve been doing this a lot of times, and so here’s a collection of tips that can help you in fixing that weird error that keeps breaking the build. Build systems are pretty similar, so whether you’re using TeamCity, Azure Devops, Gitlab, Jenkins, Circle CI or whatever, these should pretty much work everywhere.

Make sure it builds locally.

This has to be the “Did you try turning it on and off again?” of build fixing. Sometimes that build really is broken. A file might not have been checked in, or a merge might have gone wrong, but what you have on your local machine, might not be what’s in source control.
Get a clean copy of your repo in a separate folder, and build that to check if it builds OK. At least you’ll be 100% sure it’s nothing trivial before you start your investigation.

Try a clean build.

Another “try turning it on and off again” tip, I guess. On most build servers, you can opt to run a clean build. This means the agent will set up a fresh checkout folder for the new build. This way you make sure no leftovers from a previous build are causing the problem. Sometimes things go wrong with source control and getting the latest version, messing with your build. This also fixes that issue.

Does it fail everywhere?

Sometimes build agents are not installed in exactly the same way, and builds might break on a single or a few build agents only. This is good. Now you know you can always get a build on a good agent, so you aren’t stuck when you want to produce some build artifacts, and you know there’s something on that machine that’s not quite right where it’s failing.
The error will usually give you a clue on what’s missing, but most of the time you’ll only understand why after you resolved the issue. Ah, the joys of software development.
My tip here is to compare the machines and see what build tools are missing or different from the one where it does work. Make sure your SDK and build tool versions are the same, and can be found. Check your shell versions, like PowerShell and if they are running in x32 or x64 mode, and if all PS modules are installed in the mode you’re using.
If you have an automated way to quickly produce a build agent, you might want to ditch the failing one, in favor of a brand new one if your build works there.

Check the logs.

It sounds trivial, but the log files of your build server contain a lot of details you’re not looking at when things are working. Now that things are broken, it’s time to dig in and see if you can find a few clues. Most build systems also have settings to change how detailed those logs are. Setting this to verbose can be what you need to find that final clue to solve the puzzle.

Get into the machine.

When things should work, but appear broken on the build server, you’ll sometimes have to dial into the build agent and see what things look like in there. Paths might not be what is expected, files might actually be missing, and tools might be different. There you can open a shell, check if anything is missing, check if build tools are available, or try and run the same command that’s failing yourself. This doesn’t always work as build systems sometimes wrap your SDK calls, and you’re not always sure you’re running the same statement, but it might give you a hint of what’s going wrong anyway.
Look around on the machine, and you might find the problem. Can’t access the machine? Try the next tip.

Get into the machine, without getting into the machine.

You might not be able to access the build agent itself. Pesky admins, or it might even be a cloud machine you don’t own. Luckily you can edit the build itself right? In most cases, you can run some arbitrary shell commands as a build step for whatever fancy stuff that isn’t covered by default.
Well, nothing is stopping you from running an ls or type nuget.config command to find out what is really happening during your build. The output of those commands will normally appear in your build logs. You might have to check the more detailed full log files, but it should be there. This can be a tedious process, but it saved my butt a few times when things didn’t work for an at the time unknown reason.

base16-vim has all the vim themes you’ll ever need

Leave a reply

You think that’s a bold statement? Hear me out. Vim themes are great, but you (and most certainly I) spend way too much time downloading and trying out all these fancy new themes, right? At some point I came across this base16-vim plugin which has a shit-load of cool themes, all using a base of 16 colors. I haven’t looked back since. Well, maybe once of twice, but still, I’m sticking to it.

Base16-vim contains 128 different themes, and it has all the popular ones like the github theme, solarized (dark & light), monokai, gruvbox and many more. To avoid spending too much time trying them all out, here are some examples of the ones I like the best. If you want to try them in a browser, check out the previews to find the perfect one for your setup.

Be sure to check out the geeky base16-greenscreen theme, it’s awesome.

  • Gruvbox dark
  • Monakai
  • Solar flare
  • Solarized dark
  • The solarized light theme
  • Github theme
  • Green screen!

javascript development with vim

Leave a reply

Vim is great as a lightweight editor for JavaScript programming. But pretty soon I end up missing some more advanced features like syntax checks and code completion. Syntax highlighting only takes you so far.

Recently I was working on a Node.JS project, so I thought I’d find me some plugins for Vim to get those more advanced development features. Vim is super extensible with its massive plugin ecosystem, but sometimes it can take some tinkering to get things to work. After a bit of searching and trying things out, I managed to get code completion working for JavaScript code, and have basic syntax checking active.

I found that the CoC plugin, in combination with some of its extensions work perfectly.

First you need to install the CoC plugin. This plugin is more of a framework to get code completion and VSCode-like features in Vim. So you can use this for other languages too, like Python, Rust, Java, PowerShell, C#, etc. You need Node installed for this to work, but if you’re working with JavaScript, you most likely have that installed already.

Once you have the plugin set up, you then add CoC extensions for the languages you want to use. For JS this turns out to be the TypeScript server plugin, which gives your JS & Typescript support, including JSX and TSX. I also added the JSON plugin.

To add the CoC extensions, open Vim and install the extensions using:

:CocInstall coc-json coc-tsserver

That’s about it. Now if you open up a .js file, you should be getting JS code completion. If you mess up some code, you’ll get some error indications in the margins, telling you something is not quite right with your code.
Handy stuff!

Yep. There’s clearly something wrong with that code.
Helpful code completion info right there.

A good way to find a list of more CoC extensions is through VimAwesome. There’s something in there for everyone it seems.

extend visual studio with simple scripts

Leave a reply

There’s this neat feature in Visual Studio called External Tools that’s underrated. What it does is allow you to run any external tool and pass in stuff from Visual Studio and do something cool with that. For example the current file in your editor, or the currently selected text.

This means that you can write a PowerShell script that gets some input from the command line, and for example edit a file (the current file in VS), or search for a substring (selected text) in other files, or a database.

I’ve used this to do a complex number of find-replaces on the current file in a single run. I also use this to quickly find the source code of a stored procedure that’s used in code, by selecting the stored procedure’s name and running the script.

How do you set this up?
In Visual Studio, in the menu click Tools, then External Tools.
There you click Add and give the thing a title.
The command can be a bit tricky, but the easiest thing is to use a .cmd script, like test.cmd.


Then you create this cmd file, and make sure it’s in your path. You can also use the full path to the script for your command instead.
Now pick your arguments from the arrow at the right of the Arguments input box. I’m using ItemFileName here, but there’s plenty of options.

You’re all set.

As a test script you can use this gem:

@echo off
echo ** Command line parameters **
echo %*
pause

If you want to wrap a more advanced PowerShell script, you can use this:

@powershell.exe -nologo -noprofile -file c:\tools\do-something-awesome.ps1 %*

If you run this from a file now, you’ll see the passed in parameters in the script’s output. Like this:

With this technique you can easily and quickly extend your Visual Studio setup to do some mundane tasks a lot faster, using PowerShell, Node.js, Python or whatever your favorite scripting language is.