Transcript

[Banjo music]

MANTRA: Just Build Websites!

Dave Rupert: Hey there, Shop-o-maniacs. You're listening to another episode of the ShopTalk Show, a podcast all about front-end Web design and development, and maybe some GitHub Action stuff today.

Chris Coyier: [Laughter] Oh... I don't know...

Dave: Anyway, I'm Dave Rupert and with me is Chris Coyier. Hey, Chris.

Chris: Hey. Hey. We have some absolutely special guests. We have Rizel Scarlett. How ya doin', Rizel?

Rizel Scarlett: I'm good. How are you?

Chris: Good! You are at GitHub, a GitHub dev advocate.

Rizel: Yeah.

Chris: What's up. Yep. Yep.

Rizel: Yeah.

Chris: I'm sure that's not all y'all do, but it's interesting. Can you--? What does that role mean?

Rizel: Yeah.

Dave: Well, you have to put an avocado next to your username.

Rizel: [Laughter]

Dave: That's the first step is--

00:01:02

Rizel: Yeah. That's the first step to becoming an advocate. Yeah. [Laughter] My role, it varies at different companies, but at GitHub it's all about empowering our users, making sure that they understand how to use the products to the best of their ability, and I've mostly been focused on open-source and early career developers.

Chris: Awesome. Awesome. Thanks. Yeah, we'll get into all that.

We also have Brian Douglas, which probably nobody even knows that's your name, right? @bdougie [Laughter]

Brian: Yeah.

Chris: What's up, man?

Brian: Yeah.

Chris: I'm sorry, bdoug. That was the more....

Dave: ...bdoug.

Chris: [Laughter]

00:01:40

Brian: Yeah, I need the phonetic spelling in my Twitter bio so that way people can pronounce it.

[Laughter]

Brian: Yeah. Yeah, thanks for the invite. As I mentioned before you hit record, a long-time listener. Probably one of the first podcasts I started to listen to when I got my first dev job in like 2013-ish, maybe 2014.

Dave: Oh, wow. Awesome.

Chris: Ooh!

Brian: So, a long time. Yeah, I work with Rizel at GitHub, but actually, actively on a sabbatical for the summer, too, as well.

Dave: Wow. Congratulations.

Chris: That's cool. Yeah.

Dave: That sounds awesome.

Chris: It's been a long haul at GitHub, right? I've seen you speak a long time ago. I mean I basically don't even remember, but it was kind of like early days of Actions, I think.

Brian: Yeah.

Chris: I think you were out there drumming up interest of, "Look at this thing! Look! What?!" [Laughter]

Brian: Yeah, just trying to get people just to try it, and so that would have been like 2018 is when I joined GitHub.

Chris: Yeah.

Brian: So, 4.5 years is my timeline that I have so far.

Chris: Yeah.

Dave: Wow.

Chris: Pretty good. Pretty senior these days, and so it's matured a bunch. Do you, Rizel, talk to people about GitHub Actions? Is that part of your purview? Yeah.

00:02:45

Rizel: Yeah, I do.

Chris: Heck yeah.

Rizel: I do.

Chris: Nice. I'd love to talk about that. It almost seems like it's hit a tipping point now where you hear it in conversation a little bit more like, "Well, obviously, we use that." You know? Or you read blog posts about, like, "Well, I was doing it this way, but that just seemed weird now, so now I ported it over to GitHub Actions because it seemed obvious," or something, which is probably a result of dev advocacy work. Right? It hits these--

It shifts the industry in some way where the opinion is just different because there's enough resources or something or enough other people they know have tried it or the trust has just welled up to the point where you're like, "Yeah, that's obviously trustable."

What do you think it is? Those are just my guesses. But it does seem more mature now, doesn't it?

00:03:39

Rizel: I don't know if Brian was going to say something, but I will say, before I worked at GitHub, I learned about GitHub Actions from Brian. Like you were saying, it's definitely -- I think, from my perspective, definitely because of that advocacy that I was like, "Oh, this exists, and this is how you use it."

I even wrote a blog post and was like just so mind-blown by GitHub Actions and then learning that, like, I can use it for beyond dev op stuff just automating my repository and automating issue management was a big game changer.

Brian: Yeah. I would say that when I joined GitHub, I joined in 2018. We had this little secret skunkworks project called Everett. I don't know how many people have actually shared this publicly, but it was a broader scheme of what the future of GitHub was.

All that stuff sort of got picked away and picked apart. What we ended up shipping was GitHub Actions, which was a way to have compute on GitHub.

Eventually, fast forward a year later, probably when you probably saw me speaking, Chris, we added CI natively to GitHub Actions. What we've done is we've made it really simple for folks, too. Simple is kind of a hard word to use, but it is pretty simple to get actions working on a Node.js or a Rails project.

As long as your project is extremely simple, you can add actions. If it's a little more complicated, we have tools and solutions and plugins and other actions you can add to also add PostgreSQL and docker images. Overall, it's automating the things you don't want to automate is what Actions does, but most people kind of align that with CI and CD.

Chris: Yeah. That's definitely how I think of it is like this thing runs when I do pushes. [Laughter]

Brian: [Laughter]

Chris: But that's just one potential action, right? You can line it up. It could just be the push of a button if I wanted it to be, right?

Rizel: Yeah.

Chris: Yeah.

00:05:32

Rizel: To work on a cron job, on a schedule, that part is cool too.

Chris: Oh, yeah. That is cool. Free computers.

Dave: What? This is my question. Full disclaimer, I am a GitHub Actions user. Somebody set them up in my project.

Brian: Thank you for disclosing.

Dave: And I don't know how they work, so [laughter] what would be--? What's baby's first action? What is the Hello, World? I have a project. It's on GitHub. I heard I have to use GitHub Actions to get employed now. What do I do?

Chris: Baby's first Action. Yeah.

Brian: Rizel, do you want to share about the Action you created when you first joined GitHub, like your first sort of crack at it?

00:06:21

Rizel: Oh, yeah. So, I had made actions before I joined GitHub, but the action I made when I joined GitHub was -- I'm trying to remember. I believe...

Oh, yeah. Okay. [Laughter] It was--

Brian: A long time ago.

Rizel: Yeah. [Laughter] It was for Pulumi, and basically, Pulumi is this cloud thing that helps you to connect easily with AWS and stuff like that. You can just write AWS code in JavaScript and it'll get deployed there.

I wrote an action that allowed my website to be served on an S3 bucket. Then any time I pushed something, it would appear or it would get updated on that S3 bucket.

Then in addition to that, before I did the push and just had a pull request, it would show me a live preview of the changes that were made.

Chris: Oh...

Rizel: I don't think that's really baby's first action. [Laughter]

Brian: Yeah. That might be a step past, like maybe toddler.

Chris: You made your own Netlify?

[Laughter]

Chris: What?!

Dave: I just made a Netlify, real casual, like--

[Laughter]

Dave: Yeah. Yeah.

Brian: Well, that's actually what -- I created an action called Logify. Full disclosure, I used to work at Netlify. I was like employee three back in 2016-ish.

When I went to GitHub, what I noticed was some missing features in Netlify's interaction with GitHub, their GitHub app. GitHub had shipped the idea of having logs for your deployments inside of GitHub, which now is what GitHub Pages is powered by.

I wanted to get my Netlify logs inside of GitHub, which not a lot of people follow that path. It's kind of like extra for the sake of being extra. But I've created the Logify to do that, to basically just use a deployment API, create deployments inside my log inside of the GitHub logs, and that way I can see it inside of GitHub.

Chris: Logs in logs?

00:08:18

Brian: Yes. I Logified my logs. But I'd say baby's first action is probably this NPM test.

Chris: Yeah, your Jest.

Brian: Getting your test to run. Yeah, your Jest test. Your V-test or whatever the kids are using these days. Just getting your test to run is probably going to be your first action.

Dave: I'm thinking through my application. What's that entail? You said for easier stuff it's easy, right? Do I have to spin up a local host or can I just run Jest tests? How deep does it go?

Brian: Yeah. The answer is, yeah, so the actions runner is at the cloud environment, so it is VM running on Azure now, thanks to Daddy Microsoft. That gives you an environment where you could just run NPM install, NPM run test. Then you're good.

You don't need to actually set up a local hosted environment or set up speeds and feeds or size of VMs. It'll just run the test for you. That one cloud environment gives you 2,000 minutes for free per month. Hopefully, your tests take less than 2,000 minutes, and you'll be pretty good. If not, swipe the credit card. You'll be good to go as well.

Dave: [Laughter] Yeah, I can run about 1.5 tests a month. It's good.

[Laughter]

Chris: Got them thousand minute tests. That's good.

00:09:47

Rizel: I will say I want to add that I think if people are starting off with actions instead of just writing your own, there's a whole bunch of actions and workflows that you can just copy and paste into your repository. We have the GitHub Marketplace, and probably if you're thinking of it, someone already created it.

I think way back when I first started at GitHub, we were like, "We have 10,000 actions!" That was nine or ten months ago, so there are probably way more.

In addition to the NPM tests, if people want to explore more, they can just go there and copy and paste it in.

Chris: Yeah, nice, because there are some boilerplate too, isn't there? If it's Node, there's--

We should say that all this is configuration based, isn't it? Like 100%. There's a .github folder or file or something that just sits in the refer.

Brian: The .github folder is like the magical folder that hides a lot of configs for you, so there are quite a few features in GitHub that are abstracted inside the .github folder. One of them is actions. And inside the actions workflows folder, you have YAML files. So, if you follow the syntax, if you actually go to any of your repos/actions or click the action tab, and you have no actions, they'll present you a Hello, World Action for you to sort of add to your project.

There are some heuristics inside of GitHub that will identify what language you've written your code in. It's a linguist plugin. It's like a Ruby Gem back in the day to identify.

Actually, I don't know if everybody knows this, but if you go in the right tab of your GitHub repo, it tells you how much JavaScript, how much Ruby, how much TypeScript is in your project. That's the linguist. It was a Ruby Gem. Now it's just a general plugin you can use for any language to identify the language inside of code bases.

We leverage that to identify what action we should present to you, and then that'll give you your Hello, World, like your NPM, just your test runner in general. That'll be just a suite of YAML files.

00:11:50

Dave: Wow. That's cool. I've seen some cool ones, like Amelia Wattenberger had this one that would generate a bubble chart of your code base. That's a GitHub thing, right?

Brian: Yeah.

Rizel: That's cool.

Dave: It was kind of like to be like, "Hey, new people. [Laughter] If you're just exploring this, here's kind of where all the code lives." Right? "Here's where it gets weird and big and complex."

I thought that was really cool. One thing I guess that wasn't clear was some of these actions will go and do stuff, like generate files and then they put it in your repo, right? I think that's what this one does.

But then doesn't that fire off another commit? I guess there's some intelligence there to prevent the infinite loop.

Chris: Oh, yeah. How do you stop that?

Brian: Yeah. We do have conditional runs, so you can run conditionals on file types. I actually use that action for my open sauce project that gives us the bubble chart for what components look like. But another one I built is for Storybook, so Storybook being the sort of design system UI template manager.

Every time I make a change to one of my React components, it actually generates a new Storybook deploy. The way I do that is I check specifically for my components folder. If anything has changed there, it runs NPM run Storybook. It builds it onto a new branch, which is called Storybook Static. Then Storybook Static is now being watched by Netlify. Netlify will deploy Storybook Static to design.opensauce.pizza.

Because it's a regular VM, just as if I were to do this manually, which I was, every time I made a change to any sort of component, I'd just run it locally, push it up to Netlify with a Netlify deploy. Instead, now I can do this without thinking. Actually, I'm not even doing it. The actions are running it, and it's because I have a full environment that can run any library, any plugin, as long as I have the right sort of image.

00:13:57

Dave: That's incredible. We actually gave up on Storybook because it just was extra, right? It was like, "Okay, we're deploying the app," but when we try to deploy Storybook simultaneously, everyone is mad. And so, we just said, "Let's not do Storybook at all." But if you have this whole other branch that gets deployed--

Chris: It's like a microcosm of the mono repo problem, right?

Brian: Yeah.

Chris: It's its own different thing. But it's neat how you can look at changes to a particular directory. That's kind of like a first-class citizen of actions. Yeah, that's cool.

Brian: Yeah, it's extremely powerful, too, as well. When you talk about mono repos or turbo repo, whatever.

Chris: [Laughter]

Brian: Turbo repo is the actual repo in projects, but as you think about, okay, I've got this one. Imagine we have this library, and you have the TypeScript one. TypeScript has a different build command, but I want to run builds for that one folder. You could set that all in conjunction, and you could actually have actions that run on actions. Based on if a test passed, or if the test failed, don't build and deploy to NPM. Rather, alert somebody in Slack or alert somebody in Discord or fire off some sort of fallback system to basically make sure you have some sort of--

I don't know. I mean your SRE, so when things fail, I walk away, so I'm not sure what the system is, but whatever the system is when things fail, someone can step in and come up to the plate.

00:15:30

[Banjo music starts]

Chris: This episode of ShopTalk Show is brought to you in part by Memberful. Memberful is software to help you sell memberships to your audience.

What would your business be like? Do you need to build this? This is an awesome way to build a business. But Memberful is for you the developer to build this. This is a whole package of tools to make building whatever kind of membership business you want to build possible.

It handles all the hard stuff. It'll take payments with Stripe for secure payments. You don't want to write that from scratch. Use Memberful to help with it.

There's a full-on GraphQL API. Which user is it? What access level do they have? All that type of stuff: Web hooks, OAuth, single sign-on.

You're going to have to build a login process and account creation process. Why write all that from scratch? It's just built into Memberful, this complete package for dealing with membership stuff. It's so great.

Let's say the home base of your website is WordPress. There's a best-in-class WordPress plugin so that you can control who is able to see what and where the upsells are and all that stuff. Really tremendous.

It handles all those transactional emails - so much of that. It's just everything all bundled together. You can get started for free. There's no credit card required.

Just think about it. If you're a smart developer, you're not writing all this stuff from scratch. You're leveraging other software that does what it does best so that you can build the integration of a membership website perfectly. Thanks for the support, Memberful.

[Banjo music stops]

00:17:10

Chris: Baby's first was running your tests, which probably seems like it's doing an awful lot of that, I would think, in people's lives.

Rizel: [Laughter]

Brian: Yeah.

Chris: But I don't know. How close is deployment? In the days before GitHub Actions, it did seem like if you were an armchair analyst of GitHub, you'd be like, "Isn't that weird that they don't -- they're not in the deployment market at all? That I have to wire up my own little weird system to deploy my website. Why is that?"

Then you're kind of half expecting GitHub to ship some kind of deployment-specific thing. But instead, we got GitHub Actions, which is the answer to deployment but just way more broadly. It's just one of the many things it could do.

If you want to deploy your website through GitHub Actions, where do I start thinking about that? How do I do it? [Laughter]

Brian: Rizel, she brought up the Pulumi action.

Chris: Right.

Brian: That being one step. I think what GitHub does a really good job at is we are the home for all developers, 83 million developers worldwide, and there's an opportunity there for other folks who want to have the attention of those developers to build in our marketplace or to build their own open-source actions.

Chris: Yeah. Go look.

Brian: Yeah. The ones that I've used is Azure. I really like their Azure apps action. Now, I don't use Azure for a lot of stuff, but the one things I do use it for is my Twitch bots. If I need to have a running server because I need Twitch to basically talk to my -- I call it -- slay bot.

I originally created the bay bot, which is a Beyonce bot. That was actually one of my first actions, which I can get into later. But the--

Dave: You were holding back on us.

[Laughter]

Brian: Slay bot is like bay bot, but it slays. What it really does, it interacts with Twitch and does things like if you start a repo or the repo I'm working on, it'll animate across the screen and say, "Hey, thanks for starting the repo." But we also have these unique commands for my chat on Twitch.

What I'm getting at is I deploy that with the Azure apps. What I have is a staging environment. Actually, whenever I have a PR open, I essentially rebuild Netlify deploy previews using Azure and GitHub Actions mainly because I wanted to have a running server, which I can't do on Netlify, and I like that pattern for deploy preview, so I just basically built that with the commenting system and everything from scratch through actions.

Dave: Whoa! Literally, today, somebody was like, "Man, deploy previews would sure be good right here." You know? I was like, "Not today. No."

[Laughter]

00:19:57

Rizel: I have thoughts to add on the deployment stuff. I hope it doesn't steer the conversation too far. But one of the reasons why--

I really love GitHub Actions, and one of the reasons why is because I used to work at a startup that we just did not have a good release and deploy process. We would have to release on times that users were not using the product. That's like Saturday night, and I was 21. I'm like, "I want to go hang out, but I have to sit here and do this deploy, like release our code." It would take hours, and I would always make mistakes and be like, "Oh, crap. I brought down the whole app."

When I moved to another company and I saw they were using a GitHub Action to do releases, and they could do it during the day, I was like, "What?! This is so awesome," so I just wanted to add that story in there.

Chris: [Laughter] I mean I guess there's just a heck of a lot of "It depends," right? What if the way that your website is deployed is by moving files over FTP or something, which is not totally crazy? That's probably how your Laravel site works - or something. You know? Or WordPress or whatever else.

Do I have to reach for some plugin that's like, "This is the GitHub Actions FTP machine"?

Brian: There's actually feature in GitHub Actions called Repository Dispatch, which will give you a specific webhook to point. If you have an FTP server, and you're like, "Hey, whenever I drag this folder, I want it to hit the GitHub repo to start a commit process," or start an action running.

It's well documented. It's called Repository Dispatch. That will give you the webhook to basically fire off an action.

I'm blanking on the actual internal talking actions to actions. But we do have ways to talk from actions to actions, like jump the file system to basically start trigger actions from internally in the repo. Yeah. All of that is available to you and highly recommend you check it out if you do have the very arcane way.

Chris: Nice. Is there some built in smarts like it's Git, so it probably knows what files have changed?

Brian: Yeah.

Chris: Is that built in? Can I say, "Push the new files up"? It's not like every commit is going to upload every single file in my repo, right?

00:22:29

Brian: Yeah. I guess, taking a step back, GitHub Actions is like a culmination of where GitHub was working towards for years. GitHub showed up on the scene around 2008. A month after GitHub was public, general adoption, they actually shipped the GitHub API.

GitHub has always been focused on providing primitives of the product, so API, webhooks, authentication. All those are things that you would have to become a really good expert at to build your own integrations. When I worked at Netlify, I got really good at working with the GitHub API and webhooks and authentication because login with GitHub, point to your repo, do stuff like this, and deploy here.

Chris: Yeah.

Brian: That's stuff that if you are an integrator onto GitHub, you just know. But not everybody is an integrator, so to make it accessible for anybody to make those types of interactions, even if you're just a solo dev, you now have that through a combination of primitives, which is GitHub Actions. Now you have webhooks and GitHub tokens and authentication all built inside of GitHub Actions just by default.

Chris: Primitives access. Rock 'n roll.

Dave: Do you all feel like--? I feel like you all are working with people, developer advocacy. I think, Rizel, you said you're kind of in the early developer zone.

Rizel: Yeah.

Dave: Yeah. Do you feel like you have a good sense of best practices around building your app or deploying your app or here's an easy path, or here's hard paths? Do you feel like you all have any intuition about that? I'm sure there are people listening to this, and they're like, "I tried it and it doesn't work with my thing."

Rizel: [Laughter]

Dave: Do you think there are better practices you can do for development that make this easier or what?

00:24:25

Rizel: I will say start with GitHub Pages and combine that with GitHub Actions. Just use the features that GitHub gives to you because GitHub Pages allows you to deploy a static website - super basic, super easy. Well, I shouldn't say basic or easy because it could be relative to people. But I think that's one of the easiest paths because you're using what's already inside of GitHub. Like GitHub Actions is inside of GitHub.

I think you can play around there and be like, "Oh, okay. Let me see if I deploy a page to GitHub Pages with GitHub Actions and see that if I do a pull request. What would happen if I do this with a GitHub Action?" That's, to me, the easiest path.

Chris: Wasn't Jekyll almost a predecessor of it or something? Like GitHub Pages would build your Jekyll back in the day, but you didn't have to do anything. It just somehow, automatically detected Jekyll or something.

Rizel: Yeah, and now it's evolving. I hope I'm right about this, but yeah. We're basically evolving GitHub Pages, so it is using a GitHub Action called Build and Deploy, or something like that. But now it's enabled for other things, or it's going to be enabled for other things like Next.js and React and stuff like that. That's what we're working on.

Brian: Yeah.

Rizel: I hope I didn't spill company secrets. [Laughter]

Brian: I don't know if you're really scooping anything, but it's definitely--

So, we're doing a lot of development around GitHub Pages at the moment. GitHub Pages now runs exclusively on GitHub Actions now. It leverages the collaborators.

Chris: Hmm.

Dave: Oh, wow.

Brian: That was a change that happened in the last couple of months around deployments, like the idea of Jekyll just sort of magically getting deployed. If you have a Jekyll site, you just didn't touch anything and it just deploys now.

We're moving that abstraction away where now you'll actually be able to see what is happening through the deploy logs. Then now GitHub Pages also won't be exclusive. It was never--

It used to be exclusively Jekyll. They exposed it to be if you had NPM run build and you just had static files. You can get there. GitHub is now going to be making that a little easier for folks to provide--

I don't know exactly what the interaction is going to be but having a build command is going to make it a lot easier now that it's all just built on Actions, so coming soon.

Rizel: Yeah. I'm out here spilling secrets. [Laughter]

Chris: [Laughter]

00:26:52

Brian: Yeah. It's funny because ... Atlanta. I don't know if you met Tommy. We just actually came back from Render(ATL), so we hung out with -- there was like 20 GitHubbers because GitHub is a very remote company. Tommy Bird, who is working specifically on the Pages team, he was divulging secrets.

What's funny about GitHub is that we ship stuff so fast and often that I don't know what's public and what's staff share.

[Laughter]

Rizel: Yeah.

Brian: And the way we ship features is we QA stuff with employees, so you could have a feature for like six months, so the achievements that shipped last week, I've had that for six months but I've been very careful not to share my screen, like on Twitch or anything like that, because then people are like, "Hey, what's that?"

"I can't talk about that. Sorry."

Chris: Oops...

Dave: Oops...

Chris: Pixelated.

Dave: That's cool. In some ways now the Jekyll sites, GitHub sites, or whatever, Pages was probably not a major, major feature, but a significant feature. I'm sure companies are running their websites on GitHub Pages exclusively. But now you're able to dogfood that, and it's now using your own build process. It's not this separate Rails task or something that's going on.

Brian: Yes.

Chris: I imagine it's just getting easier, right? If you wanted to write a Next.js site on GitHub Pages now, you could either ship the built version of it, which would be a little weird because people tend to--

Brian: Yeah.

Chris: You tend to not commit built files, right? Or you could write an action that ran the build....

Brian: Yeah.

Chris: Right? Now you're saying, maybe in the future, if the scoop is good data, that you don't have to write that action. It will either auto-detect or you'll tell it, "Hey, this is a Next site," and it will just do Next stuff.

00:28:46

Brian: Yeah. I would say a lot of the Next actions that have been built by community members of GitHub users, they do that where you just do Next build, so when the PR is merged in the main branch, Next build runs. You create a Next branch or deployment branch or whatever, and static files just go directly to that branch. It gets deployed. Everybody is happy. No one ever looks at that branch, and you just move on.

That practice is so common that I believe that not only GitHub, but other folks are also following that pattern and helping developers out by just making it easier.

Chris: Yeah.

Dave: Very cool.

Chris: Yeah. It seems pretty natural to be like, "What are the ten most popular static site generator-esque things? Let's make it easy for those things to exist on pages." Yeah, that's cool. That's cool. Might as well.

That's what you all do. All these companies have got to battle each other a little bit with what they're going to offer. Then devs and people that make websites generally just benefit from the stuff.

Brian: Coming from a place like Netlify, and also being at GitHub for so long, I prefer not to think of it as battling but kind of like raising the tide for everybody because, back in the day, I think, before SSL was a given -- let's encrypt -- that was the sort of $5 a month you'd pay for SSL to get that auto-generated. Even GitHub Pages didn't have that up until, I think, 2018, actually, is when they shipped that for GitHub Pages.

Companies like Netlify and then eventually Vercel gave that away for free, meaning that we didn't have to basically get charged for something so simple we could do ourselves but didn't want to do.

I think, with GitHub Actions, we're raising the tide a bit for everybody where compute is now extremely cheap, so let's just give that away by default. But if compute time or runtime is what's expensive, okay, that's still going to be charged. But I think eventually we'll get to the place in the next five years where runtime is trivial because we're all operating off Bitcoin and moonstones and stuff like that, so that way money is not a thing.

Chris: That's a nicer way to look at it. Probably part of the job, in a way, because you want to make people happy. I don't know. It seems like a dev rel sin to piss people off.

Brian: Yeah. There's always opportunity for collaboration. Yeah. [Laughter]

Chris: I just think if you gobble up deploy previews, automatic builds, HTTPS, throw cloud functions in there or something, it kind of is a battle because you're like, "What do they have left? Not much." You know? [Laughter]

00:31:35

Brian: Yeah. I was just going to say that Rizel just had a conversation with Solomon Hykes about Decker.

Rizel: Yeah. Yeah.

Brian: Which is like a perfect companion next step for GitHub Actions and what they're working on over there, which is former Docker founder.

Rizel: Yeah. He's doing some cool stuff.

Chris: Yeah. How does Docker factor in with GitHub Actions? Is it like I want to run these actions in a docker because the docker is already ready to go? I don't know if I understand it all the way.

Rizel: I haven't done Docker stuff, so go ahead. [Laughter]

Brian: Yeah, so you can build actions based on docker images, if you like. But because of the VM, if you present -- you can choose your environment, so actions will run on Mac OS, Windows, and a few different Linux environments. But with docker images, if you load up the docker--

Imagine you're running NPM, so the default. Actually, don't quote me because I wouldn't know what the default action running environment is. But let's just say, since I didn't look, it's alpha....

Chris: It's ... something. Okay, yeah.

Brian: Yeah, so Alpine, the image gives you NVM and Node.js and stuff like that installed by default. But imagine if you're like, "Oh, I want Deno."

Chris: Hmm.

Brian: Okay. Well, go find the docker image that has Deno installed by default. Start with that. That becomes not trivial to do, but approachable.

Dave: I have a docker in a GitHub Action. GitHub builds the docker and then pushes it to my registry. It's pretty cool because I don't want to do that. [Laughter]

But you know I did notice it kind of takes a long time. It's kind of like, blah. It's sort of like--

Are there ways to test this stuff locally or improve on it? Are there GitHub Action wizards that will come and fix this stuff? Is this stuff that exists yet?

00:33:31

Rizel: I think there are ways to test it without pushing it beforehand. Isn't that right, Brian?

Brian: Yeah, there are community-- So, natively, not really. That's kind of one of the misses, I guess, where Actions is right now is debugging. You could do self-hosted. So, if you run self-hosted locally on your own Mac or Windows machine, you could do that. But I mentioned dagger because dagger is building prebuilt images for you. I think dagger is going to be a really good solution in the future.

But other than that, there are going to be a lot of community actions. There's a tmux action runner to test stuff live in production. That's about it.

Dave: No. Okay. All right. I'll wait for it. I'll wait. I'll wait for the local action simulator that you guys no doubt have on your computers, but we won't talk about it. [Laughter]

Chris: It doesn't seem like a missing puzzle piece a little bit. It's like, how can I test this thing without having to test it by just push and wait?

Brian: Yeah. The PM from Actions who is listening to this right now, when it goes live, definitely, let's get it on the roadmap.

Chris: [Laughter]

Dave: Let's get it on the roadmap. Yeah.

Chris: Uh-huh.

Dave: Yeah.

Chris: Whatever. You know? Netlify has got it. You know? Cloudflare has a little local tester thing. You know? You're last, so let's go.

[Laughter]

Rizel: It's not a competition.

[Laughter]

Dave: There's Netlify and then Cloudflare was like, "No, we're going cooler. We're calling it wrangler," and so--

Chris: Yeah.

Dave: Game's on. You've got to come up with something really cool.

Rizel: [Laughter]

Chris: Rodeo, or something.

Brian: Yeah ... the product marketing folks.

Dave: Good. Good. [Laughter]

00:35:16

Chris: We talked. We started at the bottom, baby's first stuff, and then we started leveling up a little bit. Here's just mouth blog what I think a proper GitHub Action should be like.

First, the first thing it's going to do is run your build process, which is going to bundle your JavaScript, process your CSS, run your Hugo, whatever. It's going to do all that stuff. Get ready.

Then it's going to run Jest tests against that just because, of course, you've written some. Your site has to have an ad function. Your ad function better test that three plus one is four. You know? Because otherwise, you broke your website, so it's going to run that.

Then it's going to run a perf test on it. No, it's got to make a deploy preview first.

Rizel: Yep. Got to have that.

Chris: Yep. It's got to do that because then you have a URL to it, theoretically, that people can see. But because you can see it, that means some other tool that could run Lighthouse or something on it could see it, too. Then you'll get your perf report.

Then you'll run the perf budget against that, so you'll be like, "Oh, man. My website is 500 kilobytes total big, but I said 430 was the largest, so it's going to throw an error or something."

Then let's say that passes, or maybe these all run concurrently. I don't know. It'll run integration tests on it, so your cypress tests or reflex tests or whatever, because now it can do that because you have a deploy preview, which is clutch, right? So, it goes clicking around to make sure the H1s are there, that the form submits, or whatever.

Then it runs your visual regression tests for the design library, like your Percy tests or whatever to make sure that your blues are blue and all that.

Then it runs your accessibility tests to make sure that your axe dev tools comes back okay.

Then it probably runs prettier on the whole code base because let's say one of your devs forgot their prettier plugin in VS Code and they committed some files that failed prettier, but that would be a bummer if somebody else then pulled that file or whatever. So, just let it run that.

Maybe run all your linters too. Make sure there's no missing semicolons or whatever linters do these days - unused variables and stuff.

Then if there's any images in there, it'll optimize your images because why not. You know? Just hit the image. Run it through an image processor and put it back in the repo optimized. Maybe you do that for your SVGs too because there's SVGO and stuff.

Then update your site map, obviously. You know?

Then if all that passes, then kick it to staging, right? Then if it's a commit to main, then make it go to production too.

Ah! Pretty juicy pipeline, but maybe that's what I would do if I had a GitHub--

Rizel: Thorough. [Laughter]

Brian: That sounds like job security for one engineer.

[Laughter]

Rizel: Yeah.

Brian: But also possible.

Rizel: Yeah, it is.

Chris: I have not written that. No, but I do think that that would be cool to piece together.

00:38:19

Brian: I will add that I mentioned open sauce in passing. That's what I'm actually on sabbatical working on full time for the next couple of months.

Dave: Yeah.

Brian: We actually have a pipeline that builds a site, so it's a React app, so it builds it and has a build command. We actually deploy that. I have a whole system to deploy it to a GitHub Container Registry and a Docker Image.

The reason for that is mainly because my day job is GitHub, so I just wanted to prove the model. But if you wanted to go even a further step, like deploy a statically built site into an archive so that way you could have a way back machine for your project, that's all possible deploying NPM libraries as well after the thing has passed.

But my favorite thing is actually cutting releases because now we could automate release cutting through the GitHub API. We do that as well, so definitely worth checking out.

Chris: That's so cool. Yeah, you mentioned opensauce.pizza a few times. Do you want to get into that a little bit, what that is and what's up?

00:39:17

Brian: Yeah, so it's an open-source project to find your next open-source project. I've always had the passion for contributing but never knew where to start.

I created a few different tools, like the dashboard app.opensauce.pizza where you can store projects, hotopensauce.pizza is where you can discover projects. Then we're working on this new tool for insights in GitHub for projects at orgs to be able to identify where contributions are happening, like where is the heatmap of, "Oh, cool. First time contributors are doing well in this project."

Chris: Hmm.

Brian: Or, "Hey, I've got an org at my company. No one is contributing to this project." Basically, trying to identify supply chain misses when stuff stops getting contributed to, but also identify community help is what we're focused on at the moment.

Chris: Yeah. That's pretty--

Dave: That does seem like a missing piece, right? You get into open-source, like, "Cool. We're doing it." Then even bad actor notification, like, "Hey, this person is committed to 3,000 repos in the last 6 minutes," you know, or something. But you have these people involved. What are they doing? Yeah, that's cool. More than just commit history, right? Yeah.

Brian: Yeah. Spam is something that we're actually looking into right now because having this data, we identify where people are going to by repo to repo and saying, "Let me change this one line in the package.json."

Chris: Hmm.

Brian: That would actually be a flag that could be sent to the maintainer, and currently working with a large hackathon that happens every October. Sort of still in conversations with how we can support them but, basically, identify spam and identifying--

Chris: I remember that last October. There was a real surge in that, like, "Oh, I put an apostrophe in your :its, or something," just because you were that much closer to a T-shirt then, or whatever the game was. Yeah. It was a little hot topic for a minute there. Probably not the worst thing happening in dev, but hey, you know. It's something to fix.

Brian: Yeah. Just trying to encourage quality contributions.

Dave: Yeah. No, but I mean you know. We've had the NPM breakages too, right? It's just like somebody just snuck a line of code in there. Maybe you could -- it's not spam exactly because usually it's this big social engineering job, but how would you? I don't know. You just see or know the people who are kind of contributing to your stuff. You know? Interesting.

Or like you said, finding people, like, "Okay. These people contribute to this stuff," or whatever. Maybe I can reach out.

00:42:21

Chris: Speaking of spam. You're giving somebody a computer, right? This is a fact not lost on anybody. But think of all the havoc you could wreak. You basically handed a computer and say, "What commands would you like this computer to run?" You know? That is ripe for abuse. [Laughter] Is it not? I'm sure there are all kinds of stuff that went into place before it even shipped to prevent whatever, Bitcoin mining and such.

Brian: Yeah. There's actually a couple of articles around specifically Bitcoin mining and GitHub Actions. So, GitHub has this organization called the Security Lab. What they do, it's a group of security researchers that identify stuff like this. Definitely worth checking out and how we mitigate spam and how we mitigate bad actors.

We didn't really talk about how to limit interactions with Actions. If you want to turn them off, you can. Or if you wanted to turn them off to first-time contributors or outside organization members or you can turn it off to--

Chris: Oh, right, because that could be a PR, right? Then you could be like, "Ooh, thanks for the PR," accept, and the accept is an executing action in your GitHub Action. You better be really fricken' careful.

Yeah, now it's coming back to me that you could even format the PR to look like one of those depend-a-bot alerts, which you've been conditioned to just be like, "Oh, yeah, that's fine." Submit.

But it could have GitHub Action stuff in it. Whatever. I'm not trying to scare people. I'm sure you're doing work around that.

Yeah, like you said, isn't that one of them is to turn off, like, first-time contributors can't contribute directly to Actions.

Brian: Yeah.

Chris: Yeah.

Brian: By default, you can't, so you have to use a special command webhook, which is pull request target if you want to have third-party contributors, so open-source contributors to leverage your actions.

Chris: Oh, right on.

Brian: That's intentional so that way if you explicitly want an open-source contribution to use that, but then there's a permission workflow where you can then limit interactions from contributors. If you don't want people to actually edit code using actions, then you could actually block those actions.

Imagine you have, every time you merged a branch it bumps the release number. Perhaps you don't want that to happen from third-party contributors. You only want maintainers to be able to do that. You can actually make that limitation happen.

Rizel: I did not know this. I wish we had this conversation like two days ago because we had the maintainer summit, and we were having these little breakout rooms talking about actions. People were like, "Oh, yeah. We're just concerned about people contributing actions that we don't want," and I had no clue. If I already talked to you, I would have known that they could limit those contributions.

00:45:05

Brian: Yeah. Yeah, and there's a thing where if you added Action to one of my projects, it won't run until it gets merged into the main branch, and that's intentional because you could just add a new file, bitcoin.yaml. It runs the Bitcoin miner on your action minutes for 2,000 minutes. Then you don't realize it until the PR has been sitting for like a week.

Rizel: Yeah. Okay.

Brian: But technically not possible anymore.

Dave: Hmm. So, I think -- everyone, turn off the podcast. I think what we need to do is land a Bitcoin miner in like esbuild or Vite or something. And then we just get little bits of Bitcoin, and then we all share it.

Chris: [Laughter]

Dave: Yeah, I think that's the new business plan.

Brian: Yeah, I just had a conversation recently with Feross. He just created a company called socket.dev. I don't know if you all have talked to him yet.

Chris: Yeah, I've seen that.

Brian: Definitely a great conversation. He originally created the NPM Fund back before GitHub sponsors was a thing and got a lot of flack from that. But he's actually doing some really cool stuff with supply chain security with this product.

We went through a long conversation on my YouTube channel about this and how all these instances where people were -- like during the Ukraine war, people were doing protests, and protests against anybody in an IP address inside of Russia that would just arm.rf their entire machine.

Chris: Oh, gees.

Brian: They call it protestware. It was something I didn't know was a thing. Definitely worth looking into. But also, you probably won't get your Bitcoin Action shipped.

Chris: Oh, I see. So, NPM, you can -- those are executable pieces of code, or they can be at least. You can even put in a package.json. Isn't it if you name a script? I forget what it is. There's one, and it looks like a convention but it really is meaningful. It says whenever this is pulled, run that. So, you don't even have to explicitly run it. It will just auto-run when you pull it. That would have an rmrf star or whatever in it? Ooh... Wow!

00:47:21

Brian: Yeah, it's definitely worth looking into or leveraging things like socket.dev to have that run. That's specifically a GitHub App, which we didn't get to the difference between GitHub Apps and Actions, but Apps are going to be like company fully featured products that people are shipping. Actions are like more community-managed things.

Chris: Oh, I have no idea what a GitHub App is. That's a thing?

Rizel: Probot. Yep.

Chris: Probot. We well know what an Action is now, right? Is an app -- I don't know. Is it part of the marketplace?

Rizel: I think they're on the marketplace too, right, Brian?

Brian: Yeah.

Rizel: But I think it's kind of similar. I don't want to say the wrong stuff, but I think it was the precursor, the thing that came before GitHub Actions where you can automate stuff within your repo.

Chris: Oh...

Rizel: You would just install this bot or this app into your application, so you can use it for almost all the stuff you use for GitHub Actions.

Brian: If you're using Vercel or Netlify, which we mentioned a couple of times before, you're actually installing the Vercel and Netlify GitHub App into your repo. That gives you permissions to look through your file system to deploy that site to the cloud and everything like that.

Chris: I see because -- yeah, that makes sense. Netlify wouldn't be as successful as it is if they had to be like, "Okay, in order to use Netlify, copy and paste this chunk of configuration into your .github folder."

Brian: Yeah, exactly.

Chris: I'm sure that it'd still be kind of cool, but it wouldn't be that cool. [Laughter]

Brian: Yeah. You give permission to have Netlify write a netlify.toggle into your file system.

Chris: Yeah. Right on. Okay. Gees. This is a complicated product. You probably have dozens of developers over there. [Laughter]

Brian: Yeah. It's quite a -- we're a really healthy company.

Chris: Yeah. [Laughter]

Brian: Yeah.

Rizel: I feel like that's the fun part. Now I can advocate for random things. I could be like, "I want to talk about copilot or code spaces, or whatever," rather than just having one feature that I'm talking about all the time.

Chris: Ah, that probably would be kind of awesome, right? You don't have to beat the same drum just absolutely forever. There's other stuff. Technically, you work for Microsoft, right? They've got all kinds of stuff. You could be a Microsoft Word.... You could be like, "Have you seen bold? It's amazing."

Rizel: [Laughter]

Brian: Yeah. I'll pass.

Chris: [Laughter] Yeah.

[Laughter]

Brian: Now, Excel, sign me up for the Excel advocate.

Dave: Yeah.

Brian: Let me show you how to do these VB Scripts.

Chris: Yeah. [Laughter] That does sound....

Dave: This conference invited me to talk about open-source, but we're going to talk about the ribbon on Microsoft Excel.

[Laughter]

Dave: And get to know your ribbon top to bottom.

You'd mentioned copilot. How much code at GitHub is written by its own robot?

[Laughter]

Dave: Are there any stats from that?

Chris: Thirty five percent was the last one I saw quoted.

Dave: Thirty five percent.

Brian: That's a good question. I'd have to ask. I'm going to actually ask Copilot.

[Laughter]

Brian: And see what they respond back with.

Chris: It's a lab feature.

Dave: Just go to their office....

Chris: Yeah.

Dave: Copilot, "I have work to do."

No, please. Answer my question.

Chris: It's so ridiculous.

00:50:48

Brian: No spoilers, but I just watched Loki for the first time.

Rizel: For the first time?!

Brian: Yeah, I mean it's been out for a couple of months, but it turns out that that robot was worth paying attention to - or whatever that avatar was.

Rizel: Yeah. The little clock thing.

Brian: The paperclip thing. Yeah.

Rizel: Yeah.

Brian: I don't know if, Chris or Dave, you've seen Loki yet.

Chris: I saw the first few episodes.

Dave: I saw it. Yeah. Yeah.

Chris: I've got to get on that.

Brian: Okay. I won't spoil it.

Chris: I'm going to write it down ... catch up. Yeah, don't spoil it for me.

Dave: It's a good show.

Rizel: Yeah.

Chris: It is amazing, though. I'm up to 50%, I bet. I trust that thing so much, dude. You write one line and then you're like, "You probably got it from here, right?" [Laughter]

Rizel: [Laughter]

[Laughter]

Brian: Yeah, I mean....

Chris: It tends to pick up what you're doing. Hell, yeah, it does.

Dave: I think I disabled it. I'm not--

Rizel: You disabled it? Okay.

Dave: Well, it turned my job from writing code to reading code.

Rizel: Oh...

Dave: I was like, "Oh, God. I've got to read all this." [Laughter] It just turned it into this, like, "Oh, shoot. Okay. That's more work for me."

Chris: I do wish you could fine-tune some things.

Rizel: You've got to get a system, like start coding without it, and then it'll pick up on the patterns. Then you're like, "Okay, I could turn it on now." That's what I do.

Dave: No, that's good. I have a bunch of tests to write. I should just fire it up for this because I don't like writing tests. Just be like, "It," and then just let it try. [Laughter]

Chris: Yeah. I hate that. I wish I could turn that off, the, like, "Don't write English language for me. That's not my favorite." Or when it invents an API that you don't have but probably should. That always pisses me off, too. I'm like, "Yeah, that sounds great. Don't have that."

Rizel: Yeah. [Laughter]

[Laughter]

00:52:31

Rizel: I have a tough time when it's pulling on older code, like an outdated API version. I'm like, "Oh, man." But have you all tried Copilot Labs? I think that's fire.

It could translate code for you from JavaScript to Python or whatever language. That's super helpful to me because a lot of people come to me and ask me to help them with their code, and they're like, "Oh, I'm writing this in Python, but it's just like JavaScript." I'm like, "No, it's not. I can't read Python," so I just highlight it, put it in Copilot Labs, and then I'm like, "Okay. I get what you're trying to do."

Dave: I saw that. I saw it can, but then I was like, I just wonder what the limits are. I don't know. I kind of wanted to test drive it and be like, "Write this, whatever, Python in HTML," and just see how wild it gets.

[Laughter]

Chris: It's pretty outstanding. All right, gang. Well, thanks so much for having your expertise on here. We really honed it in on Actions, didn't we? That was kind of my secret goal anyway, but it sounds like you all think about that stuff a lot and literally advocate for it. So, sorry not sorry, I guess.

Dave: We appreciate you.

Chris: [Laughter]

Dave: Yeah. [Laughter] We appreciate you and your consulting, free consulting, so this was....

Brian: Yeah. I'll send the invoice in the mail.

Dave: Ah! Yeah. The address is 5 Pizza--

[Laughter]

Brian: Luckily the first 2,000 minutes are free, so you're good.

Dave: Oh, great. Wonderful. Well, cool. I guess we'll wrap it up here. For people who aren't following you and giving you money, how can they do that? We'll start with bdougie. How can people--?

Brian: Oh, cool. Cash App is bdougie to see how tips -- tips will go there, and then bdougie on Twitter, bdougie on GitHub. Either one of those, pretty much everywhere. Follow me on YouTube, bdoug on YouTube.

Dave: Yeah, you've got Twitch and TikToks.

Brian: TikTok, yes, I am a TikTok person.

Dave: You're a prolific TikToker. It's amazing source of joy for the industry, so appreciate that.

Rizel, how can people follow you and give you money?

Rizel: blackgirlbytes, I'm blackgirlbytes everywhere except for Twitch. On Twitch, I'm blackgirlbytes1.

Dave: All right. Do you stream? You're streaming as well?

Rizel: Yeah, I stream open-source stuff.

Dave: Oh, cool. Awesome. I'll subscribe. All right. Thanks.

Thank you, dear listener, for downloading this in your podcatcher of choice. Be sure to star, heart, favorite it up. That's how people find out about the show. Follow us on Twitter, @ShopTalkShow, for 16 tweets a month. Youtube.com/shoptalkshow for videos. Patreon.com/shoptalkshow for the D-d-d-d-discord.

Chris, do you got anything else you'd like to say?

Chris: Hmm... ShopTalkShow.com.