Recent Blog Posts

AnsibleFest 2018 is a Wrap! Slides from my presentation and notes

AnsibleFest 2018 is in the books, and it was a great conference! I was able to attend the 'Contributors Summit' in Austin on Monday, and remotely Thursday, and I learned quite a bit! I also presented Make your Ansible playbooks maintainable, flexible, and scalable on both days of the conference. Slides from that session are available below, but you'll have to wait for the actual video to be uploaded to see the fun little gimmick I added for the live presentation 🙃.

Things I learned at the AnsibleFest Austin 2018 Contributor's Summit

AnsibleFest Austin 2018 is about to get started (with a huge party tonight, then a keynote to kick off two full days of sessions tomorrow), and the day before and after the 'Fest marks the 6th "Contributor's Summit", a "working session with the core team and key contributors to discuss important issues affecting the Ansible community".

AnsibleFest 2018 Austin Contributors Summit

As with most conference-related events, the best part of the day is getting to meet with and talk to people you work with online, but there are also usually lots of little tidbits discussed during the sessions which aren't yet widely known. Some of the most exciting things I learned today include:

Get a list of all a user's public GitHub repositories using GitHub API and jq

I recently needed to do a quick audit on all my Ansible roles, and the easiest way (since almost every one is on GitHub, and that's the main source of truth I use) was to grab a list of all my GitHub repositories. However, it can be a little tricky if you have hundreds of repos. I'm guessing most people don't have this problem, but whether you do or not, the easiest way to get all of any given user's repositories using the GitHub v3 API is to run the following command:

curl "" | jq -r '.[] | .name'

Example output:

Logging in as an existing user in a Behat test with the Drupal Extension

There are some occasions when I want my Drupal Behat tests to perform some action as a user that already exists on the Drupal site. For example, I have a test install profile with some Default Content (users, nodes, taxonomy terms, etc.), and it already has a large set of default test data set up on the site for the benefit of developers who need to work on theming/site building.

Rather than define a ton of extra Behat steps to re-create all this test content and these test users, I just want Behat to log in as an existing user and perform actions with the pre-existing content.

Note that this might not be a good idea depending on the structure or philosophy of your site's testing. As a general principle, state should be avoided—and that includes things like 'having a set of default stuff already existing before a test runs'. However, in the real world there are situations where it's a ton easier to just use the state that exists 🙃.

The problem

Out of the box, the Drupal API Driver lets you create a user in a Scenario and then use that created user, like so:

Review: Wosports Trail Camera for Hunting and Wildlife

For the past few years, I've been tweaking a few different camera rigs for wildlife and outdoor photography. I have set up a few different time-lapse rigs using my Raspberry Pis with Pi Cameras, and I've set up my Nikon D750 in a few different ways with its built-in intervalometer, or with a wireless remote.

This is great, but I've always wanted to set up the Pi with an infrared Pi Camera, as well as a motion sensor, so I could capture wildlife at night. I know there are some animals that peruse the seeds in our yard around the bird feeders, but it's well nigh impossible to capture them with my other non-infrared cameras... and they tend to come out when I'm asleep.

Wosports contacted me and asked if I'd like a discount on their 'Trail Camera' to give it a test, and I thought it was a great opportunity to check out the basic/low-end of trail cameras, so I took them up on the offer.

Wosports Trail Camera


Subscribe to Jeff Geerling's Blog