7 things I learned about GitHub Actions

I’m working on a way to track my fanfiction reading, and using that as an excuse to learn GitHub Actions. I’ve posted 7 new TILs on small things you can do with GitHub Actions and wanted to share those.

My personal experience with learning GitHub Actions has been… interesting. The syntax is very different than what I am expecting, and I don’t always predict correctly whether to use the ${{ }} braces around a variable. I bet if I learned some bash that it would be a bit easier? Maybe? Not sure. But once I muddled through a few of these, I got the hang of the syntax and things are going a little faster now. I still have a ton of questions, and none of it is easy for me, but I also feel like I’ve been bitten by the “automate all the things!” bug, and that’s fun.

• Leaving a comment on a new issue or new PR — could combine this one with labels to respond to first-time contributors, or set an out-of-office response, or just say, “Hi there!”

• Running an action conditionally — AKA where do I put the if statement? Bonus points for a little intro into traversing the API response within the variable syntax.

• Making one job in a workflow depend on another job — Or, how do I make sure this job runs before that job runs?

• Parsing JSON output from a GitHub issue template in a GitHub action — AKA, take an issue template and turn it into JSON!

• Setting output from one step in a job, so a different job can use it — This goes hand-in-hand with the previous TIL about using an issue template to parse data about an issue. I needed to be able to pass the data in an issue into another process.

• Creating a new file and committing is as part of a GitHub action — In this case, I took the data I got from the parsed issue, then wrote some of it to a new txt file, just to prove that I could. In the future, I plan to use this auto-generate yaml files from AO3 links. The dream workflow is opening an issue with the title “TBR” and a link to AO3, then the GitHub actions workflow takes care of tagging the issue, calling AO3, creating the new file, updating the status to TBR, creating the commit, pushing to main, and closing the PR. Not there yet, but soonish!

• Temporarily disabling a GitHub action without touching the workflow file — Some of my workflows are real works-in-progress. I’m flying by the seat of my pants here a little bit, so things don’t always wind up in a “working” state before I need to stop, and I didn’t want to keep merging other work and then getting emails that the workflow failed. So I learned how to disable it without just commenting out the file.

Side note: Thanks to Simon Willison’s excellent post about What to blog about, which inspired me to write this!