You might have heard about GitHub launching Actions as a way to automate everything happening around your repo.

GitHub Actions allow you to implement custom logic without having to create an app to perform the task you need. You can combine GitHub Actions to create workflows using an action defined in your repository, a public repository on GitHub, or a published Docker container image.

It's still in beta but you can request early access which I at least got already few weeks ago.

Deploying to Kubernetes

As we're mostly working with Kubernetes nowadays, I wanted to try out how to get stuff deployed from an action. One of the go-to tools we use when deploying on Kubernetes is Mortar, do'h we wrote it :), so naturally I wanted to integrate that into the action.

One of the nicest features of actions, as for many other modern CI/CD type tooling, is the fact that you can use containers as the main vessel for the action logic. For the case of Mortar, there's already a ready-made container available at quay.io/kontena/mortar:0.3.1. So to make that usable in an action is super simple.

The workflow

GitHub actions have a concept of a workflow. You can have as many workflows as you need in a repo and each workflow is triggered by an event happening on the repo. For my sample use case, I want to deploy a simple application whenever there's a push to a master branch of my repo.

So my workflow definition is super simple:

workflow "Deploy on push to master" {
  on = "push"
  resolves = [
    "filter",
    "mortar",
  ]
}

The resolves part tells what actions are part of this workflow. The actions themselves make up a tree by using dependency declarations as you'll see in a minute.

The first step I need to do is to "filter" the actions, I want the deployment to happen only on master branch. Luckily there's a ready-made action for that:

action "filter" {
  uses = "actions/bin/filter@707718ee26483624de00bd146e073d915139a3d8"
  args = "branch master"
}

The uses directive tells the action engine to look for the image definition from the given repo and path. Once it finds the action, it builds the image and executes it. In this case we just filter out anything else than a master branch.

For the actual deployment, we'll use Mortar as it handles templating and manages the set of resources as one "stack". There's a ready image for it available so it's super simple to integrate into an action:

action "mortar" {
  uses = "docker://quay.io/kontena/mortar:0.3.1"
  runs = "mortar fire -c manifests/shot.yml manifests/ my-app"
  needs = ["filter"]
  secrets = ["KUBE_SERVER", "KUBE_TOKEN", "KUBE_CA"]
}

The needs option tells that this action runs only after filtering has been executed successfully.

Naturally my Kubernetes deployment needs some secrets to authenticate and authorize Mortar for Kubernetes API. So you need to set them up at your actions tab in your own repo.

Actions state

As Actions is still in beta, it seems that there's some usability issues to fix. As Jessie Frazelle, among other GitHubbers, has asked feedback on Twitter I decided to collect some of mine here:

  • Add link to docs on the workflow "editor" page; Every time I need to use Google to find the docs. For myself as future reference, the docs are here: https://developer.github.com/actions/
  • Better syntax highlighting and maybe some auto completions would make the editor easier to use; Although the drag-and-drop is nice, setting up even a trivial workflow like in this example pretty much forces one to use the text editor. Too easy to make mistakes.
  • Some local tooling to validate the workflows; I know there's some tooling done by "outsiders", but it would be nice to have some "official" way to easily validate the workflow definitions. Even for this simple example I had to do quite a few "fix workflow" & "fix harderer" commits to get everything working. :)
  • The editor and graphical representation seemed to be out-of-sync few times when you hop between the tabs. I did lose some of the edits on either side. My example is super simple though so it does not matter. If I would've been working on anything more complex I would've been angry.
  • Overall, IMO the docs need more examples to make things a bit clearer. The state of docs is probably one of the reasons it's still labeled as beta. :)

Summary

Overall, the idea of Actions is super cool. It kinda makes the promise of not needing bots or other such things automating stuff around your repo. In some cases you might be able to get rid of even some external CI/CD tooling. I've barely scratched the surface but I certainly think I'll start using Actions more and more.

Photo by Sergi Kabrera on Unsplash