My First Week With GitHub Actions

Last week Twitter caught on fire 🔥(more than normal) when GitHub announced Actions 🏃🏃🏃at GitHub Universe 2018.

“With GitHub Actions you can automate your workflow from idea to production.”

“With GitHub Actions you can automate your workflow from idea to production.” Actions let you write scripts that are triggered based on certain events in your GitHub repo (basically any GitHub webhook event) — creating a new issue, pushing a commit, merging a pull request.

Automating things based on events in a GitHub repo isn’t a new idea. For years, people have used CI tools such as Circle CI, Travis CI, Jenkins, and others to automate things by running scripts in CI jobs. GitHub even created the Probot framework to make it easier to create GitHub Apps to automate similar types of things. However each of these approaches requires signing up for additional services, hosting and running your scripts, monitoring, maintenance, and potentially costs you money.

Enter GitHub Actions! Actions are 100% contained to GitHub and your GitHub repo. No additional tools or services or money 😁! You can store your Actions code in your GitHub repo, and GitHub runs your Actions code for you.

The two basic building blocks of Actions are Workflows and Actions:

• Workflows are triggered based on GitHub Webhook events that fire when certain things happen in your repo — creating a new issue, commenting on a pull request, merging a branch. A Workflow runs one or more Actions.
• An Action is a Docker container that runs as part of a Workflow. If you haven’t used a Docker container before — it basically means that you can run anything you want in any programming language you want 👏👏👏. You can store your Actions within your GitHub repo or use other people’s Actions stored in public GitHub repos or use prebuilt Docker images from Docker registries.

Both Workflows and Actions are written as code and stored as part of your GitHub repo and are 100% reproducible from code. That’s super powerful 💪!

If you know me, you know I’m all about finding more time to focus on meaningful work. And one of the best ways to do that is to automate repetitive tasks that aren’t the secret sauce of what is meaningful to you. GitHub Actions promise to be a great way for you to automate the repetitive tasks in your workflow so you have more time for what’s meaningful to you 🙌.

Luckily, my co-workers and I at waffle.io were invited to try GitHub Actions during the beta period. Waffle.io was one of the first companies to release a GitHub App, creating WaffleBot which automates 100,000+ project management updates per month from developers’ existing workflows. Even so, waffle.io users are always thinking up new use cases to automate — some of which are very specific to their context. So what did we do with Actions? We created a basic template to help waffle.io users add additional automation to waffle.io using Actions!

To get started, I decided to create a really basic Action that appreciates a user for creating a new issue and shares info about contributing to the repo. This is useful for large open projects so that contributors know how to successfully get started. I also thought it would be a good basic example of how to create an Action that uses the GitHub API so that others could reuse it as starter code to create their own Actions. You can find more info about how to use the Action and how to fork it for your own use cases at https://github.com/waffleio/gh-actions/.

So what were my first impressions working with Actions? TLDR, the robots 🤖 are one step closer to taking over the world 🌎. I love the potential of Actions!

Loved 👏

• GitHub Actions are really easy to set up. If you’re using someone else’s Action or forking an existing Action to create your own — it takes about 5 minutes to set up your first Action. Winning 🏅!
• Actions don’t require any hosting. A third of the time I spent creating Probots in the past was spent on hosting and maintaining, etc.
• Actions don’t require patching and monitoring like a Probot. Depending on how you set up your Dockerfile and scripts, the latest packages will automatically be used each time an action runs.
• Actions can be written in the framework and language of your choice.

Longed For 🤔

• I think there are probably some great use cases around running Actions on issues. Pull requests have a great way to visualize associated Actions, but issues do not. It’d be nice to see a more obvious connection between Actions and issues to understand which Actions are related to a given issue.
• Actions can be a bit noisy. For example, if you have an action that runs every time a webhook is fired, the action will run every time you create an issue, update its description, check off a markdown checkbox, etc. While you can filter on the action property of a webhook in an action, it’d be great to be able to only have a workflow trigger on a webhook event.action not just an event.
• Debugging Actions can be a bit tedious and time-consuming. It can take a few iterations of making changes, pushing to GitHub, and running test Actions to debug issues. One of the reasons Waffle.io created and open sourced a few sample Actions is to hopefully save you some time creating your first action.

Learned 👨‍🎓

• GitHub Apps and Probots are useful for use cases where something applies to everyone. GitHub Actions are great for uses cases that are specific to you and your team.
• GitHub Actions appear like a GitHub App when interacting with the GitHub API and GitHub UI (ex. when posting a comment to an issue).
• GitHub Actions have almost full permissions to the repo. While Actions use a GitHub App Token, the permissions aren’t configurable like they are in an GitHub App. This should be fine for most use cases since the Actions code is maintained by you and your team.

What will you create with GitHub Actions? I look forward to seeing what you create! Check out GitHub’s Actions docs to learn more.