The Changelog: Software Development, Open Source - GitHub Actions is the next big thing (Interview)

Episode Date: January 23, 2019

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.

Bandwidth for Changelog is provided by Fastly. Learn more at fastly.com. We move fast and fix things here at Changelog because of Rollbar. Check them out at rollbar.com and we're hosted on Linode servers. Head to linode.com slash changelog. This episode is brought to you by DigitalOcean. DigitalOcean is the simplest cloud platform for developers and teams with products like droplets, spaces, kubernetes load balancers block storage and pre-built one-click apps you can deploy manage and scale cloud applications faster and more efficiently on digital ocean whether you're running one virtual machine or 10 000 digital ocean makes managing your infrastructure way too easy get started for

free with a hundred dollar credit head to do.co100 credit. Head to do.co slash changelog. Again, do.co slash changelog. All right, welcome back, everyone. You are listening to The Changelog, a podcast featuring the hackers, the leaders, and the innovators of software development i'm adam stachowiak editor-in-chief here at changelog on today's show we're talking to kyle degel the director of ecosystem engineering at github to talk about github actions the new automation platform recently announced at github universe github actions is the next big thing coming out of github since the pull request with the promise of powerful workflows to supercharge your repos and your GitHub experience.

You can build your container apps, publish your packages or registries, or even automate welcoming messages to new users to your open source projects. access to interact with the full GitHub API and any other public API, actions are executed on demand as autoscale containers and offer what seems like limitless possibilities. Today, we talk through all that. So Kyle, you're a director of ecosystem engineering. I think that's the first time I've seen that title. I'm curious. I know what ecosystem is and I know what engineering is, but when you combine them, what does that mean?

Yeah. So, I mean, really it's what a lot of other companies might just call their external platform team, you know? So for us, ecosystem is responsible for all of the APIs, the API-based identity, the marketplace, which lets folks, you know, find integrations and lets integrators make money on their integrations uh in some ways it's also you know billing and things like that it's it's tying everything together to make github be useful to you um without just github if that makes sense but uh 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 and i 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 come on i know you would think working from home i could just do that but i'm pretty sure my wife would find that right i know but i feel like that's even more presumptuous exactly you know um so yeah yeah, so 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, very well. And then we just work together cross-functionally to ensure that, you know, as someone's adding something to the GraphQL API, we're also considering how that impacts GitHub apps and OAuth and kind of so on and so forth. And part of that, you were on the platform team. So similar, but not the same. Am I correct in that? Yeah. So 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 like a

feature company. You know, we obviously do get hosting, but that's just the bread and butter. We also have code review, etc. But then what we saw was, you know, 60% of our users and organizations were using some sort of external integration. You know, they were using CI or they were using project boards or something like that. And 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. 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 it's really sort of a we have a dual audience of the consumer and sometimes the consumer in a business in between us you know that facilitates that and i guess the other side of that too is marketplace you were 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 i mean so one of the things that's been really tricky for integrators is that we had a bunch of really great integrators that have been around for a while right like tra Like Travis CI started with working with open source. And then we've gotten folks like waffle and Zen hub and circle CI, like all of these companies that have been around for, you know, almost as long

as we have, or at least as long as we've had the API, right? The thing that I was sort of curious about was folks are finding CI tools pretty readily. Like nowadays, you know, 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 and dependency management, which is sort of the hot new thing this year

with all of the more recent compromises of packages and so on. Like how do you find and know about these verticals, never mind the tools? And so we started with something we called 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 want to 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. And so Marketplace for me was really about that is 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, you know, the 30 plus million software developers. And so that's been that's been the big journey for that product, I think, in the past two years it's been around. Certainly a point of exposure for, as you mentioned, smaller teams. So if I, you know, Jared and I got excited one day, we're like, hey, we want to compete with everybody who does CINCD. You know, given that we may be willing to share a percentage of the income with GitHub,

which we wouldn't mind, right, Jared? Why not? Sure. Then, you know, Marketplace would be, you know, a smart place to begin because what's the barrier to entry, right? Is getting a listing and maybe being accepted? Is there a criteria for being accepted these days or is it sort of more loose? Yeah, I mean, 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, no, you, a non-used integration, but like for one example I have is a pull reminders, which I'm not sure if either of you have heard about, but it's a, it's a really interesting integration that, uh, a gentleman, uh, Abhinoba built, uh, and you can like Google pull reminders and look up his story. It's really interesting. He basically built this side thing. Uh, he ended up selling it in the GitHub marketplace. It makes enough money now where this is his thing, you ended up selling it in the github marketplace it makes enough money now where this is his thing you know and it's his one thing and all it really does is looks at your pull

requests and reminds teams and people to review them if they haven't reviewed them in a timely fashion so it's not even competing with ci it's you know it's that niche tool that in most cases there'd be no financial reason to try to do if that makes sense that the barrier to entry 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 you know do this one tiny thing and i think honestly that's where i think developer tools will be going in the next couple years is less of these huge like 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 you know just do uh ruby dependency management or whatever versus we have to do everything because it's going to become so much harder to compete uh you know by trying to do all of these things at once and clouds and while github may not be a quote-unquote cloud it's similar in the way that um cloud infrastructure allows you to be a software vendor inside their cloud and i think if you look at you know microsoft amazon or google you see them encroaching into the developer tool space. Right. Because if if if your value add is a percentage of improvement on top of raw CPU, if that makes sense. So like CI, I would say, right, 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 uh aw aws is a git repo hosting like it's an incremental improvement on top of cpu and storage if your developer tool is just that is its primary market is a bit more than cloud hosting you're always gonna struggle in my opinion because those companies are going to make more money on their own CPU than you will, you know, 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 SSD can with some incremental improvement, which is why I think folks like Abhi 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 going to 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 is the new shiny github actions yeah definitely change the developer experience 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 what James governor said over at red monkey 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 longterm. Take us back 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, the launch. Yeah, sure. So GitHub Actions allows you to have workflow automation inside of GitHub. And so going one step less vague than that, we are running code for the first time. That's really, I think, 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. And 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. Since we've released in this beta beta all of the actions are open source uh from our side so folks are writing new ones we wrote some initial ones um the workflow is just a file inside of your repository uh 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 uh what you know what they like the most about the feature but But I would say as a developer, really it's GitHub's running code on your behalf for the first time. That I think is the low-key revolutionary thing that RedMonk said. 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 running arbitrary code inside of containers you know on your infrastructure so the security concerns, probably concerns with load and people using it for all improper reasons. So I guess my question is, how much work was this and how long have you all been working on? Yeah. So it was a lot of work. So 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. And so what we kept seeing were these workflows that each integrator either had to work with each other to make work, which was always going to be a one-to-many problem, or the customer would have to sort of 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, like candidly, in a lot of companies, the one you're forced to use, you know, uh, and add in things that, that you're more excited about, uh, better CI tools, better project management tools, better packaging tools, whatever, um, inside these flows. So initially when we started to look at this, we were sort of looking at a, um, pure workflow, uh, conduction aspect, you know, like we would, we would have a way for you to define all this.

And then we would just go out to integrators and go out and sort of talk to them and tell them what to do. 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 want to do and not sort of be a facilitator of workflow, but just be raw. What are you trying to do? You're trying to build your Docker container. Great. And then push it up to a registry. Great. Like we shouldn't say, okay, well we've integrated with these four. So you're good to go or tell integrators. Now you got to integrate with this new thing. It's okay. Let's just give the customer the raw compute. And so 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, uh, kind of what you were alluding to, which is the much, much, much harder problem of arbitrary code execution. But at the end of the day, like now that folks are starting to use it in the beta, we're seeing so much, um, 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, you know, 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 dino 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 to find it in a workflow file hopefully there's already an open source action and we'll run it for you and so two thoughts on that well i guess a thought and a question the thought is that it seems very much in the spirit like the way you guys landed on seems more in the spirit of git itself which doesn't dictate to you like this is how you will use me in terms of like this is your branching model or this is your collaboration model you know 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 you know tutorials on git flow and this is how you should do this this is how you should do that should i rebase should i force push etc um so really the the model that you guys picked seems

like it's in the spirit of git itself which is kind of neat um maybe speak to that while i try to remember my actual question yeah no i mean 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, you know, how to create a new branch or what your forking model is and so on and so forth. So with actions, we decided to start with like what I've been kind of calling the prosumer approach, which is, you know, 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 like oh you're a ruby app a ruby web

app and you want to do uh you know package uh package your app or you know 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 like here's, here's the workflow for that. Like, here's what the community has sort of definitively said is this, or here's what Kyle uses. Kyle prefers this workflow. And that to me gets us closer to like the get flow model, which, you know, the community is kind of, you know, rallied around to some degree. So I completely agree with you that instead of trying to be, you know, predictive of our customers needs, we figured okay everyone like we all have our custom setup with ide's we all have our custom way that we do all

our little things like let's not presuppose that we're going to nail that and just say all right 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 incomplete flows that then you could use similar to the heroku's build pack idea where you can write a build pack from scratch but you know most people don't have to because well is there a build pack for elixir and phoenix sure there is i'll just go use that one and i don't have to actually worry about the nitty-gritty same with workflows once we have the the repository of you know awesome actions as adam found actually exists on github

but i'm sure there'll be like an official actions place where we can share maybe i'm not sure maybe there will be you know you can just go grab what you need and then you're helped without having to actually uh know all of the the details themselves i did remember my question which it seems like the small stuff that you're talking about um the minor grease you know added to our our workflows that will help our developers lives it seems like a lot of that stuff right now is being done with bots um do you do you see actions you know maybe down the road pretty much taking the place of what people are using bots for today um i definitely think a lot of the things like probot you know like especially does a lot

of these little tasks i definitely think that actions can fill that hole for you um we actually uh went through probot with uh one of the maintainers and made it so that way you can bring your probots to actions like out of the gate you don't need to make any changes you can just put it in as one of the actions uh and it'll just work because that's a thing is we all the issue isn't the bot, like the pro bot library is fantastic. You know, writing a bot for them is actually quite simple. The issue is the deployment of that and then keeping it running in like 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, you know, a user does this one action, not enough to create another bot or like 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 you know or or you know i hate to use the word actions again but actions in it um and

let us just take care of the less interesting thing which is you know to an individual code execution at scale and securely uh code execution's a little little tricky well no one wants to run their their own infrastructure right like it's it's becoming a lazy world in those ways where if you have to run your own server forward or somehow find a way to run that bot then you're probably not going to do it like you just said right yeah or it's just too painful you know and if i can get away with get up doing it for free assuming you know even installing the apps like i'm i'm so lazy. And perhaps I may be even incompetent in place.

Like, well, just install this app into your repository. I'm just like, nah, I'm done. Like, I'll just go without that little grease, I guess, because I got 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 and et cetera. Yeah, and I think it overly impacts, overly impacts to like the larger businesses you know because for us you know if i'm on a side app where

i work for a small company or whatever like i can just go spin up that heroku instance or use glitch or like whatever to run these things but i mean if you're in a fortune 1000 company that's not how it works you know you gotta go call it and provision another server or get access to more VMs or like whatever it is. And so they can't, even though they're dying to, cause it's just not, it's, it's not worth it. It's hard to convince someone that spending an extra N dollars a year is worth, you know, having this little workflow automation, you have to build a case study and whatever else. And 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 um you know just have us run it and that should take a lot of the the stress away from you to me i mean this is kind of

a weird but this is just this is the way my brain works it kind of reminds me of the wordpress plug-in ecosystem back in the day like you know you know, you'd put your blog out there and this is obviously early in my day of like learning to be a developer or even play on the web and some 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, you know, I may get lost in this actions list when, when, and if ever one is truly created besides Sarah Dresner's awesome list, you know, to sort of just say like,

what can I do with actions and dream a little? Yeah, I think it's like the way I've described it to the team is really that, you know, we we've always had GitHub customers that integrated, but like, you know, we've built APIs, we've integrated, but like, you know, we've built APIs, we've built ways for them authenticate, we have SDKs, like we have all the nuts and bolts,

all the tools that would make sort of 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, you know, so you'll have the ability like you said build your own little thing and give it a shot or find a thing or let the community's actual you know usage of these actions help show you what is valuable because i think that's the thing that's been always really interesting to me especially having worked on marketplaces that everyone is trying to tackle the problem of what is the best X, you know, like whatever 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 quote unquote best CI for Ruby, you might have a particular thing or you might use multiple languages where it just doesn't work. And I think the thing I'm interested with actions is, you know, with these workflow file definitions and with them being shared publicly, like if they're shared publicly, like we'll be able to better understand the community, what the repos are being used, uh, by these actions. If the actions are used in a repo that is half Ruby, half JavaScript or half.net or whatever, uh, you know, we're able to help hopefully tell you a little bit more of, hey, you want to start, why don't you start with this one action, all the way through to like, we were talking about

actions, when we finally landed on that, it was a very interesting way to help potentially onboard GitHub users, you know, if you're a brand new user to GitHub, and you have never interacted with the GitHub product, then, you know, we can show you a way to sort of like 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, it's, it's hopefully raising the sort of water level of what folks can expect from like a software development platform where you can kind of dive in and do these things like, like WordPress plugins, like Adam 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 This episode is brought to you by Git Prime.

Git Prime helps software teams accelerate their velocity and release products faster by turning historical Git data into easy-to-understand insights and reports. Because past performance predicts future performance, Git Prime can examine your Git data to identify bottlenecks, compare sprints and releases over time, and enable data-driven discussions about engineering and product development. Shift faster because you know more, not because you're rushing. Get started at gitprime.com slash changelog. That's G-I-T-P-R-I-M-E dot com slash changelog. Again, gitprime.com slash changelog. That's G-I-T-P-R-I-M-E dot com slash changelog. Again, getprime.com slash changelog. 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 Frizzell'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.

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 a thousand percent cooler than I am. And so unfortunately I will leave that to her, but hopefully she can come on. So basically with actions, there's a, there's a couple of moving parts. So you mentioned the visual editor. So 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 open, when an issue is open, when something is pushed, when a ref is deleted, all those sorts of things, I would like you to run an action. And 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. And then as each action completes, it'll 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. And then if both of those pass,

I want you to package this and push it up to a registry, for example. And so the visual editor makes that very clear. But 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. So 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 sort of cruft it was human readable which was the primary concern so we looked at you know all the obvious subs suspects yaml json Um, but ultimately landed on

this because we thought it was like, honestly, aesthetically pleasing, which we thought would be in a very important part of how easy it would be to, you know, fill 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. And that container can do, you know, basically anything you can fit inside it, you get a single CPU with some memory that'll take care of what your action is trying to accomplish. So if you look in the open source examples of what actions can do, Usually you see, you know, uh, uh, the Docker file saying, uh, when, 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 sort of make sure we're making it as broad as is possible. Um, each one of those gets a couple of things for free. Each action gets a GitHub token for free. It also gets a checkout of the repository that you are working in for free. And so 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, call the github api and create an issue etc um the actions environment is ultimately a vm where we're running these actions uh on your behalf and we're using that vm boundary primarily for uh you know the security concerns that we have we do some

interesting things with docker to make it a little bit uh uh 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 kind of notoriously a monolithic Rails application. But in this instance, we have the launch editor itself, which is the drag and drop and work with file piece of its own service. Ultimately, the tool that actually receives these events and decides whether a workflow needs to be run is 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 quick, the very quick overview of how a workflow file visually or 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, you know, the GitHub token, the repo, and then also some secrets. If you wanted to put some, you know, outside tokens and we support all that and keep it encrypted as well. Who's the GitHub token that you get for free? Who is that authenticated as? Yeah, so the token is currently authenticated as basically a contributor to the repository. So it's making it as easy as possible to let you kind of kick off. Like one of you mentioned, it can be a little bit tricky to deal with authorizing these outside apps, you know, or at least you get fatigue in it. So the goal was to

make it be 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. You know, 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 be probably be something that we would add in the future and inside the docker container the world is yours right so i mean the world is yours i saw what in jess's blog she had basically the the workflow that she had is when you push or sorry when you merge a pull request back into the master branch it's going to delete the the feature branch because you guys do that nice button there which usually what i use after a merge uh to delete that branch, it's going to delete the feature branch because you guys do that nice button there,

which is 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. And so it's just, you know, ugly old bash doing its thing, hitting the GitHub API

with the token and stuff. But that's just because she picked that. You could run Ruby in there that you could run ruby in there you could run python just whatever it's docker do your thing did i hear you correctly say it was one cpu and some ram yeah i i think it's one cpu in four or six gigabytes of ram um another thing we're kind of dancing around with to figure out what the right uh you know amount of compute is for what too much people abuse it put in put not much there and yep people won't use it exactly i think at this point when we've been talking to folks

it's been pretty much okay for any you know uh like like like you both said at the beginning reasonable use of uh of what this is uh but you're totally right i mean if we put in an eight core machine with 32 gigabytes of ram or whatever um the question would be you know what exactly it's being used for but we know that c like ci like especially inside github right needs a bit beefier of a machine than a single cpu and a couple gigs of ram so um we're we're working on what our options are there to to give some more compute where it makes sense so if you have a workflow that has parallelized actions um are those each on their own resources though so i could split up my tasks and run them in parallel or is that just are they all share a singular multiple containers on one vm

so i believe it's currently in a single flow uh jess is uh like in all her blog posts jess and some other folks on the actions team are also looking at ways that we can you know make that be a bit more flexible like you mentioned so you're not sort of doing everything on a single cpu um so looking at what our options are to allow for uh the parallel tracks to 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 um but yeah you should be able to run the the parallel tracks um uh semi-independently depending on exactly how the dependency tree maps as one of the very interesting things in this and like if you watch the github universe stuff it gets a little tricky to kind of like describe but ultimately you know if uh if you're branching off and both of those

things need to work for this last thing to uh you know 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 like sort of where things are able to execute in these VMs. Man, I, I, I forgotten how difficult it is to describe visual visual things. I have my hands here, which aren't helping anyone but me at the moment over their hand waving. Uh, very good. Well, we do our best with, 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 posts, so people can get their hands on them. 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. 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's in beta. You can't have access. There's a 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. Um, tell us about people's pro, you know, what are we looking at in terms of people getting in here and using it for real? Yeah. Yeah. So, I mean, if you, if you go and sign up, uh, and you can follow the link, uh, in the show notes, but it'll show you, it's very easy to sign up. You just add your, your user or your organization. If organization for trying to sign up for work or for your open source organization. I would say your wait time is probably in like 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, you know, like we need to let people in here 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 sometimes that means breaking changes. That's one of the tricky things about developer tools is responding to the feedback. In a lot of cases, we'll break an API. But for us right now, it's been going really well from that perspective, especially in the new cohort. My hope was that in January, especially when folks kind of come back to work and they're like, I want to learn something new, or I want to try this new thing out that we would start to get, you know, that additional, that additional feedback. And we, uh, we have so far. Yeah. What's, uh, can you give us some examples of the feedback on any,

any big surprises, any major bumps or challenges? So the feedback in some ways has kind of been, you know, a little bit all over the place, like 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 like how exactly to describe this because in a lot of ways it's like saying you know we now offer paper and crayons you know and you can do whatever you want you know and of course like that's not what the press team wants has the narrative as like you know because a reporter will ask what can you do

with this and you go well anything you know and uh in kind of what we've seen at this point, is that anything, you know, a lot of folks are using actions to orchestrate amongst other outside tools. So, you know, sending an SMS or working with IFTT or working with an internal tool and then sending an issue to or sending a message to GitHub issues. So that's been sort of one aspect of it. A lot of other folks in the open source community are using it for like the automated packaging bits of whatever they're building, which I think we kind of all expected to some degree. The thing that because of some limitations in the beta, we haven't seen that much yet, but is starting is the, um, workflow improvements that we talked about at the beginning, you know, creating a

responding to a first-time contributor, adding a label, all those sorts of things. So all of that has been, uh, been pretty good. Um, one of the things that we knew going into this, that was going to be difficult is that it is in a relatively pro prosumer state, right? 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, you know, then you're kind of good to go. If any of those words, you know, 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 action. So I think, I think you see, you know, in Jess's blog posts,

and 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 sort of talk to folks and understand, you know, 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. And so we're working on that. But I highly recommend folks reach out both to me on Twitter or via email. Jess had an offer for any of us because we'd love to sort of figure that out

because that's where we're at with the product is technically speaking, we think we have most of it where it would need to be. But before we sort of say, yes, here it is world, everyone can have at it, we want to make sure that it's really, 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 it was a separate service did i hear that correctly because it does i mean as i'm using it appears to be running inside of the github.com main application

unless it's like iframed or something how does that service work and how does it how you guys build that yeah so it's ultimately uh a very very sneaky iframe okay okay they're making their way back it's 2019 the year make a note kyle daigle year the iframe it's back here i love iframes always have so yeah i mean you know one of, one of the, one of the, uh, one of the reasons that we kind of approached it that way is, uh, we have, um, 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 you can, we offer you all kinds of functionality, very similar approach to what we did with, um, with actions with the actions editor, because we wanted a way to uh iterate very quickly like that's candidly the whole purpose of this is just being able to move very quickly especially to customer feedback because we knew this was going to be a brand new thing

um and it would take some time so the the code in this is uh is i believe really canvas under the hood that the team that built the editor, we have some extremely, extremely talented front end folks that jumped in on this to make this work that the way it needed to. There's kind of two major parts. There's obviously the 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. So that side of it is implementing the, or really parsing the quasi-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. 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 would be very, very funny. We would be able to create these monstrosities of visual editors or rather workflows in the visual editor that looked either very ridiculous, but were, you know, contractually correct, or the exact opposite that were contractually incorrect, but looked beautiful. So the team did a really good job, even kind of in the last couple of weeks before we announced to make sure that the editor, you know, 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, you know, I don't want to say easy to draw, but much simpler to draw than say, a parallelized workflow that has dependencies in it. But building those two things out, one is a very, very, very difficult problem that we were able to sort of cheat around, which is, you know 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 sort of simple, I keep saying simple, but I could never write the necessary JavaScript to do this, but to do the 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 it hey it tricked this guy and hey i build web uis for a living so i didn't i didn't actually look under the hood i would have seen it but um when you just when you said on the show that it was a service i assumed it was just part of the main application so that's a cool way of you know know, somewhat decoupling, uh, at least your, your teams and your products inside of what appears to be a holistic application. So maybe, uh, listeners could take that little trick and say, Hey, it's the year of the iframe people. Yeah. There's all kinds of, 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 you know and like we never github is i think from the beginning always kind of really cared about um the product and like the user experience of what was happening. And in a lot of ways, sort of, you know, slowed to the microservice effication that we all kind of experienced over the last, you know, four or five years when that became very in vogue and it's been around forever, but, you know, became very in vogue. And 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 or a tool or an experience to our customers. And so you end up doing these tricky things where you think, okay, maybe I pulled this service out. So that way we don't have to, you know, 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 the parser or the scheduler, um, all these little things. But in a lot of cases, there's things that should be in the app and, you know, for the, for what powered actions or some pieces that are in the main GitHub, GitHub application. So there's all kinds of little tips and tricks as we bring new features to market, uh, that we, you know, have to make that choice. Uh, cause I don't think it's as simple as saying that there's, you know, a single technology approach that's just going to 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. This episode is brought to you by our friends at Rollbar. Check them out at rollbar.com slash changelog. Move fast and fix things like we do here at changelog. Catch your errors before your users do with Rollbar. If you're not using Rollbar yet or you haven't tried it yet, they have a special offer for you. Go to rollbar. If you're not using Rollbar yet or you haven't tried it yet, they have a special offer for

you. Go to rollbar.com slash changelog, sign up and integrate Rollbar to get $100 to donate to open source projects via Open Collective. Once again, rollbar.com slash changelog. so all this talk about actions has gotten me thinking about the bc boys right in the in the break why not but uh the next good step might be at the org level versus say just a repo level so 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 i mean definitely i think the i think the reason we started off with repo is we have a much clearer

primitive with the repository if that makes sense you know everything at github is really baked around the repository at this point but if you noticed uh 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 like two or three organizations, all being a part of one business, if that makes sense. So as we start to explore that as a company, you know, which we, which we talked about unified business identity and things that help that use case, um, we'll have a better sort of 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 and GitHub does is every time a new repo is created, take some sort of action. Sometimes it's auditing, sometimes it's creating, you know, 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 would be auditable. It would 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 of more foundation to lay to let those use cases be simple still inside of github and not sort of get uh into a horrible authorization management structure that you know all apps that sort of go that way tend to tend to fall into and still let our customers you know 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, you know, on their own hardware or by building their own things. I would imagine 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 like given GitHubithub actions is successful then we can come back to this bigger greater id and we can see where it goes visionaries can see org level you know actions being important however maybe right now you need to do far more feedback and iteration on the the core of it rather than thinking big picture at this point yeah yeah i i think so i also think it's about you know us wanting to solve uh you know a singular of a user problem or at least like a you know a developer tool problem as we can instead of necessarily wrapping it all up in

addressing that there's this like larger overarching primitive that everyone wants or like would like to have which is this business identity piece so for us when we try to solve problems like this especially with new uh like relatively novel things like actions we want to prove the case first that like the the the super nerd or like the high high-end developer the folks that really want to 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, uh, you know, through organizations, through the rest of the product as well. Um, so we're trying to focus on one piece first, uh, but I, I can't see how we wouldn't also allow these to be run at an organizational

level down the road. So we started out the show talking about marketplace. And then when we moved into the conversation around actions, we talked about pro bot and a lot of the apps and the bots, a lot of that functionality probably being rolled into actions or eventually you build it directly in actions, kind of eating that piece of the pie. It seems like, especially when we talk about CICD, you know, parallelism aside or resource limits aside,

it seems like maybe the 80-20 use case for that, the 80% of people are going to be okay just running their CI on GitHub Actions, I would think, assuming the product works and successful and all that. That being said, you have all these marketplace vendors and you have partners and you have the Circle CIs, the Travis CIs, 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, you know, potentially angering some of your vendors or competing directly as the platform with the marketplace? Yeah, for sure. So I mean, 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, you know, with with our partners, you know, 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 these things that, like you said, you know, encroach, if not, you know, directly compete with them, that we're just honest about what we're doing. They're businesses, you know, there's people on the other side and they deserve to know what we're trying to do. I think for us and in the conversations that came out of that and that universe, you know, what it sort of comes down to is that customers, uh, uh, customers first off are always going to choose the product that they think is like fulfilling their need the most, you know, servers have always been around

to run CI. People haven't always stuck with Jenkins. They go and try Travis CI. Um, if Travis CI isn't matching what they want, then maybe they're using, um, uh, Azure DevOps and their pipelines product. Like folks are jumping around to really find the great fit. So when we started talking to them, I do think that each one of these products offers something that is unique, you know, and is separate from what GitHub is completely offering. Even if we compete on a pure like compute level, like you said, like, let's say we're all offering the same parallelization, we're all offering the same compute, I don't necessarily that uh what actions is offering is going to completely you know eradicate the need for an external ci product that is solely focused on ci

do i think that open source projects small teams are going to probably use actions over the time over time absolutely i do i think it'll be easier i think it'll be fast um it'll be inexpensive you know or free depending and so it'll be 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 like the industry water level is rising, if that makes sense. of years ago we created projects into github where when when kanban boards and project boards seemed like an absolute necessity uh regardless of whether you're creating a uh you know a soup to nuts project management or issue management application it seemed like everyone needed this and so we added it to the application and we work with our project uh partners and they actually saw that their um business actually went up because uh we hypothesize at least that we brought some you know uh 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 or whatever and then they would go and use them so um i think the same is true in some ways with ci or at least this like raw compute piece, which is everyone's offering compute like 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, you know, like I talked about, I'll be in pull reminders at the beginning. There's tons of other small businesses like Greenkeeper and others that do that sort of, we're going to 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 five dollars a user or whatever it is so you know it's definitely it definitely competes like there's no there's no saying it doesn't um i just don't think that it's

uh it's going to stop these large businesses from being a necessity for a lot of companies. What I hope it does, though, is let's small businesses or even large businesses that want to try something out, build these very niche, interesting bots, tools, actions, you know, getting those into market, potentially open source is attached to a commercial product, which has been a very successful, you know, 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? So I could have a proprietary tool

inside 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 i don't have to worry about any sort of server infrastructure but just because the workflows are open source doesn't mean all of the tooling necessarily is right and i think you know like right now for example if github uh wanted to use an action or write its own action it's you can also embed those actions directly inside like the repo the private repo so there are there is an idea that like not every single action itself is currently public. It's just that, you know, 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. You know, I think the, the question looking towards the future is like you said, like, how can we, you know, first off, should we like, should we support this, this avenue and making it easier this way? Um, but then also how can we make it so that, you know, I could create an action, um, that is, that should be private or should be compensated for. Maybe it's not private, maybe it is public and it's just, um, uh, you know, an additional license like a sidekick and what Mike Perham does, you know, um, I think there's like a lot of different ways for us to help both the person

that's writing this uh software and ultimately bringing us 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 Slash Marketplace, an entirely new way to automate your development workflow. You 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 you know more visibility to other actions and how you plan to surface those yeah 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 um so like you, there's very few in there at the moment and doesn't match, um, like Sarah's list of actions, for example, um, looking towards the future, the, the thing that we definitely want to do is not just list them all out, but make discovery meaningful. Um, because there's way more actions than any list, or even just like name and description based search would actually be value like valuable for. So the thing that I'm really, 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. Like you'll notice the marketplace right now doesn't really have a rating system in it. You know, those have historically been gamified and don't always work. And if, if you have an unfortunate customer issue, maybe you go down or something, all your ratings go down to like, there's not a very strong signal to noise ratio on a lot of these rating systems. And you can see that in like almost every app store, you know, and there's been developer responses and it becomes a full-time job to manage your rating and so we're uh looking at ways like how can i show you that an action is uh 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 you can get on the outside, a bunch of the GitHub actions are available and sort of just say like, listen, we know you have CI. You don't seem to have any static code analysis, but your repository is, or your organization uh almost always works in python so here is something that most python folks use at an organization of your scale you know and they've used it for months like that's something that where would that be at would that be like the repo level or

it could be at the repo level it could be at the organization level it kind of depends right because you know like 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, you know, it would kind of depend on where you're looking at. And 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, you know, use it with your other repos, etc. But I think for actions, since we're able to see that it with your other uh repos etc but i think for actions since we're able to see that it ran that it ran successfully or it failed or you know uh it got installed and then immediately uninstalled like all those sorts of things uh we're we're able to bring a discovery

story that'll hopefully be really valuable you know 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 and what kind of category you're looking for. One of the other things I think that we have sort of overlooked a bit in marketplace, which I'd like to sort of address is a lot of these categories, for example, are verticals of these tools. Folks don't know what they even mean, you know, like 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. And 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 you know or one of the other tools that can tell you a little bit more about your code so I definitely think there's going to be a lot more investment we've been focusing on the producer side of actions for a bit but over the next couple weeks you should see some easier ways to find actions like you mentioned make it easier to install actions and then hopefully get to the point where we 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 uh you're betting big on this have you gotten far enough down the road of the beta to feel good about it that you know as a company there's a big bet on this um you know i think the thing that we're uh we're betting big on more than anything else really is this idea that uh you know the extensibility of of of the experience on github is the thing that we really want to make um uh like a bet on you know we're obviously making it so that way more people can use github with the free private repos that we offered well you know we're we're trying to make it easier to

to fill in all those little usage gaps that maybe were bothering like five percent of folks uh with the way it worked and then we released another improvement that five percent better for that other five percent so on and so forth um and i think i think with this what we're sort of saying is is we know our experience is powerful, but we might not have absolutely everything that you need. We might have everything you need, but we want to make it so your GitHub experience is continuously getting better every day, especially if you're bringing these outside tools in or using actions. So I think it's extremely interesting that we're doing the static code

execution. I think that is like we said it at Universe and I truly believe it that actions will be the next big movement in software development after pull requests. You know, 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 going to do the same thing, but for your software development workflow, which is historically, I feel like been either ignored or as an afterthought, you know, we spend so much time focusing on, okay, what does this code review look like? Or are we doing test driven development or 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, you know, how do I know it's good? How do I know it's going to 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 in the GitHub and have that experience in a single place instead of having to work with all these independent entities? So, I mean, right now with all the customers that we have in the beta, the feedback has been good. You know, like it's, it's, it's really scratching the itch for some folks. Like you mentioned the buzz on Twitter kind of picking up and like, I agree. I love reading what people are doing with it. And, uh, 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, you know, GitHub released the pull request. And just to reiterate to those that are in the marketplace now and, you know, people who may consider, hey, GitHub's getting into my world, they could be, you know, stepping on my toes or something like that with CI, for example. I think one point you said earlier that I want to reiterate is that, you know, 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, you know, some side eye from that perspective.

However, as you 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 offer free CI. It is a growth. It is a growth thing. you know, a lot of those products or 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, right? And you get that experience.

And so I think in a lot of ways, you know, the experience of trying out these tools, figuring out what matches, going and, matches going and buying the tool at work or deciding to use it in your small business or whatever, like that process is always going to continue because developers have very particular taste. Uh, get hub is not the only version control hosts in the world. You know, uh, Travis CI is not the only CI tool in the world. Uh, you know, Emacs, Vim, Adam, uh, VS, 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 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're going to build the absolute best editor or whatever, we want you to be able to do that. If you're going to 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 ecosystem as well to do all these things. So we're very excited to continue to work with partners and all this stuff. And I hope no one sort of 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, you know, insert integrator 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 go and look and say oh well you know i actually would rather go buy um this package management tool and i'll just use my action to push into that package management tool you know i was gonna say it's almost like an opportunity for a land grab

too for some of these partners because they can easily come on here you know i'm looking in the actions list here in Marketplace, which is accessible to anybody. We'll put it in the show notes, but I'm seeing GitHub Action for Azure, 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 anyways. So it's, it's an opportunity for them to play as well. Yeah, completely. And I think one of the interesting things when we were talking to a lot of folks, like we, like you mentioned at universe, the second day we showed a lot of partners and community folks like 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. And so 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 like 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 that, you know, this was introduced or here's the explanation as to why I built this. That way I can see that in the other tool. You see like the sneak action in there with their CLI trying to do a very similar thing of letting us just like interact with this other tool. The thing I'm excited about more than anything is not, not hopefully creating a situation where folks feel like we're competing, but that we're also letting these partners create,

have a new Avenue to, you know, work with customers and say, like you said, create an interesting action that extends their existing business and, you know, 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 a tool i already pay for there's a new thing that i'd love to go try out their tool um you know i think that's something that we'll see more of as we get to a you know the public phase uh 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 the 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 in actions and the teams behind actions that may not exactly be public knowledge

per se yet, maybe hidden in the detail somewhere what to give us some over the hill just near the future uh explanation of like where things are going or anything that we haven't covered yet yeah sure so i mean i think i think there's kind of a couple things so i mean obviously we we want to bring the actual compute to more folks and get further along in the beta program to get more folks access to potentially more powerful machines or more powerful use cases for them. I think that's one thing. 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 sort of response into an issue comment. Every integrator generally uses some version of an issue comment to give you data.

But what could happen if, for example, run kit, which is a very popular tool, allowed you to be able to pass back a sort of 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 like

what we're sort of looking to for actions is not just the code execution piece. I think that's what gives this like the excitement is you could do anything. But what happens when you can use actions to further change your GitHub experience? You know, 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, right? And 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 get sent back? What happens if we're able to use that action to put content elsewhere in the site? Like maybe I'm an engineering leader and I want everyone to listen to the change log, you know, so I want them to know what it is, right? Obviously, so what happens if I growth hack my way into creating an action that, you know, 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 kind of always treating integrations and 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. Like you mentioned, I don't think that code execution is... 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, um, you know, learn more about their existing code, um, being able to take advantage of the learnings that GitHub can have at the scale that we have via using an action. For example, if you want it to learn more about what, how your code base 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. And so I know that was slightly vague. Please excuse my best Apple invitation. 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. And so once we sort of cement arbitrary code execution and workflow management as a piece, we're, you know, I'm excited to continue to add those experiences on top of, you know, the GitHub that we all use and know and love um over the coming year or two i'm excited i think it based on i can really see an interesting future for this i mean i can even see where uh you might have paid tiers to where you know something i want to 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 longer compute cycle or something like that.

Even it's just, there's a lot of opportunities here and it's interesting how it becomes, um, this, you know, this separate layer on GitHub that just extends it. As you've said, I think it's really interesting to see where this goes.

Kyle, thank you so much, man. It was really appreciated to, to get this time with you and to walk through actions in this way. Thanks for your time, man. man yeah thanks both of you thank you for tuning into this week's episode of the changelog if you enjoyed this show do us a favor go into itunes or apple podcast and leave us a rating or review go into overcast and favorite it tweet a link to it share it with a friend and by the way you can discuss

this episode at changelog.com with fellow community members of course thank you to our sponsors and partners digital ocean get prime roll bar also thanks to fastly our bandwidth partner head to fastly.com to learn more and we're able to move fast and fix things here at ChangeLog because of Rollbar. Check them out at Rollbar.com. And we're hosted on Leno Cloud servers. Leno.com slash ChangeLog. Check them out. Support this show. This episode was hosted by myself, Adam Stachowiak, and Jared Santo.

Editing, mixing, and mastering was done by Tim Smith. Music is by the one and only Breakmaster Cylinder. And if you want to hear more shows like this, subscribe to our master feed at changelog.com slash master, or go into your podcast app and search for Change Log Master. You'll find it. Subscribe, get all of our shows, as well as some extras that only hit the master feed. Thanks again for listening. We'll see you soon. you logging during a show bro you're like that's like that's like pro level status like expert uh black belt stuff right there you know i was just uh it was there i was like why not you did it it's awesome uh commenting too bro bro. That's how I noticed because I saw the news comments. The news comments channel pinged me.

And I was like, what? I'm Nick Nisi. This is K-Ball. And I'm Rachel White. We're panelists on JS Party, a community celebration of JavaScript and the web. Every Thursday at noon central, a few of us get together and chat about JavaScript, Node, and topics ranging from practical accessibility to weird web APIs. Jared, I just have to ask a very serious question. When you're using that operator,

do you actually blurt out, bang, bang? If you were working in an office, would everybody just look at you? I don't blurt it out, but I definitely say it in my head every single time. Join us live on Thursdays at noon central. Listen and Slack with us in real time or wait for the recording to hit. New episodes come out each Friday. Find the show at changelog.com slash JS party or wherever you listen to podcasts.