GitHub Actions is the next big thing

Kyle, you’re a Director of Ecosystem Engineering, and I think it’s the first time I’ve seen that title; I know what ecosystem is, and I know what engineering is, but when you combine them, what does that mean?

Yeah, really it’s what a lot of other companies might just call their external platform team. For us, the ecosystem is responsible for all of the APIs, the API-based identity, the marketplace which lets folks find integration and lets integrators make money on their integrations, in some ways it’s also billing, and things like that; it’s tying everything together to make GitHub be useful to you, without just GitHub, if that makes sense. The kind of fastest way to explain it is just if it is integrated with GitHub, it usually comes through one of our teams.

And you direct that.

I direct that. It’s not as glamorous as being on a film set, I don’t have my own chair with my name on it, but…

Bummer!

Oh, come on…!

I know. You would think working from home I could just do that, but I’m pretty sure my wife wouldn’t find that…

Well, you can get your own chair, right?

I know, but I feel like that’s even more presumptuous.

He’s got other people to do it.

Exactly.

[laughs]

At this point I am solidly into engineering management, and I manage other managers who are running these teams, so I’m able to work with some extremely smart people that know their area very well, and then we just work together cross-functionally to ensure that as someone’s adding something to the GraphQL API, we’re also considering how that impacts GitHub apps, and OAuth, and so on and so forth.

And part of that, you were on the platform team, so it’s similar but not the same… Am I correct in that?

Yeah. One of the things that GitHub really spent a lot of time on in 2018 is figuring out how to make GitHub more of a platform for software development, instead of necessarily a feature company. We obviously do Git hosting, but that’s just the bread and butter. We also have code review etc, but then what we saw was 60% of our users and organizations were using some sort of external integration; they were using CI, or they were using project boards, or something like that… So GitHub created a platform group which comprises a lot of both the API side, but also the actual compute, the execution side, how we connect with all these companies, how we store data, how we run arbitrary code - all those sorts of things inside of this platform group.

[04:20] So we focus on how to make your experience on GitHub better by using something else, whereas the other half of GitHub’s Engineering Group is responsible for how to make GitHub the best GitHub it can be, including our client apps that are attached to that. So we have a dual audience of the consumer and sometimes the consumer and a business in between us, that facilitates that.

And I guess the other side of that too is the Marketplace; you are a part of the GitHub Marketplace, so you played (I’m sure) a pivotal role in the creation of that and the inception of that. What was that like?

Yeah, so one of the things that’ve been really tricky for integrators is that we had a bunch of really great innovators that have been around for a while. Travis CI started working with open source, and then we’ve got in folks like Waffle, and ZenHub, and CircleCI - all of these companies that have been around for almost as long as we have, or at least as long as we’ve had the API, right? The thing that I was curious about was folks are finding CI tools pretty readily; nowadays almost everyone uses CI to some degree, or at least knows you should be testing your code. As you go down the pipe though, project management becomes a bit more interesting - static code analysis, security independency management, which is sort of the hot new thing this year, with all of the more recent compromises of packages, and so on… How do you find and know about these verticals, never mind the tools?

So we started with something we call the Integrations Directory, which was just like raw listing all of these things out, which really helped customers find these new things, but the next step for me was what developer out there or small business is building an internal tool, or building a tool for themselves and they wanna bring it to market? That takes so much work and so much time to do the billing, do the processing, do all that stuff. Instead, I was hoping that we would be able to bring new things to market, and not just sort of capture the existing great companies that there are… So Marketplace for me was really about that - getting these new, interesting tools that maybe you haven’t heard about because it’s run by a tiny team, or is brand new, in front of the 30+ million software developers. So that’s been the big journey for that product, I think, in the past two years it’s been around.

Certainly a plan of exposure for, as you mentioned, smaller teams. So if Jerod and I got excited one day and we were like “Hey, we wanna compete with everybody who does CI and CI”, given that we may be willing to share a percentage of the income with GitHub - which we wouldn’t mind, right Jerod…?

Sure.

Then Marketplace would be a smart place to begin, because what’s the barrier to entry, right? It’s getting a listing and maybe being accepted; is there criteria for being accepted these days, or is it sort of more loose?

There’s some pretty simple criteria. It’s really that you kind of have to have some traction on your side, so we can prove to some degree that users find this valuable, and this isn’t sort of a non-used integration. One example I have is Pull Reminders, which I’m not sure if either of you have heard about, but it’s a really interesting integration that a gentleman Abi Noda built. You can even google Pull Reminders and look up his story, it’s really interesting. He basically built this side thing, he ended up selling it in the GitHub Marketplace, and it makes enough money now where this is his thing; it’s his one thing, and all it really does is it looks at your pull requests and it reminds teams and people to review them if they haven’t reviewed them in a timely fashion.

[07:54] So smart.

So it’s not even competing with CI; it’s that niche tool, that in most cases there’d be no financial reason to try to do, if that makes sense… The barrier to entry would be too high to go convince a company that you should use this one-person tool. But because they get into Marketplace and we take away a lot of it, and they can in some ways be next to these large players, now we have a tool that really helps our own customers and us do this one tiny thing… And I think honestly that’s where I think developer tools will be going in the next couple years - less of these huge “We do CI, we do static code analysis”, and much more like “We will run this one type of file for you” or “We will just do Ruby dependency management” or whatever, versus “We have to do everything”, because it’s gonna become so much harder to compete by trying to do all of these things at once.

And clouds, and while GitHub may not be a “cloud”, it’s similar in the way that cloud infrastructure allows you to be a software vendor inside their cloud.

Yes, and I think if you look at Microsoft, Amazon or Google, you see them encroaching into the developer tool space, because if your value-add is a percentage of improvement on top of raw CPU, if that makes sense – so like CI, I would say, is primarily running the code. There’s all kinds of amazing features that get added on top of that that make that more valuable, but the real raw cost is that incremental improvement. It’s like AWS’s Git repo hosting - it’s an incremental improvement on top of CPU and storage. If your developer tool is just that, its primary market is a bit more than cloud hosting, you’re always gonna struggle, in my opinion, because those companies are gonna make more money on their own CPU than you will by buying their CPU.

So it’s really about how do you change the developer experience and give more than just what a CPU or an SSD can, with some incremental improvement… Which is why I think folks like ABI are doing something really interesting, where a company will pay dollars per user to get access to that tool, because it’s creating a new experience for that team, that will have a much larger effect on the overall productivity than, say, “I’m gonna create a CI that works across ANY cloud platform”, because those cloud platforms are all entering that space anyway.

So as you talk about changing the developer experience, the main thrust of this conversation is the new, shiny GitHub Actions, which will definitely change the developer experience.

Yeah.

It seems to be complementary to Marketplace in certain ways, and perhaps as an outsider’s view, it seems like it’s at odds with Marketplace, potentially, in other ways; maybe we can talk about that a little bit later… But GitHub Actions - you all announced that at Universe in October, and there was a lot of interesting conversations around what Actions is and what it implies. I liked James Governor said over at RedMonk, he called it “Low-key revolutionary”, which I thought that was a nice compliment… And he says “GitHub Actions feels like a profound launch, one that will prove extremely disruptive in the long-term.”

Take us back to the launch of GitHub Actions – well, first, for those who aren’t initiated, didn’t see Universe, or haven’t been inside the public beta, tell us what GitHub Actions is, and then we’ll talk about the announcement launch.

Yeah, sure. GitHub Actions allows you to have workflow automation inside of GitHub. Going one step less vague than that, we are running code for the first time - that’s really the big change here - and we’re giving you tools in order to run that code in a singular workflow. And each of these little pieces is called an Action. You can put actions next to each other in a workflow, to ultimately accomplish something. That can be things like building and deploying, it can be checking for best practices, if those are happening, by running these little actions (that are ultimately just Docker containers) on your behalf, inside of this workflow.

[12:00] Since we’ve released, in this beta, all of the actions are open source from our side; folks are writing new ones, we wrote some initial ones… The workflow is just a file inside of your repository, and we’ve been adding more and more folks to the beta at this point, just to kind of get more and more feedback as to what they like the most about the feature.

I would say as a developer, really, GitHub’s running code on your behalf for the first time. That, I think, is the “low-key revolutionary” thing that RedMonk said.

Yeah. That’s why it’s potentially extremely disruptive. Announced in October, still not public-public; it’s in beta, so people are out there, playing with it. We’ve been in the beta, got to play around with it a little bit - very cool stuff, but man, there is a lot going on here. So you have this cool visual editor, you have this workflow file, which is kind of a DSL for describing these things… Obviously, you’re writing arbitrary code inside of containers, on your infrastructure, so the security concerns – probably concerns with load, and people using it for all improper reasons, so…

Of course.

…I guess my question is how much work was this, and how long have you all been working on it?

Yeah, so it was a lot of work. I would say about a year from when we announced it, we wanted to really tackle the problem that we started to see in customer usage of GitHub, which is most folks do something integration-based, like I mentioned at the beginning. They use an outside tool… And then there’s an issue, because when you use CI, for example, and then you ultimately have to deploy, those two systems need to talk to each other in some way, generally speaking. If you’re using a continuous deployment workflow, your CI runs, it passes, and then you deploy.

So what we kept seeing were these workflows that each integrator either had to work with each other to make work, which was always gonna be a one-too-many problem, or the customer would have to put all their pieces together; they might use an external CI, but they use an internal deployment tool, and those things don’t talk to each other.

So we kind of did an exploration around this idea of what would it be like to run your workflow within GitHub, so that way your workflow is a lot closer to your code. We always want you to use whatever tool you think is right for you, whether that’s the one (candidly, in a lot of companies) you’re forced to use, and add in things that you’re more excited about - better CI tools, better project management tools, better packaging tools, whatever - inside these flows.

Initially, when we started to look at this, we were sort of looking at a pure workflow conduction aspect. We would have a way for you to define all this, and then we would just go out to integrators, and talk to them and tell them what to do…

Oh, I see.

But what we ultimately sort of landed on was what I think made pull requests so valuable, is “What would happen if we just let the customer do what they wanna do, and not be a facilitator of workflow, but just be raw ‘What are you trying to do? Are you trying to build your Docker container? Great’, and then push it up to a registry.” Like, we shouldn’t say “Okay, we’ve integrated with these four, so you’re good to do.” Or tell integrators, “Now you’ve gotta integrate with this new thing.” It’s “Okay, let’s just give the customer the raw compute.”

Over the course of that year when we were trying these ideas, and working with customers and showing people internally, and with our partners, we sort of made the shift to what you were alluding to, which is the much, much harder problem - arbitrary code execution; but at the end of the day, now that folks are starting to use it in the beta, we’re seeing so much really interesting usage to this… Because there’s the obvious stuff of “Okay, great, I can build or I can run CI”, or whatever, but then there’s all the little friction things that you do every day when you write software, like “Every time I open a PR, I have to label it with ‘Work in Progress”, or whatever your organization asks you to do. Why not just let Actions do that? And it’s right next to the code, so folks can iterate on that, and you don’t need to go and ask for a server to be spun up, or go spin up a Heroku Dyno and make sure that never goes down, and all of those little things that almost any software developer has had to do. Just say, “Okay, great. Define it in a workflow file, hopefully there’s already an open source action, and we’ll run it for you.”

[16:16] Two thoughts on that… Well, I guess a thought and a question. The thought is that it seems very much in the spirit – the way you guys landed on seems more in the spirit of Git itself, which doesn’t dictate to you “This is how you will use me”, in terms of “This is your branching model” or “This is your collaboration model.” Git is a power tool, but we can all kind of use it the way that we want to, in certain ways; that’s why we have tutorials on Gitflow, and “This is how you should do this, this is how you should do that. Should I rebase? Should I force-push? etc”

So really the model that you guys picked seems like it’s in the spirit of Git itself, which is kind of neat. Maybe speak to that, while I try to remember my actual question.

[laughs] Yeah, it is. I think the issue which I think you can see with Git and Git adoption is that freedom creates a lot of overhead, because you have to know all the workflows, and everyone can have a slightly different workflow - how to create a new branch, or what your forking model is, and so on and so forth.

With Actions, we decided to start with what I’ve been calling “the prosumer approach”, which is “Okay, you can do anything.” But I think what we fully expect is as folks put together these workflows, that we can start to say “Oh, you’re a Ruby web app and you want to package your app, or containerize your app” or whatever; or you’re a Ruby gem and you want to push it up. We should be able to make it easier for those folks by just saying “Okay, here’s the workflow for that. Here’s what the community has sort of definitely said is this.” Or “Here’s what Kyle uses. Kyle prefers this workflow”, and that to me gets us closer to the Gitflow model, which the community has kind of rallied around, to some degree.

So I completely agree with you that instead of trying to be predictive of our customers’ needs, we’ve figured – we all have our custom setup with IDEs, we all have our customer way that we do all our little things; let’s not presuppose that we’re gonna mail that, and just say “Alright, we’ll give you the hard version first, and then as the community sort of figures out what works best for them, we can start to show you via Marketplace, for example, these complete flows that then you could use.”

It’s similar to Heroku’s Buildpacks idea, where you can write a buildpack from scratch, but most people don’t have to, because “Well, is there a buildpack for Elixir and Phoenix? Sure, there is. I’ll just go use that one, and I don’t have to worry about the nitty-gritty.” Same with workflows - once we have the repository of awesome actions, as Adam found actually exists on GitHub, and I’m sure it’ll be like an official Actions place where we can share (I’m not sure, maybe there will be), and you can just go grab what you need, and then you’re helped without having to actually know all of the details themselves.

I did remember my question… It seems like the small stuff that you’re talking about, the minor grease added to our workflows that will help developers’ lives - it seems like a lot of that stuff right now is being done with bots. Do you see Actions, maybe down the road, pretty much taking the place of what people are using bots for today?

I definitely think a lot of the things like Probot - it especially does a lot of these little tasks; I definitely think that Actions can fill that hole for you. We actually went through Probot with one of the maintainers, and made it so that you can bring your Probots to actions, out of the gate; you don’t need to make any changes, you can just put it in as one of the actions, and it’ll just work.

Nice.

[19:38] Because that’s a thing… The issue isn’t the bot. The Probot library is fantastic; writing a bot for them is actually quite simple. The issue is the deployment of that, and then keeping it running, and all of those little things that just add up. You might do one, and then you’re like, “Do I really need to comment every time a user does this one action? Hm… Not enough to create another bot.” Or try to host it, or whatever. And with Actions, the hope is that by taking away the execution, folks are going to build interesting activities, or - I hate to use the word “actions” again, but - actions in it, and let us just take care of the less interesting thing, which is to an individual, code execution at scale and securely, code execution is a little tricky.

Well, no one wants to run their own infrastructure, right? It’s becoming a lazy world in those ways, where if you have to run your own server for it, or somehow find a way to run that bot, then you’re probably not gonna do it, like you’ve just said.

Right.

Or it’s just too painful, and if I can get away with GitHub doing it for free, assuming it’s free forever…

Even in installing the apps - I’m so lazy, and perhaps I may be even incompetent - when they’re like “Well, just install this app into your repository”, I’m just like, “Neah, I’m done. I’ll just go without that little grease, I guess”, because I have app fatigue, or something. So it’s nice that you can just drop a workflow file into your repo and be done with it, versus going through the app, and credentialing etc.

Yeah, and I think it overly impacts too the larger businesses, you know? Because for us, if I’m on a side app or I work for a small company or whatever, I can just go spin up that Heroku instance, or use Glitch, or whatever, to run these things. But if you’re in a Fortune 1000 company, that’s now how it works. You’ve gotta call IT, provision another server, or get access to more VMs, or whatever it is… So they can’t, even though they’re dying to, because it’s just not worth it; it’s hard to convince someone that spending an extra N dollars a year is worth having this little workflow automation. You have to build a case study, and whatever else.

So the hope was that if we made this easier for them, as well as the open source community, which already has a ton of the automation, but also has to pay the tax on infrastructure - just have us run it, and that should take a lot of the stress away from you.

To me - this is kind of weird, but this is just the way my brain works… It kind of reminds me of the WordPress plugin ecosystem back in the day.

Sure.

You’d put your blog out there - and this is obviously early in my day of learning to be a developer or even play on the web, so I’m learning as I go, and I just sort of would scour other blog posts and/or the directory to find things I could just install to WordPress and magic happens. This kind of seems like that, where I may get lost in this Actions list, when and if ever one is truly created besides Sarah Drasner’s awesome list… To sort of just say, “What can I do with Actions?” and dream a little.

Yeah, the way I’ve described it to the team is really that – you know, we’ve always had GitHub customers that integrate it, but we’ve built APIs, we’ve built ways for them to authenticate, we have SDKs… We have all the nuts and bolts, all the tools that would make a better GitHub experience for folks. But there is a barrier to entry there, and what I think Actions does is it makes every GitHub user a potential integrator.

So you’ll have the ability, like you said, to build your own little thing and give it a shot. Or find a thing. Or let the community’s actual usage of these actions help show you what is valuable. Because I think that’s the thing that’s always been interesting to me, especially having worked on Marketplace - everyone is trying to tackle the problem of “What is the best X?”, like the best CI tool, or the best whatever… And unfortunately, that’s a really hard problem to solve, because in software development it doesn’t matter if you are the “Best CI for Ruby.” You might have a particular thing, or you might use multiple languages where it just doesn’t work.

[23:37] I think the thing I’m interested in with Actions is with these workflow file definitions and with them being shared publicly, if they’re shared publicly, we’ll be able to better understand the community, what repos are being used by these actions; if the actions are used in a repo that is half-Ruby, half-JavaScript, or half-.NET, or whatever. We’re able to hopefully tell you a little bit more of “Hey, you wanna start? Why don’t you start with this one action?”, all the way through to – we were talking about Actions and we finally landed on that… It was a very interesting way to help potentially on-board GitHub users. If you’re a brand new user to GitHub and you have never interacted with a GitHub product, we can show you a way to get started and play with some programming inside of a repo, and it’s just an action, because we’ll execute it on your behalf.

It’s hopefully raising the water level of what folks can expect from a software development platform, where you can kind of dive in and do these things, like WordPress plugins, like Atom plugins, like your IDE of choice plugins… All these little things where you can add in and hopefully make a bigger difference. But I agree that discovery will probably be the next big thing for us to help users, as Actions grow and grow.

So let’s talk about Actions, how it works… Tell us as much as you can. Nerd out with us on the way it’s built, the way that we use it… I’ll give a quick plug to Jessie Frazelle’s blog, where she posted “The life of a GitHub action”, which was super-useful for me to understand how it all fits together… Even though I did get in and play with the visual editor, I didn’t have an actual goal in mind, and it’s very difficult to build an action where you’re like “Well, I’m just kind of poking around at things. I don’t really understand what’s going on here.” But when you have a goal, it’s a lot easier, I assume. But we will link that up in the show notes. We actually almost got Jess on the call today, but the schedule didn’t quite work out; maybe another time, Jess, but this is a great post…

Definitely.

So do your best impression of her, give us the life of a GitHub action in your words. Help us understand how everything fits together when I’m trying to use this.

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.

The GitHub token that you give for free - who is that authenticated as?

The token is currently authenticated as basically a contributor to the repository. It’s making it as easy as possible to let you kick off – one of you mentioned it can be a little bit tricky to deal with authorizing these outside apps, or at least you get fatigue in it, so the goal was to make it have the same rights as someone that can push to the repository.

We’re working with the community to figure out what sort of limitations folks would want on that. I can totally see someone saying, “Don’t ever let an action see code”, but I want them to deal with issue comments, for example… So that would probably be something that we would add in the future.

And inside the Docker container the world is yours, right?

The world is yours.

In Jess’ blog, basically the workflow that she had is when you merge a pull request back into the master branch, it’s gonna delete the feature branch. You guys do have a nice button there, which is usually what I use after a merge to delete that branch, but this would just automatically clean up the just-merged branch… And hers is a Bash script; it’s just ugly, old Bash, doing its thing, hitting the GitHub API with a token, and stuff… But that’s just because she picked that. You could run Ruby in there, you could run Python - whatever; it’s Docker, do your thing.

[32:26] Did I hear you correctly say it was one CPU and some RAM?

Yeah, I think it’s one CPU and 4 or 6 GB of RAM. Another thing we’re kind of dancing around with to figure out what the right amount of compute is for what folks are trying to do.

Right… Put too much there and people abuse it, put not much there and people won’t use it.

Yeah, exactly. I think at this point when we’ve been talking to folks it’s been pretty much okay for any - like you both said at the beginning - reasonable use of what this is… But you’re totally right - if we put in an 8-core machine with 32 GB of RAM or whatever, the question would be what exactly it’s being used for. But we know that CI, especially inside GitHub, needs a bit beefier of a machine than a single CPU and a couple gigs of RAM…

For sure.

…so we’re working on what our options are there to give some more compute where t makes sense.

If you have a workflow that has parallelized actions, are those each on their own resources though, so I could split up my tasks and run them in parallel? Or they all share multiple containers on one VM.

I believe it’s currently in a single flow. In all her blog posts, Jess and some other folks on the Actions team are also looking at ways that we can make that be a bit more flexible, like you mentioned, so you’re not sort of doing everything on a single CPU… So looking at what our options are to allow for the parallel tracks that have their own VMs, maybe each action should have its own, so that way it has its own compute, depending on what you’re doing… But yeah, you should be able to run the parallel tracks semi-independently, depending on exactly how the dependency tree maps. That’s one of the very interesting things in this - if you watched the GitHub Universe stuff, it gets a little tricky to describe, but ultimately if you’re branching off and both of those things need to work for this last thing to ultimately run, there’s this dependency tree that we have to build in order to make it run, and ultimately that tree is what’s telling us sort of where things are able to execute in these VMs.

Man, I’ve forgotten how difficult it is to describe visual things… I have my hands here, which aren’t helping anyone but me at the moment.

[laughs] Over there, hand-waving.

Exactly.

Well, we do our best with the audio that we have, and we link out to everything else… So definitely we will link to the GitHub Universe videos; there’s a bunch of demos, as well as, as you mentioned, the blog post, so people can get their hands on it. But more and more people are getting into the beta, so tell us about the status of things. It’s in beta, you can’t have access to it; there’s an application process, but it seems like maybe you guys let in a wave of people last week, because all of a sudden there’s a bunch of buzz again… Tell us about that - what are we looking at in terms of people getting in here and using it for real?

If you go and sign up - and you can follow the link in the show notes - it’ll show you… It’s very easy to sign up. You just add your user or your organization if you’re trying to sign up for work, or for your open source organization. I would say your wait time is probably a week or two at this point, it kind of depends. The only thing that’s limiting us really at this point to getting folks in is we need to hear the feedback. We need to let people in, hear what they have to say, meet them, see what’s working well, see what’s not working so great… But I would agree that folks are moving through relatively quickly.

It’s still in a beta phase, so we can respond to feedback and that sometimes means breaking changes. That’s one of the tricky things about developer tools - responding to the feedback in a lot of cases will break an API. But for us right now it’s been going really well from that perspective. Especially the new cohort, my hope was that in January, especially when folks come back to work and they’re like “I wanna learn something new” or “I wanna try this new thing out” that we would start to get that additional feedback, and we have, so far.

[36:15] Can you give us some examples of feedback? Any big surprises, any major bumps or challenges?

The feedback in some ways has kind of been a little bit all over the place… Not in terms of good or bad, but just in terms of what people were using this for, and sort of where they were either getting what they needed or had friction.

It was interesting, when we were doing press for actions right after Universe we were sort of talking as a team about how exactly to describe this, because in a lot of ways it’s like saying “We now offer paper and crayons, and you can do whatever you want.” And of course, that’s not what the press team wants as the narrative. Because a reporter will ask, “What can you do with this?” and you go “Well, anything.” What we’ve seen at this point is that anything.

A lot of folks are using Actions to orchestrate amongst other outside tools - sending an SMS, or working with IFTTT, or working with an internal tool and then sending a message to GitHub issues. That’s been sort of one aspect of it. A lot of other folks in the open source community are using it for the automated packaging bits of whatever they’re building, which I think we kind of all expected, to some degree. Because of some limitations in the beta, we haven’t seen that much yet, but as starting is the workflow improvements that we’ve talked about at the beginning - responding to a first-time contributor, adding a label, all those sorts of things. All of that has been pretty good.

One of the things that we knew going into this that was going to be difficult is that it is in a relatively prosumer state. It is something where if you understand Docker, if you understand the limitations therein, if you can wrap your head around the workflow files and the documentation that we have, then you’re kind of good to go. If any of those words is something that you don’t really understand that well, or you haven’t had a ton of experience with, we’re not necessarily making it really easy for you to come and use Actions.

Like you see in Jess’ blog post, she was offering to meet with open source maintainers, our product managers are out, the team is out, everyone’s out right now in this new effort to talk to folks and understand what is the thing that’s stopping you from really diving in and loving Actions. Because at this point if you’re a creator, generally speaking, you’re doing pretty well with Actions. If you prefer to consume, if you prefer to install plugins, then you’re not really sure if this is exactly what you need at the moment. We’re working on that, but I highly recommend folks reach out both to me on Twitter, over email, Jess had an offer - any of us, because we’d love to figure that out… Because that’s where we’re at with the product - technically speaking, we think we have most of it where it would need to be, but before we say “Yes, here it is, world. Everyone can have at it”, we wanna make sure that it’s really a joy to use, and not just a sort of step-up improvement in your workflow.

In light of the creation side, I’d love to go back to the visual editor and just focus on it, maybe the technology, for a minute… You mentioned there was a separate service - did I hear that correctly?

Yes.

Because it does… As I’m using it, it appears to be running inside of the github.com main application, unless it’s iframed, or something. How does that service work, and how did you guys build that?

Yeah, so it’s ultimately a very sneaky iframe. [laughs]

Okay, okay…

They’re making their way back; it’s 2019, make a note, “Kyle Daigle, the year of the iframe.” It’s back. [laughter]

The year of the iframe. I like it. I love iframes, I always have.

[39:58] One of the reasons that we kind of approached it that way is we have – if you’ve ever used any 3D files, for example, inside of GitHub, we use a very similar approach to render 3D files and PSDs and images, and we offer you all kinds of functionality. A very similar approach to what we did with the Actions editor, because we wanted a way to iterate very quickly. That’s candidly the whole purpose of this - just being able to move very quickly, especially with customer feedback, because we knew this was gonna be a brand new thing, and it would take some time.

So the code in this is, I believe, really Canvas under the hood, the team that built the editor. We have some extremely talented front-end folks that jumped in on this to make this work the way it needed to. There’s two major parts - there’s obviously the animation, the actual drawing of the workflow itself, and then we also have the code that is rewriting all of that into the workflow file, using a server-side task. That side of it is implementing or really parsing the cvasi-HCL, the workflow file that we have right now, making sure the dependency tree works, and then ultimately sending that dependency tree back to the UI, which is then rendering it in the page itself.

Gotcha.

We had to build that separate parser piece in order to ultimately ensure that this thing could run… Because ultimately, when we first started - it’d be very funny - we would be able to create these monstrosities of workflows in the visual editor, that looked either very ridiculous, but were contractually correct, or the exact opposite, that were contractually incorrect, but looked beautiful. So the team did a really good job, even in the last couple of weeks before we announced, to make sure that the editor visually showed, especially once you got to parallel workflows - because for a period of time we were only working in a single workflow… And that was very - I don’t wanna say easy to draw, but much simpler to drawn than (say) a parallelized workflow that had dependencies in it. But building those two things out, one is a very, very difficult problem that we were able to sort of cheat around, which is how you draw out parallel workflows that ultimately have dependencies; building that tree is quite complex, but we kind of cheated slightly in order to get something that looks really good and is still true… Versus when we initially started and just had that simple – I keep saying simple, but I could never write the necessary JavaScript to do this simple tree, which just had all the consecutive actions in it.

Very interesting. I love that you’re just sneaking in a completely different set of code inside an iframe there, and… Hey, it tricked this guy, and hey, I build UI’s for a living. I didn’t actually look under the hood, because I would have seen it, but just when you said on the show that it was a service, I assumed it was just part of the main application; that’s a cool way of somewhat decoupling at least your teams and your products inside of what appears to be a holistic application… So maybe listeners could take that little trick and say “Hey, it’s the year of the iframe, people!” [laughter] Listen to Kyle.

Yeah, there’s all kinds of very interesting things that you have to do when you have a website like ours, that is under a tremendous amount of traffic, but is also a 10 or 11-year-old Rails application. GitHub has from the beginning always really cared about the product and the user experience of what was happening, and in a lot of ways sort of slowed to the microservice application that we all kind of experienced over the last 4-5 years, when that became very en vogue; it’s been around forever, but it became very en vogue.

[43:55] So for us, the thing that we’re always sort of figuring out is “How can we make a technology choice that lets us move quickly, in service of bringing a product/tool/experience to our customers?” So you end up doing these tricky things where you think, “Okay, maybe I pull this service out, so that way while we’re iterating very quickly, we don’t have to deal with the entire application while we’re doing the launch editor, or the parser, or the scheduler?”, all these little things. But in a lot of cases, there’s things that should be in the app, and for what powered actions there’s some pieces that are in the main GitHub application. There’s all kinds of little tips and tricks as we bring new features to market, that we have to make that choice. Because I don’t think it’s as simple as saying that there’s a single technology approach that’s just gonna solve all our reliability problems, or solve all the customer problems, or product problems… And this gave us a tricky way around that when we already had a solution like it for all the 3D and image rendering.

So all this talk about Actions has got me thinking about the Beastie Boys in the break, why not– but the next good step might be at the org level, versus (say) just a repo level. Maybe I’m trying to run code analysis on all of our repos, or different stuff like that - do you see this moving in a direction of org level, versus simply repo level?

Oh, definitely. I think the reason we started off with repo is we have a much clearer primitive with the repository, if that makes sense. Everything at GitHub is really backed around the repository at this point, but if you noticed over the past couple of months, and at Universe, and stuff, we have started talking to our larger customers, like the folks that would use this from an organizational perspective, aside from the open source organizations, where they want to think about not even just one organization, but two or three organizations all being a part of one business, if that makes sense.

Yeah.

So as we start to explore that as a company - which we talked about a unified business identity and things that help that use case - we’ll have a better place, as well as authorization management to do that. Because that’s where this sort of starts to become difficult; we totally believe that organizations want to say – for example, one of the things that almost every business customer that I’m aware of in GitHub does is every time a new repo is created, takes some sort of action. Sometimes it’s auditing, sometimes is making sure the right people have the right permissions… Any business of medium to large scale does some automated action that way, and of course, we’re looking at actions and going, “Well, obviously, this could make this very easy, because it’ll be auditable, it’ll be always run for them”, but the trick is “Who should have access to this? Where should it live?”, all of those sorts of questions.

So I think we have probably a little bit more of a foundation to lay, to let those use cases be simple still inside of GitHub, and not sort of get into a horrible authorization management structure that all apps that sort of go that way tend to fall into… And still let our customers execute things for every single repo, or every single issue, or every time a user is added, send them a welcome message; any of those sorts of things that currently our customers unfortunately have to do on their own hardware, by building their own things.

[48:11] I wanna mention too when you think through product development like this, you’re thinking, “Okay, here’s an idea for phase two or phase three - and maybe that’s orgs - so given GitHub Actions is successful, then we can come back to this bigger, greater idea and we can see where it goes.” Visionaries can see org-level actions being important… However, maybe right now you need to do far more feedback and iteration on the core of it, rather than thinking big picture at this point.

Yeah, I think so. I also think it’s about also wanting to solve a singular of a user problem (or at least like a developer tool problem) as we can, instead of necessarily wrapping it all up in addressing that there’s this larger overarching primitive that everyone wants, or would like to have, which is this business identity piece. So for us, when we try to solve problems like this, especially with new, relatively novel things like actions, we wanna prove the case first that the super-nerd or the high-end developer, the folks that really wanna dive into this find this intriguing and interesting. Because if they find it intriguing and interesting, then it’s likely that their open source projects, their teammates, their businesses will also find it interesting, and then we can bubble that up through organizations, through the rest of the product as well. So we’re trying to focus on one piece first, but I can’t see how we wouldn’t also allow these to be run at an organizational level down the road.

We started out the show talking about Marketplace, and then when we moved into the conversation around Actions, we talked about Probot and a lot of the apps and the bots, a lot of that functionality probably being rolled into Actions or eventually build it directly in Actions, kind of eating that piece of the pie… It seems like especially when we talk about CI/CD, parallelism aside or resource limits aside, it seems like maybe the 80/20 use case for that - the 80% of people are gonna be okay just running their CI on GitHub Actions, I would think, assuming their product works and is successful and all that. That being said, you have all these Marketplace vendors, and you have partners, and you have the Circle CI’s, the Travis CI’s, all these companies who’ve built businesses around GitHub as a platform… And that’s when I said maybe it’s at odds - which I do see that as potentially being problematic as Actions becomes more popular and I can just go grab the Ruby on Rails CI workflow, and just throw it in my repo; I don’t need to look beyond GitHub’s domain. Can you speak to that and what you guys are thinking in terms of potentially angering some of your vendors, or competing directly as the platform with the Marketplace?

Yeah, for sure. When we decided to go this route, even when we were really just exploring it, we started to immediately share what we were up to, with our partners. Both to work with us, if it made sense to them, or just kind of giving them a heads up. I think it’s really important as we’re building these things that, like you said, encroach, if not directly compete with them, that we’re just honest about what we’re doing. They’re businesses, there’s people on the other side and they deserve to know what we’re trying to do.

I think for us, in the conversations that came out of that, and at Universe, what it comes down to is that customers first off are always going to choose the product that they think is fulfilling their need the most. Servers have always been around to run CI; people haven’t always stuck with Jenkins, they go and try Travis CI. If Travis CI isn’t matching what they want, then maybe they’re using Azure DevOps in their pipelines product. Folks are jumping around to really find a great fit, so when we started talking to them, I do think that each one of these products offers something that is unique and is separate from what GitHub is completely offering, even if we compete on a pure compute level, like you said.

[52:16] Let’s say we’re all offering the same parallelization, we’re all offering the same compute - I don’t necessarily think that what Actions is offering is going to completely eradicate the need for an external CI product that is solely focused on CI. Do I think that open source projects’ small teams are probably going to use Actions over time? Absolutely, I do. I think it’ll be easier, I think it’ll be fast, it’ll be inexpensive, or free, depending… So it’ll be something that I think most people will go to.

I also think though that we in a way sort of have a responsibility to acknowledge when the industry water level is rising, if that makes sense. A couple of years ago we created projects into GitHub, when kanban boards and project boards seemed like an absolute necessity, regardless of whether you’re creating a soup to nuts project management or issue management application; it seemed like everyone needed this. So we added it to the application, and we work with our project partners, and they actually saw that their business actually went up, because we hypothesize at least that we brought some visibility into that market segment, and thus folks went “Oh, we could use this, but this product actually has this very particular thing that we’re looking for” and then they would go and use them.

I think the same is true in some ways with CI, or at least this raw compute piece, which is everyone’s offering compute; that is not going away, and so by us going, okay, the raw compute piece is commoditized, that’s just what it is, and we want to help our developers be better software developers or be more productive software developers inside of their businesses, so maybe we should offer that to them and let them build the tools.

I would love a future case where an entire developer tool could be an action that is charged for. Like I talked about Abi and Pull Reminders at the beginning, there’s tons of other small businesses, like Greenkeeper and others, that do that sort of “We’re gonna do one very particular thing.” I would love them to be able to build an action or a set of actions, a workflow, let us run it, and that can be the developer tool that you purchase for $5/user, or whatever it is.

You know, it definitely competes, there’s no saying it doesn’t, I just don’t think that it’s going to stop these large businesses from being a necessity for a lot of companies. What I hope it does though is lets small businesses, or even large businesses that wanna try something out, build these very niche, interesting bots/tools/actions, getting those into market, potentially open source, as attached to a commercial product, which has been a very successful avenue for a lot of folks… Or hopefully down the road being able to sell them, so that way as a small developer my entire side business could be a Docker container. Not running it, not supporting the payment for it, just a Docker container.

I was just thinking that… So the workflows are open source, but they ultimately execute code that’s inside of a Docker container, and the Docker container has to be published somewhere that GitHub can fetch it, but the contents of the container are not necessarily open source, right? I could have a proprietary tool inside of a Docker container - that by the way, I have zero infrastructure at this point, like you pointed out, so it’s kind of bringing the indies even more to the table, because they don’t have to worry about any sort of server infrastructure…

Yeah.

But just because the workflows are open source doesn’t mean all of the tooling necessarily is.

Right, and I think right now for example if GitHub wanted to use an action or write its own action, you can also embed those actions directly inside the private repo. So there is an idea that not every single action itself is currently public, it’s just that in the current avenue that we’re using it and doing beta testing, the vast majority of them are, because of the sort of open source side of things.

[56:13] I think the question looking towards the future is, like you said, how can we – or first off, should we support this avenue and making it easier this way? …but then also how can we make it so that I could create an action that should be private or should be compensated for? Maybe it’s not private, maybe it is public and it’s just an additional license, like Sidekiq and Mike Perham does. I think there’s a lot of different ways for us to help both the person that’s writing this software, and ultimately bringing this to market, and then also all the developers that could benefit from having a tool like they’re building.

We also talked earlier about discovery being an issue, and obviously Marketplace is there, and I’m noticing that you have GitHub Actions actually in the top part of it on /marketplace, “An entirely new way to automate your development workflow”, and you’ve got a View All there, and they’re all pretty simplistic; the installation process is pretty simple, you just say “Copy and Paste”, basically, into a repository. Can you paint a picture for maybe – since part of your background is actually establishing Marketplace, maybe what some of the vision might be for how this will eventually get easier, faster, better, or more visibility to other actions, and how you plan to surface those?

Yeah, so most of the actions that are currently in Marketplace at the moment are ones that we created or we had a hand in sort of supporting the creation of; not all of them, but a lot of them. Like you mentioned, there’s very in there at the moment, and it doesn’t match Sarah’s list of actions, for example.

Looking towards the future, the thing that we definitely want to do is not just list them all out, but make discovery meaningful, because there’s way more actions than any list or even just name a description-based search would actually be valuable for. So the thing that I’m really excited about as someone that has cared about our external platform for a while is trying to figure out how folks are using them together, or just using them at all.

You’ll notice that Marketplace right now doesn’t really have a rating system in it. Those have historically been gamified, and don’t always work, and if you have an unfortunate customer issue, maybe you go down or something, all your ratings go down, too. There’s not a very strong signal to noise ratio on a lot of these ratings systems, and you can see that in almost every app store. And there’s been developer responses, and it becomes a full-time job to manage your rating. So we’re looking at ways, like “How can I show you that an action is well-used and well-liked by customers that do similar software projects as you do? Or in organizations of a similar size as yours.”

We have so much information that is completely public information, and not even looking at any of the sort of private usage, that we could use to help make it so that when you land on this page, we’re not just showing you a couple of integrations that you can get on the outside, a bunch of the GitHub actions that are available, and sort of just say “Listen, we know you have CI. You don’t seem to have any static code analysis, but your organization almost always works in Python, so here is something that most Python folks use at an organization of your scale, and they’ve used it for months.”

Where would that be at? Would that be at the repo level, or…?

It could be at the repo level, it could be at the organization level… It kind of depends. At GitHub we don’t all use Ruby, right? We use Ruby, we use Python, if you’re in machine learning, we use Go, if you’re writing services, we use C, and so on and so forth. So it would kind of depend on where you’re looking at, so we’ve looked at ways to make it easier to do this from your repository page already for the other Marketplace apps. If you already have an app, we suggest you use it with your other repos etc. But I think with Actions, since we’re able to see that it ran, that it ran successfully, or it failed, or it got installed and then immediately uninstalled - all those sorts of things, we’re able to bring a discovery story that will hopefully be really valuable to you, and not just “Here are the top 10 actions that everyone uses”, which I feel like in a lot of cases most app stores or plugin markets kind of devolve into, which is “This is the top 10, and then here are the categories. What kind of category are you looking for?”

[01:00:26.28] One of the other things I think that we have sort of overlooked a bit in Marketplace, which I’d like to address, is a lot of these categories, for example, or verticals of these tools, folks don’t even know what they mean. “Dependency management” is a word we kind of all use, but it fills in a lot of different use cases. “Continuous integration” is a little bit better; “static code analysis” - again, who the hell knows…? It can get a little bit tricky… So I think there’s an education piece that we could help bring to you, and say “Here’s an action that does this one thing, so you can kind of give it a go.” If the action doesn’t serve what you need, then you can go get Code Climate, or one of the other tools that can tell you a little bit more about your code.

So I definitely think there’s gonna be a lot more investment. We’ve been focusing on the producer side of Actions for a bit, but over the next couple of weeks you should see some easier ways to find Actions – like you mentioned, make it easier to install Actions, and then hopefully it gets to the point where you can just say “And here’s potentially a workflow that would make sense for you” or “Here’s an action that will round out your workflow really well.”

Is it safe to say that you’re betting big on this? Have you gotten far enough down the road of the beta to feel good about it that as a company there’s a big bet on this?

I think the thing that we’re betting big on more than anything else really is this idea that the extensibility of the experience on GitHub is the thing that we really want to make a bet on. We’re obviously making it so that way more people can use GitHub with the free private repos that we offer, we’re trying to make it easier to fill in all those little usage gaps that maybe we’re bothering like 5% of folks with the way it worked, and then we’ve released another improvement 5% better for that other 5%, so on and so forth.

I think with this what we’re sort of saying is we know our experience is powerful, but we might not have absolutely everything that you need. We might not have everything you need, but we wanna make it so your GitHub experience is continuously getting better every day, especially if you’re bringing these outside tools in, or using Actions.

I think it’s extremely interesting that we’re doing the static code execution. We said it at Universe, and I truly believe it, that Actions will be the next big movement in software development after pull requests. When those came out, they were very big and they changed the way that a lot of people were writing software. Now I think we’re gonna do the same thing, but for your software development workflow, which historically I feel like has been either ignored, or as an afterthought. We’ve spent so much time focusing on “Okay, what does this code review look like?” or “Are we doing test-driven development?” or “Is BDD better?” and all these other things… And now we’re sort of saying, “Okay, you also have this entire other part of what software development is, which is after the software is written, or while it’s written. How do I know it’s good? How do I know it’s gonna run well? How do I know that it got deployed? How do I know once it’s been deployed, that it’s functioning the way I want? How do I read the stats on GitHub and have that experience in a single place, instead of having to work with all these independent entities?”

Right now, with all the customers that we have in the beta, the feedback has been good; it’s really scratching the itch for some folks. You mentioned the buzz on Twitter kind of picking up, and I agree; I love reading what people are doing with it. Now the thing for me is “How do I get Actions to all 30 million people, and make it be something that is as impactful - if not more impactful - than when GitHub released the pull request?”

[01:04:05.16] And just to reiterate to those that are in the Marketplace now, and people who may consider, “Hey, GitHub’s getting into my world. They could be stepping on my toes”, or something like that, with CI, for example… I think one point you said earlier that I wanna reiterate is that actions will play a role for open source developers, and these are typically people that they’re giving free accounts to anyways, which is sort of a growth hack model for most of these businesses, so I can kind of see some side-eye from that perspective. However, as you’ve mentioned, in some ways you’re educating that hey, you may need CI and you don’t even know it, or you may need code quality, or whatever… So you’re surfacing needs, not so much solutions.

Yeah, I completely agree. I think that one of the things – like you mentioned, most CI tools are for free; it is a growth thing. A lot of the folks that use those CI tools for their free open source, whether it’s a big project or just some little side repo, is also so that you go to work and you say “I really love using Insert-CI-tool-here”, and you get that experience. So I think in a lot of ways the experience of trying out these tools figuring out what matches, buying the tool at work, or deciding to use it in your small business or whatever - that process is always going to continue, because developers have very particular taste. GitHub is not the only version control host in the world, Travis CI is not the only CI tool in the world. Emacs, Vim, Atom, VS Code - all those things exist, in my opinion, because everyone has a slightly different taste. There’s bigger companies than us that offer CI, or offer code execution; there’s the Google Cloud platform with their Functions, Azure has Functions as well, there’s Lambda… There’s all these things that do something a little bit simpler.

The reason why we think it is worth building Actions right now is that it is the network that you would have to build to do all these little things in all these different places - we just want you to have a simpler experience in doing that. If you are going to build the absolute best editor, or whatever, we want you to be able to do that; if you’re gonna build the best error tracker, we want you to be able to do that. Yes, there might be some open source action or private action or whatever that does something similar, but we still work – we have an entire partner engineering team that works with our partners to make sure they’re building things that are valuable for their customers, as well as helping them implement new features; we have a partner management team that works in the ecosystem as well to do all these things, so we’re very excited to continue to work with partners in all this stuff, and I hope no one leaves this conversation or looks at the launch of Actions and just kind of throws their hands up and says “Well, I guess there goes Insert-integrated-vertical-here.” My hope is if anything, folks are going to see Actions, use it for where it makes great sense for them, and then also look and say “Well, you know, I actually would rather go buy this package management tool, and I’ll just my action to push into that package management tool.”

Yeah. As we said, it’s almost like an opportunity for a land grab too for some of these partners, because they can easily come on here - I’m looking at the Actions list here on Marketplace, which is accessible to anybody (we’ll put it in the show notes), and I’m seeing a GitHub Action for Azure, a GitHub Action for Heroku… It’s not like it’s GitHub Action for GitHub CI. You’re using third-party vendors and they can easily come in here and help folks to use Actions to benefit the usage of their tool anyway, so it’s an opportunity for them to play as well.

Yeah, completely. One of the interesting things when we were talking to a lot of folks – like you mentioned, at Universe the second day we showed a lot of partners and community folks using Actions, because we gave them some early access… A lot of the partners that we talked to were very interested because they saw actions as an opportunity to do something new and unique, versus their main product. Obviously, I can’t talk in too many specifics about this, because a lot of this stuff hasn’t launched yet, but… If you could look at a simple tool that does static code analysis, for example, maybe there’s some way for them to add a CLI or something via an action, that lets you sort of demark, “At this point, this PR, this comment, or whatever, this was introduced” or “Here’s the explanation as to why I built this”, so that way I can see that in the other tool.

[01:08:28.29] You see the sneak action in there, with their CLI trying to do a very similar thing, of letting us just interact with this other tool. The thing I’m excited about more than anything is not hopefully creating a situation where folks feel like we’re competing, but that we’re also letting these partners have a new avenue to work with customers, and like you said, create an interesting action that extends their existing business and puts it in the Marketplace, or just open sources it regardless, so that way customers know, “Oh, there’s this new way to interact with the tool I already paid for. There’s a new thing that I’d love to go try out their tool.” I think that’s something that we’ll see more of as we get to the public phase of the beta program that we’re running.

I’m interested to see the future of paid Actions. I think it could be an interesting thing to consider… But point a lens towards the future; there may not be a ton you can say about the future of Actions, but maybe some things you can tease and/or name-drop. What’s on the horizon for you and Actions and the teams behind Actions, that maybe not exactly be public knowledge per se yet; maybe hidden in the details somewhere. Give us some over-the-hill, just near the future explanation of where things are going, or anything that we haven’t covered yet.

Yeah, sure. I think there’s a couple things. Obviously, we want to bring the actual compute to more folks, and get further along in the beta program, and give more folks access to potentially more powerful machines, or more powerful use cases for them. I think that’s one thing.

The thing that we’ve kind of been playing with which I can mention is we had a – we recently released a new API to the platform called “The Content Attachments API”, which basically allows integrators to be able to put in more data into their response into an issue comment; every integrator generally uses version of an issue comment to give you data, but what could happen if for example RunKit, which is a very popular tool, allowed you to be able to pass back a rich version of the thing that they just ran on your behalf? Instead of sort of formatting it into markdown, and so on.

I share that single example as a way to show that what we’re sort of looking to for actions is not just the code execution piece. I think that’s what gives this the excitement, is you could do anything, but what happens when you can use Actions to further change your GitHub experience? Folks do this already by sort of hacking the platform features that we offer, like statuses or checks… Like, run an action and fail it if this person didn’t describe what this thing did in their PR. So they kind of cheat the system and use a tool that was meant for CI to do something else.

But what happens if we allow the customer to, say, add a button somewhere as part of an action, or what happens if when you press that button, an action runs, does a result and gets sent back? What happens if we’re able to use that action to put content elsewhere on the site? Maybe I’m an engineering leader and I want everyone to listen to the Changelog, so I want them to know it exists.

Of course!

Obviously.

Now you’re talking our language.

What happens if I growth-hack my way into creating an action that puts an event into the dashboard, for example, because I want that for my organization? A lot of the things that are necessary to do that is sort of further extending our external platform to provide these use cases to make the GitHub experience different, instead of necessarily always treating integrations in Actions as these tools that you go out to, and then you sort of get drip-drops of information back via issue comments, or statuses, or checks, or whatever. Let’s try and create new and interesting ways to extend your GitHub experience that makes your life easier, and isn’t sort of hacky, or dropping all this information everywhere, but lets you have that rich experience.

[01:12:31.26] Like you mentioned, I think code execution is going to continue to continue to grow, meaning we’re going to find new and interesting ways to help contributors learn more about their existing code, being able to take advantage of the learnings that GitHub can have at the scale what we have, via using an action, for example, if you wanted to learn more about how your codebase compares or how this function changes, or whatever. We’ve done all kinds of interesting things in that regard that we’ve been sort of drip-dropping out as well, so… I think Actions is at the center of this plan to helping you have the exact experience and workflow that you want.

I know that was slightly vague, please excuse my best Apple imitation, but I think you can see when you look at a lot of the features that we’ve added to the platform kind of where we’re headed with this. I mentioned that when we were talking at Universe that Actions in retrospect, when you go back and you look through – we added Checks, and that was a big feature when that came out, to improve over statuses; we added more ways to interact, we added the GraphQL API, we’ve made all these investments in the platform, and Actions starts to show you where once we have all these foundation pieces in place, what can happen. So once we sort of cement arbitrary code execution and workflow management as a piece, I’m excited to continue to add those experiences on top of the GitHub that we all use, and know, and love, over the coming year or two.

I’m excited. I think based on that I can really see an interesting feature for this. I mean, I can even see where you might have paid tiers too, where something I wanna compute is a little bit more than you’re willing to give me for free, and maybe at some point you can say “Well, hey, you can pay for a slightly larger compute cycle.” Or something like that. There’s a lot of opportunities here, and it’s interesting how it becomes this separate layer on GitHub that just extends it, as you said. I think it’s really interesting to see where this goes.

Kyle, thank you so much, man. It was really appreciated to get this time with you and to walk through Actions in this way. Thanks for your time, man.

Yeah, thanks both of you.