Friday 19 June 2015

Unit testing - because Puppet is worth it

The other day I was browsing the slides of "Continuous Deployment with Jenkins", from PuppetLabs. One sentence in particular I found relevant for what I was doing, and important in general:

Puppet manifests are code too.

To be honest, I don't think I need to sale this very hard, so I'll proceed to a practical consequence: unit testing for puppet modules. Unsurprisingly, there's a app tool for that: rspec-puppet.
At least this is what I've been using for some time and find very useful and easy to use. I've even created some Jenkins jobs just to unit test Puppet modules.

You can find a tutorial for rspec-puppet here. Feel free to leave this article, read the tutorial, experiment a little and come back later.

What I wanted to share is some tricks/settings that I had to use, which I haven't found in one single place so far.

As you can see in the tutorial, rspec-puppet generates a dir skeleton for you (with the command 'rspec-puppet init'), to be populated with the tests for your module, then you just need to run 'rake spec' and have the unit tests run.

What I noticed though was that 'rake spec' didn't quite work, or didn't work as expected, and eventually I ended up with installing these dependencies (alas, with reference to a CentOS 7 host):

    package { [
         'bundle',
         'puppetlabs_spec_helper',
         'puppet-lint',
         'rake',
         'rspec-puppet'
         ]:
         ensure   => present,
         provider => 'gem',

    }

Then I found a better Rakefile (although I can't remember the origin, it must come from an official Puppet forge module. If you recognize it give me a shout and I'll give full credits):



The last important bit was the .fixtures.yml file, which allows to refer to 3rd party modules required by the module under testing.
Here's an example:



which basically says: "You can find mymodule in this directory, and please use stdlib from this other directory". In fact, for stdlib you should not use the local path (because it implies that stdlib is installed, and somehow defeats the point of unit testing) but the git URL. Since this installs stdlib from git at every run, I preferred using a host with it installed and refer to the local path instead. Not perfect, but handy.

Only then I could use 'rake spec' with satisfaction.

I hope you find this useful, and if you have any type of feedback please don't hesitate to add a comment.

Tuesday 16 June 2015

git tricks - get latest tag and its distance from HEAD

Problem: "I want to get the git tag of the current project, but only if it's associated to the latest commit. If not, I want to know what's the current commit hash."

In order to achieve this I was using something like:
This works but a drawback is that I either see the tag or the latest commit.
So a coworker pointed me to this:

git describe --tags --always

which I didn't know and it's just great. It returns a string with this format:

TAG-N-gSHA

where:

TAG is the most recent tag.
N is the number of commits from the TAG.
'g' is just a formatting convention.
SHA is the latest commit (HEAD).

If the latest commit is also pointed by the tag, then it just returns TAG.

'git describe' is explained here.

Wireshark setting to interpret UDP as RTP automatically

 Before I forget again, a Wireshark setting that can help saving time by trying to interpret any UDP as RTP, if possible: Analyze --> Ena...