Let’s wrap this up. In part 1 of this blog series, I explained the different Windows build targets supported by PostgreSQL. In part 2, I showed how to test patches for Windows compatibility and how to easily spin up a Windows environment for testing and simple development. Now, in this third and final part, we’ll do what good programmers do: We’ll automate it.
There are a number of services out there that you can point to a GitHub (or GitLab or Bitbucket or …) repository and have it build your code at every commit. Travis CI is a popular one of these, but there are others. Most of these only support builds on Linux. But there is also a service that supports builds on Windows, and that is AppVeyor. So let’s hook up a PostgreSQL build with that. Let’s use GitHub here for simplicity, but AppVeyor also supports other Git services.
To get started, create an AppVeyor account, push the PostgreSQL code to a repository on GitHub, and connect the two. I have https://github.com/petere/postgresql and https://ci.appveyor.com/project/petere/postgresql, for instance.
All you now need is a .appveyor.yml file in your repository to tell AppVeyor what to do. I have just posted the files that I use to pgsql-hackers, so you can grab them from there. Note that there are three files for the three different build variants: MSVC, MinGW, and Cygwin. Perhaps it would be useful to combine them somehow, but it‘s not clear to me how to do that without creating a giant mess. So just commit the file you want, push your branch, and let it build. If you need to test multiple variants, just git reset --hard HEAD~, commit another, and push again. I have used this system for a few months now, and it’s been very helpful.
Alright, that wraps up my travels around Windows for now. As I mentioned at the outset, Windows is not my primary development environment, so this was to a large part an exploration for my own benefit. I hope it’s useful for others and makes managing the Windows support in PostgreSQL less daunting.