Getting colorized output from Molecule and Ansible on GitHub Actions for CI

For many new Ansible-based projects, I build my tests in Molecule, so I can easily run them locally or in CI. I also started using GitHub Actions for many of my new Ansible projects, just because it's so easy to get started and integrate with GitHub repositories.

I'm actually going to talk about this strategy in my next Ansible 101 live stream, covering Testing Ansible playbooks with Molecule and GitHub Actions CI, but I also wanted to highlight one thing that helps me when reviewing or observing playbook and molecule output, and that's color.

By default, in an interactive terminal session, Ansible colorizes its output so failures get 'red' color, good things / ok gets 'green', and changes get 'yellow-ish'. Also, warnings get a magenta color, which flags them well so you can go and fix them as soon as possible (that's one core principle I advocate to make your playbooks maintainable and scalable).

How to shoot a large event (photography gear / workflow)

Jeff Geerling shooting photos with Nikon at Steubenville Youth Conference
Shooting with a Nikon D7100 and 70-200mm f/2.8 VR (photo by Sid Hastings).

I love taking pictures. Specifically, I love taking pictures at meaningful events where people show a range of emotions, and enjoy interesting environments and situations. I've been honored to help at a few large events year after year, such as the Ordination Masses for the Archdiocese of St. Louis, or the Steubenville St. Louis Mid-America youth conference, and I thought I'd try to write an article detailing my workflow with tips and techniques for other photographers getting into solo event photography.

Simple Git feature branch workflow

After reading A successful Git branching model [], which I consider one of the best graphical/textual depictions of the ideal Git model for development teams (and most large projects), I simply wanted to adapt a similar (but way less complex) model for some of my smaller sites and multisite Drupal installs.

Since I'm (almost always) the only developer, and I develop locally, I don't want the complexity of working on many branches at once (master, hotfixes, develop, release, staging, etc...), but I do want to have a clean separation between what I'm working on and the actual live master branch that I deploy to the server.

So, I've adopted a simple 'feature branch model' for my smaller projects:

  • master - the live/production code. Only touch when merging in a feature or simply fixing little bugs or really pressing problems.
  • [issue-number]-feature-branches - Where I work on stuff.


My Simple, but Nerve-Calming, drush Update Workflow

Just posted for my own reference - here's my workflow for updating a D6 (probably also D7) website using drush. Comprehensive information about all drush commands can be found on the website. If you're not yet drinking the drush kool-aid, you need to—if you use a Linux server, of course.

  1. Visit admin/reports/updates page on your site, read through any relevant release notes for required updates (to check if there are special requirements for said update).
  2. $ drush @site pm-updatecode  (add all modules to be updated)
  3. $ drush @site updatedb (updates the site database - update.php)
  4. $ drush @site cc all (clears all caches on the site)

The reason I do this manually, instead of running something like pm-update or pm-updatecode is that I like the granularity and security of doing all the updates discretely—especially when I'm updating a larger site, where I like to know exactly what's happening when I update.