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.