Using GitHub Actions to Deploy your Jekyll Site

Dec 1, 2018
Tags: Jekyll Web Development GitHub Actions

A few weeks ago, I got invited into the limited beta for GitHub Actions. In case you’ve not heard of Actions before—it’s GitHub’s pitch for the future of continuous integration/deployment of GitHub repos. As has been said:

The future has arrived, it’s just not evenly distributed yet. –Apocryphal William Gibson

Is Actions the future? I don’t know, but after playing with the beta for a bit—I do think it’s pretty cool. Even for something relatively straightforward like building a Jekyll site—the immediate advanages are obvious.

  • Want to use those custom Jekyll plugins that GitHub Pages has always blocked? No problem.
  • Want to update your search index with newly built pages everytime you deploy? Sure thing.
  • Want to run some NPM scripts to compress, concatenate, autoprefix, ship, resize, slice, or dice any, some, or all of your assets? Errr…OK.
  • Want to do it all while staying on GitHub…for free? Let’s do this.

Setting Up Your Workflow

Once we have access to Actions we can start things off by adding a do-stuff.workflow file in a .github directory sitting in the root of our repository. Github includes a little visual editor you can use to setup your workflow, but I found this to be more trouble than it was worth. Essentially: our workflow needs to identify itself, indicate a trigger, point to an action, and include any secrets or environment variables the action will need.

workflow "Deploy Site" {
  on = "push"
  resolves = ["Build and Deploy Jekyll"]

action "Build and Deploy Jekyll" {
  uses = "BryanSchuetz/[email protected]"
  secrets = ["GITHUB_TOKEN"]

Building the Action

In the action directory we need a couple things:

  • Dockerfile We’ll use Docker to setup a container within which we can import ruby and jekyll and any other gems we’ll need to build our site.
  • This is where the heart of our action lives. We’ll install all our Gem dependencies, build the site, initialize and setup Git, and then push all the site files back to the gh-pages branch of our repo.
  • Explain what the action does. One of the nicer features of Actions is that creators can expose them in a public repo—so that other users can call them from their own workflows!

Action Log

Try it Out

As mentioned above, I’ve put this action in its own public repository so anyone can point to it and use it to build and deploy their own Jekyll site. Or, just have a look around and see how I’ve sructured things—I’m sure there are efficiences I could make—if you have any suggestions, please let me know.

Concatenate JS for Free with Jekyll

Apr 15, 2018
Tags: Jekyll Web Development

This one’s a stupid little trick, but I literally use it all the time, and I’m always surprised how novel people find it when I explain it to them. Basically: use Liquid includes in a bundle.js file, and let Jekyll smash all your .js crap together for you.

Jekyll will parse any file that has a YAML front matter block at the top of the file. So, just drop one of those suckers at the top of your JS file and include your scripts in the order you need them.



{% include _vendor/turbolinks.js %}
{% include _vendor/isotope.js %}

//More Awesome JS Stuff Below

When Jekyll hits bundle.js it will grab your partials and drop them into the file right where they should be. You may still want to minify, etc.—though your vendor files are probably already ugly. This is a super simple, no overhead, low config way to concatenate all your js crap together—letting Jekyll do what Jekyll does best: parse files.

Viewing AWS logs on the Command Line

Mar 28, 2018
Tags: Serverless Web Development

If you’ve ever tried to quickly check AWS logs from the command line then you know my pain. Don’t get me wrong, the AWS CLI is great and all but—if I just want to quickly double check that a Lambda function has returned what I think it has—it’s kind of a giant pain in the ass. You’ve got to first describe-log-streams for a given log group, grep to find the most recent stream and capture the logStreamName, then get-log-events for the stream (requires logStreamName), and then finally grep for what it is you were hoping to find.

I’d say that this was basically like “living in Mogadishu”—but then I’d have to punch myself in my first world face—so I’ll just say that it’s less than ideal. So, recently I’ve been using awslogs, a nice little Pyhton utility for doing the same type of thing—only more better.

Why better? Because you can do the same thing as above, in a single command.

awslogs get /aws/lambda/myGroup 2018/03/28 -s2h | grep objectIDs -C 1

Basically: get events for the given log group, where streams match the given expression, in the given timeframe—then grep for what I’m hoping to find. I’m sure there must be a better way of doing this kind of thing that I’m totally unaware of but, “works for me”™.

Git Branch in the Bash Prompt

Feb 25, 2018
Tags: Command Line Tooling

Waaaay late on this one—but you know what they say. For a while I’ve had a text trigger in iTerm2 to catch and highlight the currently active Git branch—but it never occurred to me to just add it directly into the command prompt.


Trivial to do, and super helpful—as soon as you open up the directory, you immediately know what branch you’re working in. Below is what the setup for the prompt looks like, just drop that into your .bash_profile and you’re all set.

parse_git_branch() {
     git branch 2> /dev/null | sed -e '/^[^*]/d' -e 's/* \(.*\)/ (\1)/'
export PS1="⚑$RED\$(parse_git_branch) $NO_COLOR\w > "

VS Code: Hope, Hype, and Hijacking

Feb 21, 2018
Tags: Tooling Text Editors

I’ve always been a bit promiscuous with my text editors. The whole chronology probably looks a little something like this:

Dreamweaver => Coda => BBEdit => TextMate => Espresso => Sublime Text => Espresso (again) => Sublime Text 2 => Atom => TextMate (again) => BBEdit (again) => Sublime Text 2 (again) => Espresso (yet again) => Sublime text 3 => Atom (again) => Espresso (yet again, again) => Sublime Text 3 (again) => VS Code.

As you can see, I’m not shy about “picking up stakes” and moving from one to another—and back again. I’d like to think that I’m always hopeful for better features, performance, extensibility, etc.—that I’m always looking for ways to procrastonate, and avoid acutally doing any work with the editor du jour is probably closer to the mark. Nevertheless, my promisquity has given me a pretty good sense for what does and doesn’t make for a good editor.

Espresso App

From a purely UI/UX perspective I still think Espresso is one of the most elegant editors I’ve ever used—unfortunately its workflow model is a bit anachronistic. I really appreciate the thought that went into some of the features like Dynamo—their proprietary static site generator—but ultimately, it’s playing in the proverbial walled garden. And, I can’t remember the last time I used FTP to send files to the server.

Like most, I’ve welcomed our new decoupled, extension based, Git enabled, Electron App overlords—and it’s probably for the best. Electron apps will never be as blazingly fast as a well written native app, but VS Code does “OK”—better than Atom, I think. The Git integration is nice, though I do most of that stuff from the command line anyway. What really gets me are the extensions and the configuration. Granted, it’s a pain in the ass to setup—Sublime is too—and though VS Code makes it easier than most, it still takes a real investment to get everything configured as you’d like. But the good news is that everything, and I mean everything is configurable, and the extensions are killer.

Killer Extensions

All the usual suspects are there: git gutter, file icons, linting, Emmet, syntax highlighting for every language you can imagine (these are much easier to fine-tune to your liking in VS Code). The IntelliSense—Microsoft’s version of code completion/hinting—extensions are what really seal the deal though.

VS Code

Sure, you get hinted to the right method in Ruby, or ES6—but better than that, you can autocomplete on filenames, CSS class names, even Sass variable, mixin, and function names—I never remember that stuff. There’s no lack of hype around VS Code right now—but on the whole, I’d say it’s living up to it.

Hijacking the Community

Honestly, I feel kind of bad for the Sublime Text folks. Atom, and now VS Code are in many ways a direct hijack of the package/plugin/extension approach—pioneered in TextMate and brought to scale in Sublime—to say nothing of the command pallete, and some other directly hijacked bits of UI. It’s telling that the extension which ports Sublime keyboard shortcuts over to VS Code already has 1/2 a million downloads. But just like any other suffeciently advanced technology these days—it’s the ecosystem that really matters. When TextMate was TextMate, there was a vibrant community around it—creating bundles, themes, and addons—this made the editor much more than it could have been on its own. When development of newer versions stalled, the community moved on to Sublime—and did it all over again. Today VS Code has the community mindshare, but what came before is never really lost—most of the syntax files I’ve seen for VS Code are still based on the original TextMate Grammar scheme from 2004.

The Distress Signal is the personal blog of Bryan Schuetz. Bryan has been complaining on the Internet since the 90s. If you'd like to get in touch with Bryan, he can be found.