GitHub Action Traction

Brian Douglas: [0:00] What's up, you all? My name is Brian. I go by bdougie on GitHub and bdougieYO on Twitter. I'll actually introduce myself in a couple slides. First, I want to introduce GitHub actions. You're probably here, because you want to get an understanding of GitHub Actions.

[0:13] That's awesome, because that's what I'm going to talk about. We're going to discuss high level GitHub Actions, what you can do with them, and some examples of how I use them in my workflows. Let's jump in.

[0:23] GitHub Actions is a way for you to implement custom logic into your repositories. Custom logic, in the ways, think of automation. I'm going to be focusing a lot about automation and automating your developer workflow in this session.

[0:36] Before I jump in, I want to shout out Colby. Colby actually has a course on egghead all about creating your own GitHub Actions to do automation with using JavaScript. If you want to get a deep dive or get your feet wet with this, after this conversation and talk, definitely check out that course.

[0:54] Also, if you have a repository, and you want to use GitHub Actions as well, it's going to give you a little hint, click the Actions tab up in your repo, and you'll be met with this screen.

[1:03] The screen will identify if using JavaScript, or Ruby, or whatever language in your repository, and recommend action workflows for you. When the action workflows that I want to talk about right now is the one that is recommended for you for doing generic CI testing in your node or a JavaScript repository.

[1:24] Here, I'm running this on whatever the default branches, what GitHub actions gives us, it gives you error runner hosted on GitHub infrastructure to, one, run at least to run your CI or your tests, but you can also do more than that.

[1:41] When most people think of GitHub Actions, they think of running tests or doing CI. I felt introducing the actions is probably going to focus on this for a couple slides because I want to get this out of the way, so I can talk about some other stuff.

[1:53] Here's an example of a note CI that's given to me for free from the GitHub Actions tab, those are the same heuristic provided workflow templates that we saw before in the last slide. I don't want to focus too much on this because I want to talk about some other stuff besides CI.

[2:09] I bring this up because CI is something that I think mostly introduces folks into GitHub Actions, mainly because you don't have to go to another provider or another solution. You could enable this on your template using open source CI tools.

[2:24] You can leverage npm scripts, or you can leverage Jest, or whatever your flavor of JavaScript testing of your choice. What I bring up is a perfect idea of a CI/CD workflow. It works. Obviously, we're seeing a superb athlete identifying a need to automate and getting logs to the basement. What I love about this, is that these are opportunities that we should be looking for all the time in our repository, in our code base in the way we interact with other developers and collaborate.

[2:59] I mentioned CI briefly because there's so much other stuff we can do in addition to CI and CD. One of the examples is iLeverage, I'm going to jump right in an example. I briefly touched on this. I'll go into more detail later at the end of the talk, one of the examples I have is the Lighthouse Action.

[3:18] The Lighthouse Action gives me an opportunity to, one, get Lighthouse scores at the time of PR.I love using this action because, one, it's open source, so I didn't write any of the code to support this.

[3:29] Two, in my mind, when people use Lighthouse scores, they do this in production. You take a production URL. You run the Lighthouse CI, or you open up your chrome console when you get your Lighthouse score. The thing is, I never think to do that. The only time I think to do that if there's a problem.

[3:45] The beauty of this is that this action runs every time you open a pull request, and it gives you a Lighthouse score at the time of PR, and I'll show you this at the end. I love this action. I wanted to mention up front, and then also mention event at the end because it's a good introduction to something beyond just CI.

[4:01] The other thing is automation of my Storybook Design System. This is something that I set up a special case for whatever I want to deploy my Storybook. I want to deploy this whenever I make changes to my React frontend. The way I did this is using GitHub Action.

[4:19] If you're interested, I do have a Dev2 post that you can check out called automating My Storybook deployment, using GitHub Actions. Search it out. See if it's good for you. If it's not, leave me some feedback.

[4:32] This is what the design system looks like. I have a separate website specifically for the components of my web app. Then, I've got an entire deployed site, that's also deployed using Netlify.

[4:44] What I wanted to do is I wanted to separate the deployment, so that way, the design system would deploy, and then also the Netlify deployment for OpenSource.pizza, which is the app that I'm working with here. It will deploy separately, and I'll get the details on how I orchestrate that through GitHub Actions.

[5:00] I jumped right in. I didn't introduce anything, because I just wanted to jump right in. I did also want to mention, I do work for this company called GitHub GitHub. If you got this far and you're down here to GitHub, congratulations.

[5:14] GitHub, it's a tool that I think most of us here in the room have heard of. If you haven't, how I recommend, head over there. Sign up for a GitHub account, and then go try some new tutorials maybe on lab.github.com, or maybe even try some Egghead courses that cover GitHub as well.

[5:31] This is my employer. What we like to focus on a lot is collaboration of skill. We're collaboration tool for developers to help coordinate, especially asynchronously and the time of 2020, 2021. We need to be able to collaborate to push code, to not let systems go down, and still have that interaction. That's what GitHub really, our bread and butter is.

[5:55] I myself am a developer advocate at GitHub. This is what I look like on the Internet. Brian Douglas is my name. I do want to show off my GitHub profile, which is bdougie. I show this off because I like sharing the fact that I built a MySpace Top 8 on my GitHub profile README. This is a feature we shipped last summer to help showcase your talent, your skillset as a developer.

[6:22] I took the initiative of doing something different. The cool thing about this is it's powered by GitHub repo, which means I can do anything I want and code, and then rewrite my README programmatically. What I did is I built a GitHub Action to add folks to my Top 8.

[6:42] The way it works is basically, whenever someone opens an issue and adds themselves to my Top 8, I will regenerate a new profile README. I encourage you to check that out if you're interested. It is powered by GitHub Action. I won't get into details on that, but wanted to mention now.

[7:00] GitHub Actions, I mention this up front as a way for you to customize workflows, within your developer workflow inside your GitHub repos. If you want to summarize all that, is that GitHub Actions is a tool to get out of the way, so you can continue to write code. If there's opportunity for you to improve part of your workflow, you can potentially reach for GitHub Action.

[7:28] To break it down even further, GitHub Actions built on top of a couple different primitives here at GitHub. One being the GitHub API, the other one being web hooks and authentication as well. These are all different things that usually take a lot of work to put together yourself.

[7:44] You got to manage your web hooks instead of receive any sort of changes or do a watcher on your repository. You're going to hit some roadblocks mainly rate limiting, so definitely use our web hooks. The API itself, it's a very large API. It's been around since GitHub was created.

[8:00] The API, a month later, was also shipped. Authentication, managing your own Personal Access Tokens and JWTs as well, can be a pain, so we provide that to you for free to use, GitHub Actions. Keep that in mind.

[8:16] All these sort of primitives, they'll build this one thing, this one feature which is workflow automation, automating parts of your developer workflow. I like to bring up this analogy, which is basketball. Now, please bear with me.

[8:31] This is a basketball court. If you're familiar with basketball, it's like soccer except to use your hands. The object of the game is to get this ball to the opponent's hoop and get the ball in the basket.

[8:43] There's a concept in the game of basketball called full-court laps, or I guess, being a ball hog, where you have five people on a team, and one person on that team could take all the work. They could be the cowboy coder. They could be the lead engineer that doesn't pass around the ball enough to get other people involved in the team, if there's always opportunities to optimize your workflow.

[9:09] I bring this up because in the game of basketball, this is a term called Hoopanomics. It's been taken from "Moneyball," so baseball. They use statistics to identify the best players and the best teams.

[9:19] They did the same thing with basketball and identified on the court, 31 percent of the shots at this point of the court will go in. This is the highest rated points that you can get a shot in, so anywhere else it's going to be less. Three-point shots will be less.

[9:34] I bring this up because what's happened to the big game of basketball is that when you figure things out like this, everybody over indexes to get the ball to that point on the court. We saw this with the three-point shot in the last couple of years. We see this area 31.

[9:51] What this here is five people on the court. This is me identify routing out a basketball play where the number one takes it to number two. Number two's already at area 31. They shoot the ball. That's the opportunity, if you can get the ball to area 31 whether it's number two, three, four, or five and this numbers are identifying the person on the court, and their position.

[10:13] What I'm getting at is if you know that you've identified a repetitive task that you're going to have to do every single week so, let's say, it's code review, if we can get code review done by Wednesday, if we can get our stuff in by Thursday, whatever it is, you know we're going to have to review that code.

[10:30] How do you optimize for your workflow to make sure that code gets shipped every week, every sprint, every month, every year, if you do Waterfall, whatever it is? When we think about GitHub actions, we always think about how do we get this get our test to pass, but there's so many other aspects of that automation piece.

[10:51] We know about source control. Source control being the way GitHub operates. It's built using Git, but also you can use SVM if you wanted to. We won't get into that. What I'm getting to is the Build step is the thing that people think about.

[11:05] What about staging? What about production? How do you get stuff shipped? How do you cut releases? What happens after production? Being able to automate those portions of your workflow are things I'm going to bring up in a moment.

[11:17] The other thing is linting. Linting is something that comes up too, as well as part of testing. How do you identify if something breaks in the linting? Do you have a pre-commit hook? I personally find pre-commit hooks annoying, so I usually don't leverage those. Instead, I push those to the PR.

[11:34] If I have something that falls out of the linter, I have automation to automatically lint that code, and then push it back to the PR, rather than trying to force people to fix stuff before they can commit, because that can get annoying if it's Friday at 5:00, you just want to go home or close the computer.

[11:54] We do have features like the GitHub Checks API to be able to add these sort of annotations to your code as things start failing. I bring this up, just minutes, these are what the checks look like. If you wanted to have checks in your code, you can hook into that. The nice thing about this is they can give these to you for free.

[12:15] The one thing I also want to bring up about linting too, as well, back in this year, summer 2018, GitHub made the decision to remove all jQuery from the UI, so github.com itself had jQuery back in 2018 in order to taper back how much jQuery we are maintaining and moving closer to JavaScript.

[12:36] The reason for this decision is because that a lot of stuff that we were doing was not complicated jQuery, and a lot of that stuff you could use in normal, sort of in Vanilla JavaScript. What we did is every time you open a PR and including jQuery, it would run a transpiler and provide you to JavaScript from the jQuery.

[12:56] Not only did we do that, we create comments in the code like this. You could identify what code in JavaScript, you should be writing instead. If you happen to change something unrelated to jQuery code, and you're like, "I touch this file, but I don't want to fix the jQuery. I'm just going to move off."

[13:13] We would give you the code directly in the PR. Then, all you have to do is commit that code, copy and paste the code. Put it in the PR. Let the test pass, and you're good to go. That's one, identifying a task that is repetitive that you can automate to improve the workflow for all developers not just yourself.

[13:39] I also mentioned reviewing a pull request once a day, it's another opportunity for you to identify places where you can improve your workflow by saying, "Hey, we're going to reprove PRs once a day. How do we automate? How do we get folks to encourage them to review that code?"

[13:55] One, being notifications every time a PR is open, send a notification to discord. Send a notification to slack. Those are all opportunities for you to automate and get folks on the same page, folks on the same team on the same page.

[14:10] I bring this up, and I want to focus on examples now. These examples are going to be open-source stuff that you can leverage in your project today. One thing I love doing is generating release notes, something I never did prior to last year, and mainly because I didn't know how to write proper release notes.

[14:30] What I love about this is that I use this GitHub action. I did mention earlier, but we have a marketplace for GitHub actions. If you want to GitHub Marketplace, github.com/marketplace, you can search for /actions.

[14:45] There's one which is called release drafter. What it does, it exactly does that. Every time you push a commit to your default branch or whatever branch you choose, it's going to cut a draft release with that commit, who changed it in the title and a PR that was merged.

[15:01] I love this because it gets me in a position to be able to think about what's going to happen. You can look at my releases. All these releases here are organized based on what types of changes happen. These are all sort of generated as I've merged stuff there. I didn't write any of this code. The only thing I have to do is change the title and the tag, and I'm good to go.

[15:29] Definitely check it out. This is what a final release looks like. This is another project I work on which called Open Source. I've taken all my features, my bug fixes, my chores. You can see with Dependabot I had a great time in my last release.

[15:47] All this is automated. Now, every time I cut a release, I know exactly what's happening. Everybody who commits to the project knows exactly what's happening, and the historic context is always intact as well. This is something that I personally like, open source of the project I contribute to, every now and then.

[16:03] I didn't have the forethought to basically go and massage releases and write them in a way that anybody can walk in there and understand the context. By me, automating, I never have to think about that every time I merge a PR, and deploy that to production.

[16:21] I want to also talk about cloud deployments and environment management. This is something that, it goes above and beyond simply running your test. I bring this up because we just shipped a project, which is called skyline.github.com, which I briefly showed in a different slide before, but I didn't call attention to it because I knew I was going to have it here.

[16:44] This is a real fun project we did during the holiday break, called skyline.github.com. What it is, it's an opportunity for you to type in your GitHub handle, and then see what your GitHub commits look like in a 3D printed image.

[17:00] This is me typing in my coworker Michelle's handle. I can see Michelle's commits. There you go. Then, I have a choice to, it was very brief, but I have a choice to download that asset or send it to Shapeways to get it 3D printed and shipped to my house.

[17:18] It's a little project, I wanted to show the context of it for the sake of the next couple slides, so that way, you know what we're working with. This is a project that's using STL files it's using some web GL as well to generate these 3D printed images on the fly.

[17:34] I bring that up because here's a demo we did in a recent conference which is setting some different environments for this project. We have a staging environment, so that way, when we produce, whenever we do a PR, we can identify a place for this to get deployed to, that's not production for us to test.

[17:58] Here, I can add different secrets specifically for staging. I can add reviewers, and I can do a couple other different things like doing a wait timer, if I wanted to wait for this to deploy Intel 24 hours, or 36 hours if I wanted to only had one staging to share amongst the team.

[18:15] I bring this up because environments is something that, folks, you might not be aware of that you could do and GitHub, but it's a good way if you do have a deployment platform, or you're deploying to AWS, and you want to be able to manage different buckets. You can do that here in GitHub, and point that within your GitHub Actions as well.

[18:33] That is an example of what you would do with these environments. Here, I've got a PR, which is linked to my staging environment. You can see the link right there. I can click through and check out to see what it looks like.

[18:45] Here, this is deployed to Azure. I can test it out and see if it's working, which is good news because we're going to find that it, yes, it is working. Thank you, Katie. Katie, another one of my co-workers here at GitHub, and we see it's good.

[19:01] I love this because you could also do protected environments. Here, Katie is going to be approving this and then approving the deployment, so it's another feature within, it's built within GitHub Actions as well as within your GitHub repositories. If you wanted to do a full on CD pipeline, connected to the metal of Azure, or AWS, or Google Cloud, there you go.

[19:25] This is a closer look to the GitHub action workflow. If you are interested in how this works, feel free to take a screenshot of the video. If not, I do have another project I'll share in a little bit that you can check closer. Unfortunately, this Skyline project is private, so I can't share more than this. I'll move on and I'll show you the project you can check out later.

[19:50] The one thing I like to do is compressing images, at the time, a PR as well. It's something that I don't think of. I mentioned GitHub Marketplace. If I wanted to look for actions that compress images, you can do search directly in the marketplace, You'll be good to go.

[20:06] This is a website, it's my website, bdougie.live. The one thing that I do, is every time I present, I go to a Livestream project on Twitch. I go to bdougie.live, and I added to my project. The one thing I don't do very well is compress images. I use whatever I can get my hands on. I realized that's a problem. Here's the GitHub actual workflow.

[20:29] In this workflow, I mentioned this before, but GitHub Actions run on a number of different workflows. These are also webhooks. Webhooks can be run on GitHub Actions, events. This one's running on pull requests. Every time a pull request is open, I'm going to look for these paths. JPEG and PNGs, as well as WebP.

[20:53] I'm going to go and run a build, to basically check one, I'm going to check a conditional to see if this is a pull request to the actual default branch, which is head. Then, I'm going to go through and run this caliber image actions. That's going to run and compress all the images that I'm looking to compress, which is what I'm looking for JPEG or PNGs or WebP.

[21:20] The beauty of this is that at the time of PR, this is a screenshot for one of my PRs, you can see the performance improvement based on this one PR. I have a bunch of images that I did not bother grabbing small sizes. I got like a label image, which is way too big. It's like one megabit, actually even compressed.

[21:43] I try to fix that anyway, but you can see the reduction in size, 62 percent, 44 percent, 60 percent. That's a huge reduction that I'm not sending into production. I'm able to do that with the GitHub Action.

[21:57] One thing that you also can do is you could upload artifacts. This is going to be interesting for, my example here, is every time I run the Skyline PRs, I actually use Playwright which is like puppeteer, but well, it's basically the same thing.

[22:14] Playwright has a headless web browser that goes and take screenshots in three different major browsers, Firefox, Edge, and Chrome. Then it uploads those to my PR. Every time I'd open a PR, if I'm not around to do a staging environment test, I can do some headless browser testing, and then upload the screenshots directly to GitHub Action. I do that with another GitHub Action.

[22:44] I didn't focus on this too much in this conversation, but all GitHub Actions are is a GitHub repo. You could write GitHub Action code, specifically workflow code in your repos that you're running your code in, or you could route those in a third party repo, as well.

[22:59] In this case, I'm using a GitHub Action, which is one setting up Node. I'm going to run JavaScript in this action, and I'm going to leverage that to then run Playwright, to do that headless browser testing. Playwrights going to look for my Playwright test and run those.

[23:15] Then, finally, I'm going to take those and upload the screenshots of the Playwright testing, it's going to run them to a folder called end-to-end browser images.

[23:30] I'm more than welcome to go into details or answer questions about this tutorial. I realize I'm going into way too much detail. I don't have enough time to break all this down.

[23:45] One thing I did want to bring up as well is the idea of self-hosted runners. There is probably in some cases where you do want to use your own stuff. You're paying for your own servers. You can do that by going to Settings, switching from GitHub or hosted runners, to self-hosted runners, and it gives you the script to basically do that for you.

[24:04] The beauty of this is that copy paste is in my environment running all the commands to install a runner. The runner itself is open source, so if you're interested in looking at code, you can. This is the actual runner running.

[24:17] If you have any interest in using Kubernetes to manage your self-hosted runners, this is open source actually, so there's an open source utility to manage your runners through Kubernetes. Definitely check it out.

[24:32] It was put together by one of our solutions engineers, so I'll have to defer any questions to them, because I don't know much about Kubernetes, but this is available for you. This is an example that is showing how to manage these GitHub runners.

[24:48] All the green ones are the ones that are running. Every time a PR is closed and merged, it shuts one down. That's example that's happening here. This, right here, was a GitHub repo, that's the name. Then, this is the repo name. Check it out if you want more detail on them.

[25:06] Also, check out this repository for awesome runners. If you're just looking for other use cases for GitHub Action, self-hosted runners, I defer to this repo for ideas.

[25:18] I alluded to this in the beginning, which is the idea of continuous delivery. These two actions that I mentioned up top was automating My Storybook deployments. I didn't want to break this down for you, so definitely check out the DEV2 posts if you want more context.

[25:34] On line four, I'm running this on any pushes to the main branch. That's the name of my branch. I'm looking specifically for paths in the stories or components folders. If you're familiar with React, code components is where a lot of my React components will live, and then stories is where my storybook components or storybook stories live, as well.

[26:00] The way this is working is I'm running an npm command. If you look in line 18, some of my playwright actions, I'm running a build script specifically to build storybook folder. Sorry. I'm using a build scripts to build storybook. Then, I'm going to take that and deploy that directly to Netlify.

[26:25] On the other end, Netlify is looking specifically for the branch, which is called storybook static. If you're familiar of Netlify, you point to branches for deployments, or you can deploy the entire repositories, and then deploy all branches. The way this works is that Netlify only deploys open source from the main branch. I've got a whole other Netlify app that deploys to storybook static to storybook.

[26:51] Again, this is what it looks like. That's the trickery of how I end up managing that, but I did want to point out that line 20. I'm using James Ives, his GitHub deploy action.

[27:05] I'm pointing it specifically to version 3.4.8. If you saw earlier the releases, if you've ever cut a release, that you could cut a release specifically to a tag. That's what I'm doing here. 3.4.8 is a release tag. That's how that works. That's how this works.

[27:29] The Jake Jarvis action, the one thing I did want to point out too, as well, is that this is running on pull request, but the beauty of this is that every single one of my actions, those logs are available to me in the actions tab. I can leverage and find out my performance. I have accessibility of all the Lighthouse score. I can have a historic record every time the PR has merged.

[27:50] If there's ever a question of like, why did the progressive web apps fall down to 56 points? I can go back historically and say, "OK, let's just go back in the logs and see when this number went down." If no one was paying attention when did the number go up, I can always figure out at what point everything changed. That's Lighthouse.

[28:14] If you're interested in seeing the Skyline demo live, there is a video from GitHub Satellites India. That's a lot of the examples I took from that example. If you are interested in seeing my actions, I am on github.com/bdougie. You can search by actions, and you'll see all the actions I've written, if you're interested in leveraging them.

[28:33] If you want to get greater context on how to leverage actions, as well, I do have a YouTube video series where I have tips and tricks on GitHub Actions, so from what are GitHub Actions, to manually running your GitHub Actions, to compressing images. I do go in greater detail in those videos.

[28:52] Again, it's available today in your repositories. If you're not using them, definitely check them out. Definitely a great way to get started with CI, but also through automation of your workflow.

[29:05] That's not my name. I'm a big Beyonce advocate, which is a whole other joke, whole other talk. BrianDouglas@GitHub, and those are my handles. Definitely reach out, and I'm looking forward to answering your questions.