Browsing...

What do you usually do when releasing a new version of gems? Running test suite? Something more? I like to use my tool on tracking changes in RubyGems gem-compare as it gives me a little bit more confidence on what am I actually releasing. Here’s how I do it.

Since I package and maintain Vagrant and vagrant-libvirt for Fedora, I have a need to test new builds. But since I run just one version of Fedora and I don’t really feel like testing it directly on my host system, I actually use Vagrant to test Vagrant. In other words I run Vagrant with KVM and inside I download the new builds and run Vagrant with KVM again. This is possible because KVM supports nested virtualization. In fact I already wrote about setting that up with virt-manager. But today I show you how to do it using Vagrant itself.

As you probably know, you can use eval() to evaluate Ruby code from Ruby. But evaluating things that come from the outside of the program like user inputs can be dangerous. Why they can be dangerous you ask? eval() evaluates anything as we would program it ourselves. Basically anything can happen. That’s why it’s best to avoid eval() for such inputs altogether. But we can evaluate Ruby in a safer manner too; with $SAFE.

Sometimes it happens that you want to run an old test suite, but you don’t have a correct version of the testing framework available. That happens a lot in Fedora since tooling around RPM supports only one version of each component and new rubies does not come with test/unit anymore. As we still need to run the tests, we have two options. Either go ahead and update the whole test suite to a new version or just use Ruby’s dynamic nature to actually run it. Let’s look how the latter can look like.

Are you tired of putting the same sane configuration options to every Vagrantfile? Here is how to make the life with Vagrant a little easier.