Adam and Jerod talk to Kyle Daigle, the Director of Ecosystem Engineering at GitHub. They talk about GitHub Actions, the new automation platform announced at GitHub Universe this past October 2018. GitHub Actions is the next big thing coming out of GitHub with the promise of powerful workflows to supercharge your repos and GitHub experience. Build your container apps, publish packages to registries, or automate welcoming new users to your open source projects — with access to interact with the full GitHub API and any other public APIs, Actions seem to have limitless possibilities.
Kyle Daigle: Yeah, Jess is 1,000% cooler than I am, and so unfortunately I will leave that to her, but hopefully she can come on. Basically, with Actions there’s a couple of moving parts. You mentioned the visual editor - we make it easy for you to go in, and you can drag and drop and basically say “On a particular event” - and this is generally like a webhook event; so when a pull request is opened, when an issue is opened, when something is pushed, when a ref is deleted, all those sorts of things - I would like you to run an action.
In the visual editor it’s easy to see that you can also parallelize actions. So “I would like you to run these two actions.” Then as each action completes, it will go down the line, and so on. So you can create this interesting dependency list where you can parallelize to two separate actions - “I’d like you to run CI over here, and I would like you to check dependencies. Then if both of those pass, I want you to package this and push it up to the registry”, for example. So the visual editor makes that very clear.
[27:48] Under the hood, we use workflow files, and the visual editor ultimately goes down to that. The workflow file is ultimately a subset of HCL, the HashiCorp language - if you’re familiar with any of those products, it’s a very similar syntax; it’s not completely it, but it’s a subset. We chose that in part because we wanted to make a workflow file that was very clear to understand, that didn’t have a lot of cruft; it was human-readable, which was the primary concern… So we looked at all the obvious suspects - YAML, JSON and so on, but ultimately landed on this, because we thought it was honestly aesthetically-pleasing, which we thought would be a very important part of how easy it would be to feel these things out as human beings. So that’s the first piece here.
Now, skipping from the workflow file to an individual action, an individual action is ultimately just a Docker container. That container can do basically anything you can fit inside it. You get a single CPU, with some memory, that will take care of what your action is trying to accomplish.
If you look in the open source examples of what actions can do, usually you see the Docker file saying where we’re actually going to run this thing, what it does, so on and so forth. Any Docker container should work; there’s some limitations around exactly what we let you do with Docker, but we’re working with the community to make sure we’re making it as broad as it’s possible. Each one of those gets a couple of things for free; each action gets a GitHub token for free, and it also gets a checkout of the repository that you are working in for free. In this way we’re trying to make it very simple for you to do things like “Run these tests. Go look at these files in my repo, and then call a GitHub API and create an issue” etc.
The Actions environment is ultimately a VM where we’re running these actions on your behalf, and we’re using that VM boundary primarily for the security concerns that we have. We do some interesting things with Docker to make it a little bit more secure and so on, but ultimately, at the end of the day all of this code is going into a VM for us to run for you.
In between all this we have a couple of services that help us do this. GitHub is generally notoriously a monolithic Rails application, but in this instance we have the launch editor itself, which is the drag-and-drop and workflow file piece as its own service… Ultimately, the tool that actually receives these events and decides whether a workflow needs to be run as its own separate service, and then ultimately the tool that is running the code and sort of orchestrating and scheduling it is a separate service as well.
So that’s kind of the very quick overview of how a workflow file visually, or a workflow file-wise triggers these actions based on events, and then ultimately these actions are all run inside of a VM, which has access to the GitHub token, the repo, and then also some secrets if you wanted to put some outside tokens, and we support all that and keep it encrypted as well.