 Hey everybody, thank you very much for coming to my talk about GitHub Actions. I'm B-Dougie and I'm gonna jump in right now. So cool. So I'm gonna jump in, talk about GitHub Actions. There's gonna be a lot of examples. All of this stuff is open source. So feel free to take a look at the top of the slides for the URLs and the slides that have websites associated with them. But I'm here to talk about GitHub Actions. If you haven't, if you got this far, you haven't heard of GitHub Actions, it's totally fine. GitHub Actions is the way to automate portions of your workflow. It gives you a piece of GitHub primitives put into one feature inside of your GitHub repositories. So if you have a GitHub repo, you have access to GitHub Actions. Now, GitHub Actions is, the backbone is workflow automation. So it's a built in feature that connects a bunch of different primitives at GitHub. Primitives being GitHub API, authentication, web hooks. There's all things that you can leverage and have access to directly from your repos. So I'll go through some examples, but before I could jump into that, I have an analogy I'd love to share, or anecdote, which is basketball. The game of basketball, it's a sport that's played in across the world, actually. I was gonna say US, but it's all over the world. And it's kind of like soccer, if you aren't familiar, but you use your hands instead of your feet. And the opposite of the game is you get the ball in the opposing team's hoop. That's how you score a basket or a point. Now, there's a concept of full court layups where you have five members on a team, and instead of that person that takes the ball in, passing it, that person just basically scores the point everybody else sort of stands around. And the context of coding, cowboy coding, is something that comes up a lot. Folks who would be waiting for the senior engineer or somebody else on the team who has more context on the project to shoot the ball in the hoop or commit the code or review the PR. And sometimes it becomes a blocker. What I like to do is find out the best places. Actually, what the guy I like to do when I contribute to open source is find out the places where I can actually provide value. And in the game of basketball, there was a book that came out as well as a movement around whooponomics. It's when you apply statistics to the game of basketball. And at this point in the court, this is the half court right here. At that point, 31% of the shots go in and are made or that are tempted to go inside the basket, the hoop. And that's whooponomics. And the way they did it is they basically took all the shots that happened throughout the entire court and then they identified percentages based on that. So this right here, you get two points if that goes in. The reason for 31% is because most players are right handed. So at this point in the court, it's gonna be hard to defend a right handed shot on that side of the court. It's actually easier to dribble if you're right handed to the right side of the court as well. But there's so many other variables as well. But just note that if you know you're gonna get all your shots or 31% of your shots that are tempted, made there, instead of doing a full court layup, leverage the team, pass the ball from the one to the two. Once one correlates with the player on the team, so the two being our shooting guard, they're in position in area 31 to make that attempt or that shot. And if they missed, number three or number four is gonna grab the rebound or number two will grab the rebound. So everybody's in a position, everybody's doing their job. And that's what I like about automation is like, it's not everybody, but it's every bot. And we'll get into that in a sec. I like to actually explain this and ideas for automation through repetitive tasks. There's gonna be stuff that we do all the time, every day, once a week, we're via PR. There's all opportunities for automation. And that's what I love about get up actions because you can actually hook into those web hooks, authenticated interactions through the get up UI and make those automations happen. I'll share some examples in a sec. But if you haven't got, if you got this far and you don't have any actions in your repo, if you just click the tab on your GitHub repository, it will give you some actions. If you have a Node.js app or a JavaScript app or a Ditto app or whatever app, it will just identify that through heuristics and also because of file extensions that you have JavaScript and it'll recommend some CI, some MPM install, some scripts to be able to set up CI actions for you right out the gate. They look like this, it does infer like matrices. So if you do have projects that have different versions of Node that are required to be leveraged in the project, you can leverage the matrix. You can also run your CI, your build, your linting all through GitHub actions. And it also gives you access to entire Node environment too as well. So very similar to other CI systems. And I think I don't want to spend too much time on the CI side of the house because I want to talk about the continued delivery. But like with good CI systems, they kind of just work this. You set them up, you don't have to fix and break or fix broken CI's all the time. It should be like a, in a place that it works all the time, 99% of the time. Some examples that I have around continues delivery is like, there's one thing that I do in my projects which is I like to have a lighthouse score for my web projects. It's something I don't ever think about. I only run the lighthouse score whenever there's a problem or if I have bandwidth to start improving accessibility or improving performance, it's something I just don't think of until, again, there's a problem. The cool thing with the lighthouse action is that it actually gives you a lighthouse score at the time of PR. So rather than wait until there's a problem, check the lighthouse score every time there's a PR and then we can always work to improve the project's accessibility or the progressive web app score and stuff like that. The other use case I have is my Storybook. My Storybook.js I have a project called OpenSauce and all my components are built using Storybook or sorry, they're sort of hosted using Storybook. And it's a way for me to sort of showcase my design across other folks who contributed to the project. I have a front end project. It's called opensauce.pizza and this is my design system and if anybody wants to come in and contribute they can see my basic design here. And this is opportunity for improvement so people can actually kind of jump in there and get an idea of how this looks in the code but also in the UI. I mentioned this but I work at a company called GitHub. You've most likely heard of it. I mentioned it in quite a bit but collaboration tool, what we've been doing a great job of is collaboration at scale. We give access to folks repository and code across time zone, across computers, across whatever, how your situation, your teams are set up. We're here to support that. This the GitHub homepage is shouting out that this has been updated in the last six months and it's got a cool little globe but I also wanna point out that that number is outdated. It's actually 65 million developers worldwide and I bring that number up because I just mentioned that I'm a developer advocate at GitHub and properly introducing myself. My name's Brian Douglas. This is what I look like on the internet. This is my handles as well but the 65 million developers helps me with this term which is I'm a Beyonce advocate which I'm a big Beyonce fan and Beyonce has a lot of fans as well and I like to basically be what the people are just like the little mermaid. I like to hear the questions, answer questions. You have a question about actions, about issue templates, about all the stuff within your repositories. I'm happy to field those and introduce you to people who can give you answers. Speaking of Beyonce, I've got this project called the Baybot and this Baybot is a project I built as a joke last year but it's a Twitch integration to basically when you're live streaming folks can interact with you using this Baybot. It's built on JavaScript and HTML and CSS. Pretty basic. I've also built this other and the Baybot I've also built this as a GitHub action as well and it gives me the same sort of interactions but instead it's gonna be in your GitHub comments. I built this actually that issue right there is accessible. You can actually test out the Baybot yourself right there but it just responds with a gift of your choosing. So it's not Beyonce only. You can use a using to get a giffy API. You can present a gift of anything you would like but what I'm getting at is like a lot of these concepts I'm gonna bring up in the next few slides are all open source like feel free to jump in, jump out, leverage stuff for clone. That's the beauty of a GitHub action is that you can clone and fork and contribute the things that you can start building upon often. That's what I love about this conference and I'm super honored to be here again speaking about something completely different than I spoke about last year. But the one thing I wanted to point out is one thing that I had no concept of or ever tried or attempted to do with my projects which is generating release notes. I find this process a little bit cumbersome especially as a solo maintainer of a project. I just don't think about notes and making sure folks are all on the same page. I'm the one that's shooting the full court layups and using this GitHub action which is called release drafter. It actually gives me an idea of like the commit from this Shaw to that Shaw and all the commits in between and gives me a beautiful list of commits that I can share for my team. And it looks like this. This is my open source releases. You can see dependabot is a number one maintainer on my project and all the commits that they did in that week which is intense dependabot and you can slide out of it. They're all listed right there and I can keep track of like, okay, these are dependabot changes but these are all the changes from the humans up here. And I'm able to organize that through release drafter and it's all built on automation. Also shout out the semantic release. With GitHub actions, it's all based on YAML which I showed earlier but I didn't call out it was YAML. You could run NPM scripts or MPX scripts. So if you already have a GitHub token and NPM token you can do your entire automated release with semantic release which is a CLI tool that you can leverage inside your action workflows. So it's not about only using actions but it's also being able to have access to existing and ready to run node environments as well. Now this is sort of the meat of the conversation and sort of how I'm gonna round up this talk is cloud deployments and environment management which just sounds like a mouthful but it's kind of the heart of my CD workflow. I have a project called Slaybot. And Slaybot, it's kind of like Baybot but this one Slays and it's literally the description that's right there on the right. But it's basically Baybot but another level. So it integrates GitHub API to be able to whatever someone stars a repo on live streaming it will show up on screen. It's sort of like tongue in cheek and a lot of the stuff I sort of work on is kind of tongue in cheek. All right, so since I have a bit of time I'm gonna add a little... So since I have a bit of time I'm gonna show you a really quick demo of what Slaybot looks like. Best thing I could show is going into the repo and what I'm gonna do is I'm gonna start the repo itself and on the above you can see I actually started the repo screen. The other thing you can do is you can type in the yoke command and Beyonce shows up and shows that I am hype in the chat. This sort of sums up the interaction but let's just jump back into the slides. But I do live stream every Tuesday and Friday on twitch.tv slash biduggy. I build GitHub actions. I build open sauce and I also build a couple other things. And I like to interact with my community and have folks like feel like they're on stage with me but without needing to be in front of camera. So with Slaybot, what I do a lot is on stream I have to fix stuff for the bot and I also have to set up staging environments too as well so I can test things out. So basically you're building the shift while you're trying to sail it down the river exactly what I'm doing with Slaybot. I've got in my environments, I've got a staging environment which I have here you can see on the right and I've got the production environment. Sorry, the production environment. And I will go into a great detail of this and I'll actually zoom in on that. But basically GitHub offers an ability for you to set up environments in your repositories which makes it easier for the point deployments for GitHub actions. It's something we shipped in the last six months so I encourage you to check it out. I'm able to also highlight in my YAML the environment name too as well. So I have an environment called staging and I'm also pointing it to this URL. So I've got a separate staging URL that I only deploy whenever if you look on line 42, whenever there's a pull request I'm only deploying the staging. That's the only time I have an opportunity to deploy the staging is all automated and I can set up approval so that way only one staging is live at a time so that way I don't have to pay more money for that. And then the other thing that I do is I leverage this thing called GitHub Script to be able to have a comment directly with my PR on that staging URL. And the way I'm doing that is again, with GitHub Script this is the actual GitHub Script that I'm using and leveraging GitHub API again. It's part of the primitives for GitHub actions and I'm able to take that URL from Azure which Azure I'll show you in a sec but it's an Azure action web app service that allows me to deploy to Azure from GitHub and then return a URL. Take that URL and I'm adding it to the comments and this is the code that I'm using to have this right. It's all open source, feel free to copy and paste or delete. I might not accept your PR if you delete it though. And the other thing I'm doing is I'm uploading artifacts. So with this might be obvious but maybe depending on this might be your first issue or first time you've heard of anything like this before but with Azure it expects a zip file or a zipped repository to be able to deploy it. So I'm using this GitHub action which is called web app deploys it's all GitHub actions are they're just GitHub repositories. You can contribute open issues do it as you would like with them. And what's cool about this is with the artifacts I can use a GitHub action to then build an artifact which is my repository uploaded to my PR. So basically in my actions tab I can upload an artifact where I can see and download the zip and whatnot. And I'm leveraging this here. This is like my build script or my build job basically. And you've looked towards the bottom that's where I'm uploading the artifact using the action slash upload artifact V2 GitHub action. I'm naming it node app which if you saw before it's called node app right here and then it's just grabbing all what's in the sort of current directory. And this is my deploy step which I'm leveraging again this is for staging but if you scroll down to like well if you look down to line seven which I didn't highlight that's where I'm getting the web app URL from the Azure web app output. And then I'm downloading artifact and then at that point I deploy it. So this is the the so crux of how I get my deployments to work while I'm live on the air and streaming. And it gives me ability to basically make a change or a fix or add a feature in front of an audience and do some live coding. And it gives me the ability to do that continuous delivery and continuous deployment. So I don't have a lot of time to go into a lot of details. Again, this is open source. Definitely check out the repository that I shared earlier called Slaybot. I might be the only Slaybot on GitHub. I'm not sure yet. Automating storybook. I wrote a blog post on dev.to about how I do that. So again I can't go into detail on how this all works. But I do encourage you to definitely check it out. There is my design system too as well if you also want to check it out and contribute to it. I forgot why I have that slide there. But and then finally the lighthouse action. I mentioned in passing, this is my lighthouse score. So I'm able to see the score in my actions tab inside the logs. I didn't have time to go into details about the logs because I wanted to focus more on the continuous delivery piece of this. But there I got my logs. Every time my PR happens, I can historically look at the context and what's changed. I can even make this a comment on the PR as well if I wanted to. And it gives me everything I need to do to basically make this work. Also shout out, I didn't mention too as well, but you could also have your URLs inside of your workflow visualizer, which I sort of breeze by. What you're looking at here is the workflow visualizer. You can visualize your workflow and the steps as they sort of depend on each other. Also want to shout out that my GitHub profile, it's powered by GitHub Actions. I intentionally built a MySpace clone using GitHub Actions into GitHub profile for me. So if you want to dig into that repo, find out how I'm leveraging code to powered by actions to be able to keep my top eight up to date. Man, I wrapped. Now also shout out to my YouTube because like and subscribe, but also I have some GitHub Actions tips and tricks as well. So I've got a playlist there if you're interested. Reach out if you have questions because I end up making those in the videos because it's easy to have that at the point to folks in the future. Also wrote a whole blog post on how I built the MySpace on my GitHub profile using Actions. Check it out. And again, just try Actions. And I hope you find this insightful. I'll be around the Q&A sessions. So find me or find the sessions and I'll be there to answer questions. All right, thank you very much. And this is what I look like on the internet if you forgot. All right, have a good night. All right, a good day.