:::: MENU ::::

Building an Email Testing Environment with Vagrant, Dovecot and Travis-CI

In my previous post I introduced the testing suite I created for Fetch. Here I want to go through exactly what needed to be done to put that together. This post is a bit longer, and you really don’t need it to take advantage of this package, but it may provide some insight to anyone hoping to do something like this themselves.

For me testing has two major components- it should ease development on the local level by preventing regressions, and it should help me as the maintainer of an open source project by giving me trust in the pull requests that are coming in to me. Travis-CI, an application I’ve been using extensively for my projects now, makes that last problem much easier as it will run my test suites and tell me right in the pull request if any problems have come up. On the local level I decided to use Vagrant, as it makes adding virtual machines to source control (without adding a huge binary file) really simple.

Continue Reading

Announcing a New Continuous Integration and Email Package using Travis-CI and Vagrant

Years ago I wrote a library, Fetch, which was designed to read email using the PHP IMAP Extension. At the time I did not expect it to get much reuse so I skipped out on much of the test suite- if I’m going to be perfectly honest here though I have to admit that a huge reason for not building out a test suite then was that I was unsure how to go about it. Building a test suite for an email library has some very interesting requirements, especially if you want to test it in as real world a setting as possible.

  • You need a mail server.
  • That mail server needs a variety of messages, folders, flags and attachments for all the for different types of tests that are needed.
  • Those messages have to remain consistent between test runs.
  • Resetting the mail server to it’s original state should be fast to encourage lots of testing during development.
  • The test suite, and thus the mail server, need to be portable so other people can run tests on their changes.
  • Continuous integration (integrated in with something like Github) is really really nice.

Unfortunately for me all of my great excuses have vanished, thanks in large part to Travis-CI and Vagrant. Both of these systems are fantastic for testing. Travis is a continuous integration environment that’s setup for a number of languages and has direct integration with a number of services such as Github. Vagrant makes sharing server environments as easy as passing along a configuration file. With the two of these tools I was able to put together a testing package for Fetch that met all of those requirements, and after a bit of additional work I’ve broken that up into a stand alone package for people to use in their own projects.

Using this is really simple- you just need to call SetupEnvironment.sh before each run of your test suite. Once that is finished running you have a fully functional Dovecot server with a consistent set of messages. It doesn’t matter if you’re running this from your home computer or if it’s run on Travis-CI, as the SetupEnvironment.sh script will recognize where it’s being run and work accordingly.

There are also some cool optimizations to make testing faster. The test environment will stay up and running for a half hour after the last test before shutting itself down, so you don’t have to wait for the virtual machine to boot between tests. Rather than start from a blank slate each time, the environment has a reset function that restores the original inboxes. With an already provisioned test environment there is almost no overhead by this package between tests, as resetting the inbox takes only a couple of seconds.

The project is up on Github at tedivm\DovecotTesting, so if you’re writing an email reading library there’s no more excuses. I’ve also put together a more detailed post describing how this was put together.

Upcoming Github Enterprise Vulnerability Disclosure

Earlier today I discovered that, due to a vulnerability with Github Enterprise, I still had access to resources at my former company that I really shouldn’t have. After reporting it to those guys so they could lock it down on their end, I reached out to Github themselves so they could repair it on their end and push out a fix to their own customers.

Their response was that they didn’t care. I received a form letter stating that they were “aware of this and similar issues”, and that they’d be working on improving it in the future.

Sometime this weekend I am going to be writing a blog post describing how former employers of a company can access the repositories and data inside Github Enterprise installations, because apparently Github as a company gives no fucks and it’s public disclosure time.

If anyone knows anyone at Github who might actually take this seriously please feel free to send them my way. I would much rather do this the proper way if possible.

WordPress Syntax Highlighting for YAML

I was writing up a new blog post that had some Yaml config files in them. I’ve been using the Syntaxhighlighter Evolved plugin for this, which has worked remarkably well. Unfortunately it seems that Yaml is not one of the supported languages, and I couldn’t find much about it.

Luckily for me the author wrote a fantastic blog post about extending his plugin, which I used to create my very first WordPress plugin. If you’re looking to add Yaml highlighting to your blog you can grab my SyntaxHighlighter Evolved: Yaml Brush plugin right off of the WordPress Plugin Directory. The first version is pretty simple, but I’m considering collecting a few different languages together for a more comprehensive pack.


As part of maintaining Fetch I have to install the php imap extension quite a bit. Although this is pretty trivial on most variants of linux it’s kind of a pain for OSX- you have to find a few dependancies, compile the imap c library from source, create the extension against your currently installed version of php (which typically won’t include it’s source on the system), and then take that one resulting file and set it up.

After doing this for the millionth time I decided to script it, and like any good programmer I looked to see what was already out there. I found a script by Ivan Vucica for an older version of OSX and then polished it up. My version should work on more than just OSX, although in most cases you’ll want to use the system package manager in that case anyways.

I’ve posted the code and a Readme on Github, and have thrown together a first release. Please let me know if you find it useful!

Planning to Go Down, HTTP Edition

Whether it’s from a planned upgrade or a blown RAID, your site is going to go down eventually. This was brought to light for a lot of people by a recent outage on Hacker News- an outage that was made worse by HN responding with 200 Status Codes. During the subsequent discussion I posted a few quick pieces of advice which got a bit of attention, so I thought it was worth writing up a real post about it. Since this all started with a website and a status code it’s only fair to focus the attention on HTTP and how it can be used to help.

Continue Reading