In the continuation of the Lita development that I've been doing recently, I've found myself needing a more sophisticated development environment for Lita. Running bundle exec lita locally just was not cutting it anymore. My Lita plugin was starting to pepper my hard-drive with various files and the number of services I was needing to manually install and manage on my local machine was increasing. Now, unfortunately the Lita plugin that inspired this work not currently open source, but I've managed to replicate the setup with a Lita plugin that I have open-sourced: lita-announce.
In the past several weeks I've been doing some personal coding on several Lita plugins for the teams that I work on at Chef. Lita plugins are relatively new to me, but they've been a neat way to get some personal coding in whilst also bringing some value to my team. Some of these plugins are small, but others are large and rather complex, requiring helper functions, classes, or sometimes entire gems. What I want to talk about today is a weird quick that exists in Lita v4.7.1 that can impact how you make assertions against test instances of your Handler class.
If you are an early adopter like me you like using the latest and greatest technology. When working with Open Source software however early adopters can face challenges when the latest is not always the greatest. Bugs are a problem in any software but thankfully the community-driven nature of Open Source projects means that those bugs are often reported and resolved very quickly.
That does not mean, however, that a new release of that software is made available to everyone as soon as the bug has been resolved. The release cadence of Open Source project varies greatly from project-to-project and it is unreasonable (and likely undesirable for everyone) if a new release of a gem was made available every time a bug was resolved. The maintainers would be constantly building and users would be constantly upgrading. The internet would be littered with relatively meaningless patch releases for thousands of gems.
So what do you do if you run into a particularly troublesome bug that is causing you grief? You have a couple choices:
- Ignore and/or workaround the problem.
- Downgrade the software to a previous stable release.
- Build the software locally from source.
As of the writing of this post, I am working on creating a Chef cookbook that will manage Ghost, the blogging software I use for my personal website. One of the features of this cookbook is the ability to install a theme from a git repository.
I was working on tweaking the theme for my site in a Test Kitchen environment when I found myself doing something horrific. I pushed over 20 commits to a public Github repository in the span of 10 minutes because I playing with CSS values and I needed my local Test Kitchen instance to download them using the `git` resource.
This is obviously not efficient, desired or a best practice. In this post I am going to show how you can have Test Kitchen pull code from a local git repository instead of a public repository.