So GitHub Actions went fully GA a couple weeks back, on August 8th, after sitting in beta since basically last October. I'd been on the waitlist since March and forgot about it until a random email showed up saying I could turn it on for any repo I wanted. I finally sat down this week and actually moved one of my real projects over instead of just poking at the Hello World example, and I've got some thoughts.
The project is a dumb little Node script that rebuilds this very blog from a pile of markdown files (yes, techpad runs on hand-rolled tooling, I've never trusted the fancier static site generators to still exist in five years, and given how many of them have come and gone since 2011 I think that instinct has been proven right more than once). It was on Travis CI, which has worked fine for years, but Travis's UI always felt like it was built in 2013 and never touched again. Which, coincidentally, is close to true.
Moving over wasn't bad, but it wasn't "five minutes" either
The workflow file lives at .github/workflows/build.yml instead of a .travis.yml in the root, which is a small thing but it did make me stop and reorganize how I think about the repo. Here's roughly what I ended up with:
name: Build and Deploy
on:
push:
branches: [main]
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v1
- uses: actions/setup-node@v1
with:
node-version: '10.x'
- run: npm install
- run: npm run build
- run: npm run deploy
That's basically it, and it ran in about 90 seconds on the free minutes, which felt fast compared to what I remembered from Travis (though to be fair I hadn't actually timed Travis in ages, so maybe I'm misremembering). The log viewer is genuinely nicer, you get that collapsible step-by-step view instead of one giant wall of text you have to Ctrl+F through.
The annoying part was secrets. I had three environment variables (an API key, a deploy token, and one config flag I'm honestly not sure I still need) and moving them from Travis's settings page to GitHub's meant re-typing all three by hand because there's no export/import. Took maybe ten minutes total but it's the kind of ten minutes that makes you procrastinate the whole migration for a month, which is exactly what I did.
The actual deploy step is where it gets personal
For the deploy itself I didn't reinvent anything, my npm run deploy script just does a git push to a remote that rebuilds and restarts the site, the same git-push-to-deploy setup I've been using for a while now over at Tricknowtech for the actual hosting side of things. So the CI part changed but the deploy mechanism underneath it didn't, which honestly made this whole exercise lower-stakes than I expected. If the deploy step had also needed rewriting I probably would have put this off until October.
One complaint, and it's a real one: matrix builds. I wanted to test against Node 8 and Node 10 at once, the same way I used to on Travis with a two-line array, and on Actions it took a full strategy.matrix block plus fiddling with how the version gets passed into setup-node. It works, it's just more YAML for the same result, and at this point I've typed enough YAML in my life that I get a small headache every time I have to get the indentation exactly right on the first try.
Would I tell you to rip out your existing CI setup this week? No, not unless something's actively annoying you about it already. But if you're starting something new, or if (like me) you've got a project sitting on a service you've been mildly irritated with for three years and just never had a reason to move, this is a good excuse. It's free for public repos, the minutes add up generously if your project's small, and not having to leave GitHub's tab to check a build status is a nicer habit than I expected it to be.
Now I just need to go find the other four repos I've got scattered across Travis and Circle and decide if I care enough to do this four more times. Ask me again in a month.