A Japanese automata theater in Osaka, drawn in 18th century. The Takeda family opened their automata theater in 1662.
By 竹原春朝斎 - 摂津名所図会, Public Domain, Link
One of the things I have played a lot with at work and on personal projects recently is the automation of tasks using GitHub Actions. Maybe you've done the same elsewhere, such as in Argo Workflows, Jenkins, CircleCI... But so far the experience with GitHub Actions has been the best for me and given they're mostly compatible with Gitea make it a bigger deal for me personally, as I wouldn't like to be "locked-in" on proprietary software.
Recently I had to integrate benk-uk/workflow-dispatch at timescale/docs, so we could trigger internal builds on our private documentation website repo adding newer content from this public docs content repo.
Since it's all workflow_dispatch, you can still define inputs to be sent. In our case, we send the origin branch name and PR number from the docs, so we can generate the previews based on this information, useful for distinguishing the URLs, for instance.
We can now also define the target branch from the ref parameter, making it easier for testing and previewing newer features before they're live, such as custom markdown syntax, new components, and so on.
And this is just a fraction of the power of workflows! I have a fork of a custom action called godot-export written in TypeScript that I use to build and generate the artifacts for my Steam games for Windows, MacOS and Linux. The fork was created initially just so I could add specific steam DLL/SO files for the Steam integration. Nowadays, I believe this could be achieved with the original action as well, but again, this shows how easily you can extend behaviors by yourself. It's so convenient to write custom workflows since they support Node.js, Python, Go, and more...
If we wanted to go further with this, we could for instance add a step with the setup-steamcmd action, and use their CLI to send the artifacts directly to Steam. How cool is that?
As with anything else, there are concerns to be taken into account, specially regarding security1 and pricing — think an automation to run hour long tasks at your company multiple times, they won't be happy at the end of the month.
Of course, if you're already familiar with CI/CD, any of this shouldn't be news. But based on my personal experience, many people disregard the importance of these tools and just take it for granted, maybe because there's already a well-defined DevOps team and making releases always seemed smooth for you and since it just works, why even open the workflows folder to see what's inside?
At times some people just remember there's something under the hood when a workflow starts failing, maybe due some expired or revoked token (been there after a colleague left the company and we used one token created from their account). Having to fix, extend or create new workflows generally ends up being that postponed task that no one wants to tackle, but I ask you, why? I recommend diving on it when the opportunity come, it might be eye opening and you start seeing new places that could benefit having that, maybe your projects would be easier to maintain with some automated validations or binaries distribution. It's surely a great skill for your toolbelt.
What else can you do with them...
Recently, I started contributing a bit more to the local GDG group from where I live and, during the website overhaul (last update was 5 years ago!), so I added a workflow file to simply build the Next.js project and deploy it through GitHub pages after every push. Nothing fancy — but does everything we need!
A Little Game Called Mario, an "open-source, collectively developed hell project"2 has a whole suite of workflows for:
- Validating the game dialogs JSON file
- Validating and reporting warnings for collisions masks and layers
- Building the game on each PR to validate nothing is broken
- Deploying the previously built artifacts to a Netlify preview link(!!)
- Producing the game credits based on contributors(!!!)
- And of course, building and publishing the actual game build
Isleward, an open-source moddable roguelike MMO3, has in their .gitlab.yml uses it for running npm audit, linting both client and server packages and even building docker images for the game.
Bevy, an open source refreshingly simple data-driven game engine built in Rust4 goes further and use actions to check for visual regressions! That might not seem so cool for web folks that have done the very same for web pages, but come on, we're talking about a game engine, much cooler.
Example Bloom screenshot that went through Bevy's visual regression test
Leaning to game development examples is a good way to "extrapolate" some ideas of what can be done thinking outside of the box, since usually there's more freedom than in a company environment and interesting ideas emerge from people working on creative projects.
Thanks to manokara for helping review this post and for mentioning the Bevy example!