I have been diving deep into Github actions for about a month now and they are wicked good! They allow you to run any sort of arbitrary code based on events in your repo, webhooks, or schedules. They are very reasonably priced. The interface that GitHub hs developed for them is top-notch! It's so good I have done 90% of my editing of them right from github.com.

TLDR

interactions to your repository triggers code to run.

The online editor for actions is pretty amazing. When creating a new workflow it automatically sets up a new blank workflow or a workflow from the marketplace for you in your .github/workflows directory. This is all it takes to get an action running, a yaml or yml file in the .github/workflows directory.

The editor does a great job of detecting syntax errors, misplaced keys. It also does a great job at autocompletion. As you type it will suggest keys that are accepted by the workflow syntax. There is an embedded side pannel with docs and the marketplace to the right.

see this article from GitHub for a full set of details: https://help.github.com/en/actions/reference/events-that-trigger-workflows

You can trigger actions to run based on about any interaction with the repo that you can imagine, push, PR, webhooks, follows, create a branch, delete a branch, deployment, fork, wiki, issues, comments, labels, milestones, just check out the GitHub article for the full list.

The most common and default trigger you will come across is the on push. This means that on every push/pull_request the given action will run. This is typically at the start of the file and will trigger the workflow for the whole file.

# Trigger the workflow on push or pull request
on: [push, pull_request]

You can also filter to only run on specific branches. You probably only want to run your release workflow on the master branch, but want linting and testing on all branches.

push:
  branches:
   - master
pull_request:
  branches:
    - master

It is also possible to set up your workflows to run on a schedule. I have set a few of these up myself to do things such as updating/auditing npm dependencies and checking if the site is up.

on:
  schedule:
    # * is a special character in YAML so you have to quote this string
    - cron:  '*/15 * * * *'

One issue that I have with GitHub actions is that there really isn't a good way to manually run workflows. A workaround I found is that you can run a workflow when the repo is starred.

on:
  watch:
    types: [ started ]

If you have a public repo with some traction, you might want to avoid this hack, but if you did want to use it on a repo that may potentially get some stars randomly make sure that you filter to only your stars.

on:
  watch:
    types: [ started ]

jobs:
  run-on-star:
    runs-on: ubuntu-latest
    steps:
      - name: ✨ you starred your own repo
        if: github.actor == 'WaylonWalker'

GitHub offers quite a generous free tier to get you started.

I think that GitHub's pricing just shows its commitment to the open-source. Any public repo has unlimited build minutes! I believe this goes for not only Linux actions, but the more expensive windows and mac actions as well.

You will find that a lot of actions need things such as a GitHub personal access token. You may even be hitting a third party API such as twitter or Gmail that require an API key. These are things that need to be kept secret DO NOT put these as raw text inside your action. The first tutorial I followed to deploy to GitHub pages did this 🤦‍♂️ and I followed.

GitHub offers a wonderful secrets manager. From your repository go to settings > secrets. You can just add settings/secrets to the URL of your repo to get there as well. From there add a new secret. Now your secret is accessible by secret key using ${{ secrets.<your-key> }} from anywhere in your workflows yml file.

GitHub has done an amazing job at hiding these secrets. Anywhere that I have seen try to echo these secrets out into the console or anywhere just shows ***. I am not sure if you can 100% rely on this, but they appear to have done a good job with it.

One great feature of actions is the live logs. As you are developing them it is likely that you are anxiously watching them with anticipation. Watching those logs go, and turn green is a great experience.

As with all things open source, much of the power of actions comes through the community and in actions case the marketplace. Reusable actions can be deployed to the github marketplace. Here they can be found from search, starred, and example workflows can be copied in one click.

I find that many times while I can write all of the code necessary in a shell script to do most of what I need, there is already an action in the marketplace that takes care of everything for me. In fact there are usually several to choose from.

• What Actions are you excited about?
• Are you using actions today?
• What struggles have you encountered with actions?
• Do you like these silly image headers I used? Do they kill A11y? I attempted to use good alt text to counter.