 And there we go. Hello, everyone, and welcome to I&E's bootcamp series, GitHub for everyone. My name is Brooke Seahorn, and this is actually going to be a really cool. I know you've always heard people say, I couldn't be more excited. You think, yeah, whatever. This is actually going to be very cool. In this particular series, what we're going to do is we're going to be diving into GitHub, looking at some of the features. And the main thing I want you to remember about this is is GitHub for everyone. One of the things that a lot of people miss out on GitHub is, it's not just for developers. It's not just for infrastructure people. You can use it in so many different ways. It's really creative. But the problem is most of us don't or are not even aware of the technical capabilities that are there. So with that said, again, hi, my name is Brooke Seahorn. First of all, welcome to everyone who's showing up. I'm seeing several people, Aziz, Baron, Matt, Varyn. Hey, everybody, Keith. Hey, man, Keith Bogart. The amazing instructor we have here at I&E is also going to be sitting in the attendees room. And there's actually a lot of people from inside I&E who are going to be watching this because GitHub is just such a powerful tool that we want to let everyone, even the folks working in I&E, know about it. Now, for a little bit of a switch up here, there's something I need to tell you. A little bit of a bait and switch. I'm not the instructor. Remember at I&E, we're all about experts making experts. And even though I'm learning a lot about GitHub, I think what I'm learning more and more is that I've been doing some things wrong. And the person I've been learning from is the person who is going to be leading this and in fact came to I&E from GitHub. And I'd like to introduce him down, Mr. Matt Davis. Hey, Matt, jump in, man. Hi, everyone. Thanks for showing up. This should be an absolute blast. Great segue, Brooks. Couldn't appreciate you more. Let's jump in and talk about you and I real quick before we get started. As Brooks spilled the beans a little bit prior to I&E, I did kind of do a little time over at GitHub. And it was an absolute blast. And one of the best things that I learned while I was there is that GitHub has so much more to offer than what we realize from the outside looking in. We're used to developers using it or students using it to use or to source code their actual or version control their source code, right? So we're used to them using it for development projects. What we're not used to is the HR team using it for documentation. What we're not used to is using it to give all of our managers a view of work in progress. What we're not used to is making the work that we're working on available to the rest of our organization in case they have something they can chip in. And then we're also giving them a guide on how to do that. And that's something that really opened my eyes when I was at GitHub to the capabilities that this platform has. I'll take it even as far as telling you that to request time off if you're a GitHub employee, you use GitHub. And that's kind of weird, right? You're probably used to going through a system like Just Works or some sort of HR management tool to request your time off. For us or for them at GitHub, not us anymore, we would open issues to request our time off. And what was really cool about it is it wasn't just an issue. When we opened that, an entire series of automation would kick off and add that time off information to Google calendars, to HR spreadsheets. It would put it in wherever the visibility was needed. And the employee had to do nothing other than open an issue. It was really cool. So what we're hoping to do is expand your horizon on what GitHub has to offer you. Some of you might be developers. Some of you might not be developers. I hope there's more non-developers than developers in this session because I think you're going to get a lot of insight on how you can enable your developers. So hopefully we can teach you a thing or two. Prior to GitHub, I traveled all over doing DevOps consulting. And prior to that, I worked at a college. And prior to that, I did network and stuff. So I've been all around the block. And my most current is here at ID. And what's really cool is I get to bring all of that expertise to the table and talk about a tool that I just truly firmly believe in. And that's the big thing is I could sit on any high horse from a third party that said, hey, will you promote our tool? That is the exact opposite of what's happening here. This bootcamp, although it's about GitHub, this isn't a sponsored thing from GitHub or anything. We at I&E saw the power of GitHub. And we couldn't help but share it with you. So it's just something that we really believe in and believe can make your workflows a little better. Absolutely, absolutely. I'll kick it over to Brooks. If you want to throw a little bit of your background out and then we'll do that. Absolutely, yeah. I've been in I&E coming up on one year as an instructor here for AWS. Prior to coming here, I was at AWS, the mighty AWS, where I taught all sorts of facets of cloud. And I can tell you that, you know, the things that Matt just talked about, the collaboration, looking back, there were situations where we really should have been using GitHub. One of the most, I don't know if you've ever run in this sort of situation, Matt, where, you know, you're having teams collaborate just on documents, but these are big, big, big documents. And there was a real push on inside about getting rid of some certain types of language inside our public facing documentation or at that time AWS's public facing documentation. The challenge was, Matt, was that you're talking about, you know, a document that can have typically hundreds of pages in it, making sure that when it goes to legal, legal can see just what changed when you're passing around Word documents. Wow, that was a real challenge. Absolutely. That was, dude, the solution was right at our fingertips the whole time with things like GitHub. So I think that's really cool. And by the way, I hope y'all heard the thing that Matt said there about requesting time. That's the flexibility of this tool that even things like that and become such a great single source of truth for what's out there. So anyway, yes, I was at AWS, I was there for several years. Prior to that, it's been many, many, many years working within the national defense architecture, particularly for the DOD, the different branches of service, implementing cloud architectures. And then of course, back before that as a software developer, still a software developer today, Matt and I have great conversations about Go and Rust, it's actually fighting at one another about which one's better. So goes the better language. Yeah, we'll, I'll straighten you out, man. Don't worry, we'll get you straightened out. So that's my background right there. But I can tell you, you know, truly this tool is one of the most overlooked underutilized things that you can have advantage to you. And the thing about it is the sucker is free, absolutely free to individual users. There's some higher levels that Matt will teach us about, but it's just, it's free for the using. So we really do need to take advantage of it. So that's a little bit about me. Excellent, thanks for that Brooks. Yeah, man. So we'd like to know a little about you and we know that you guys can't jump on the mic or do any kind of screen sharing but I see one of you has posted in chat, it looks like VJ says that he worked, or works as a network engineer, no prior GitHub experience. I would love to hear about some of the rest of you guys that are in attendance. You go ahead and post that in chat. Tell us, you know, a little bit about you. And what we're really curious about is one, like your GitHub experience, like that's super helpful just to know, like if you've messed with the platform, under what capacity you've played with the tool, whatever that might be, but the most important piece is tell us about a collaboration challenge that either you currently face or have faced in the past. And I wanna prompt you a little bit, consider all the possibilities of collaboration. There's collaboration in your immediate team. Brooks and I have to work together every day, we don't tell anybody, but we have to. And that means that we have to communicate, or at least our work is better when we do. So we have that inter-team, or that intra-team collaboration, but we also have to work with the production team, don't tell them what we're forced to, again. And that's inter-team. So how do we help other teams collaborate with us? And then on occasion, we might have to work with other organizations. And you're probably in one of these buckets, many times throughout your career. So I'm curious to know like, what are some of those challenges that maybe you faced? And we'll give you like 30 seconds to type them out. Yeah, just a little short blurb, absolutely. Cool, so it looks like Barron says that he's also a network engineer working on DevOps and Ansible. High five, what up? I love Ansible. That is my configuration management utility of choice, absolute favorite tool. I got my DevOps start. And you're just now learning about Git and GitHub. We are gonna rock your world. I think that you're gonna leave the next three days. Not only are we gonna show you how to version control all your Ansible playbooks, we're not gonna dive into Ansible specifically, but all of the concepts are gonna apply. You're also gonna learn how to pipeline those. I've done some really cool stuff with Ansible and GitHub Actions, where I used GitHub Actions to take, the playbook files and provision the infrastructure and just automate all these pipelines. And we're gonna talk about that pipeline automation. We're gonna do a little bit for the quote unquote developer. And then it's mostly gonna be around like how you can apply this to things that aren't exactly dev or DevOps related, but much more like people management related. All of this stuff is gonna apply. And I think you're gonna walk away feeling real good, real good. Cool. So Keith says demystifying concepts of repositories, branches and stuff like that. Yeah. You're in good hands. That's a horse that we will be sure to tenderize thoroughly as we go through this bootcamp. Another network engineer, let's see your prior experience. Okay. I don't know how it might help with Cisco DevNet, but it might. What I can tell you is that any type of note taking you're ever gonna do, GitHub is a wonderful, wonderful place for that. And on that token, all of the files that we work on are gonna be shared with you through GitHub. So that's the super cool like magical review. I know a lot of you are probably gonna want a copy of the bootcamp itself, which again, just check INE in a couple of weeks, the editing team, the production team, they're gonna be awesome. They're gonna put that up there. But maybe you wanna leave something on Friday or leave with something on Friday. We got you covered. All of you will know exactly how to interact with the repository that we used through this bootcamp. And you're gonna get to take a copy of it with you. And that's gonna be super cool. Absolutely. I'm gonna be all set. So if we go fast, right? If we go fast and if you feel like you skipped something and you really want us to share those files and those notes, just know it's coming. You're gonna get absolutely everything. And you might even have visibility on all of our commit history along the way too. Yep. Without it being cool. And we'll talk about that. And one thing I wanna add in there real quick, Matt, because I'm looking at Matt and Brian, some of the stuff they posted into the chat. One of the best things about having Matt here to take us through this is the fact that if you've got a little bit of experience, you may have some events like when you go, cause I've been doing that work and I go, oh, I was doing that wrong. Or there was a better approach to it. For example, are we gonna talk about issues, Matt, in this particular bootcamp? I might have an issue with issues that we'll discuss. Yeah. See? And the proper use of issues really, I could not believe I had missed something that was right in front of me as an absolutely game-changing tool in terms of improving the flow of work, improving the flow of communication. It really does change the game. Also when it incorporates with things like the board, which I think we're gonna talk about that too, aren't we, Matt? About what? I'm sorry, I didn't hear that. The board. Oh, absolutely. Yeah, yeah. So- We are gonna do quite the deep dive into a lot of the service level features. Yeah, so as you guys are going through this, not only is it a learning experience, but for those of you who have a little bit of experience, I would open your mind to the possibility that maybe we're doing it wrong, because I know I have been and Matt can show us the right way. This looks like we have a question. How does GitHub provide us all of this? Is some of it free? Yeah, so there is no catch. Like that's the craziest thing. Yeah. And I'll dive into that in the next section. So just hold that question for a second. Let me set these expectations. And that's actually what we're gonna start with, because I totally agree with you. Such a great question. How can it be so great? Yep. If there's no catch. If there's no catch, Matt, and the catch is there's no catch. Like that's the craziest thing about it. Again, I'm gonna get overly excited because I'm just passionate about this tool because of that right there, the fact that there's no catch. It makes no sense. It makes no sense that this is free. Right. So here's the expectations for the bootcamp. Let's set a couple of things up. First and foremost, we are gonna hound on GitHub. It is gonna be the focus of the next three days. Most of the stuff we talk about, brand strategies, issues, version control, collaboration, it does apply to other platforms, right? Other platforms are like Bitbucket and GitLab. This isn't to say that they don't solve this problem either, right? This is just to say that this is Matt's tool of choice to solve this problem. Feel free to use your tool of choice. A lot of what we're gonna talk about will transfer, okay? So if your company uses GitLab, don't think, oh shucks, I'm not gonna get anything from this. Same principle, right? It's just like Azure and AWS. They all offer kind of the same thing. Same thing here. Just a different name. There's different company, different tool. Okay. The next expectation is if you're looking for a specific recipe on how to solve some very niche problem, I apologize ahead of time. You are in the wrong place. We are gonna talk about leveraging this tool largely in the sense of collaboration and automating some of that collaboration. We're not gonna talk about how this tool fits into the DevOps pipeline in depth. We're not gonna talk about how GitHub provides you with this super rich history that allows you to roll back bugs that made it into production in depth. We'll touch on it, but you're not gonna leave with how to solve my specific problem. You're gonna leave with how to start thinking about using this tool to solve your problem. Second to that, if you're a developer, sorry, we're not gonna build an application and we're not gonna be writing any code. We might do a little bit of that, but the focal point is not that. Does it help you understand Tanzu, Kubernetes? It's gonna help you understand keeping the version control for your manifest in order. It's gonna help you understand working with other DevOps engineers to write those manifests. You're gonna be able to do code reviews on those manifests. Again, it's gonna help you understand the collaboration part behind it. Are you gonna learn anything about Kubernetes in this? Nope, not at all. Nope, but it's going to help you do Kubernetes better. Absolutely. With those manifest, Matt, that is such a big deal because the collaboration with a worldwide team, that's the sort of stuff that we had at AWS, you can easily and quickly share. You can look at the differences and you can make suggestions. It's just fantastic, Vijay. I think you'll really enjoy it and learn a lot. Again, we're not gonna be diving into Tanzu, Kubernetes, obviously, but you will have the foundation of going, ah, I see a better way. Exactly. There's a lot of things you would get from GitHub that we'll talk about along the way. The security features can help with those manifests. You may have been in a situation, you wouldn't be unique if you were, where a sensitive API key or password kind of got stored in a file somewhere. I know someone that could be guilty of that at some point. GitHub helps with that type of stuff. Yeah, it does. So those are the major, major expectations. The last one that I wanna hit on is that this is a 100% participation kind of thing. We're gonna build in some time for you to be able to do some of the stuff that we're working on. And because of that, there are a couple prerequisites that come along with this. One, I'm assuming is a bad assumption, but I'm assuming you got a web browser. You have access to Chrome, Safari, Brave, you should probably be using Brave, personal opinion, whatever it might be. You have access to a web browser and here's the catch. You're on a network that can reach github.com, okay? So if you're VPN through work, you can't get to the GitHub website. You're gonna have a bad time getting it fixed. Let's make sure you can get to github.com. Outside of that, those are your only prerequisites. I don't need you to have a bunch of other tools installed. Just be told, you don't even need to have git installed, okay? So we're gonna do all of this inside of the web interface, which is gonna drive some of you nuts if your terminal freaks. Again, this guy, but that's okay. Again, we're driving home different concepts. All right, the last thing is if I go too quick because I get crazy excited in chat, say, Matt, you're crazy, slow down. You've had too much coffee. Let Brooks talk. We don't like you anymore. Whatever you need to say, throw that out there so I know to slow down, okay? Oh yeah, because I talk slow. Absolutely, man. Exactly, exactly. So are you gonna show how to do stuff with both Windows and Mac, respect to just one plot twist? I'm gonna use Linux. So, everything I do is gonna be on Linux and I can give you from the stuff we're gonna cover, it does not matter what operating system you use to truth be told, if you wanna be fancy, go grab GitHub Mobile and do all this from your phone because you can do that too. So the operating system is not a factor, right? It's all on github.com. So it's gonna be all through your web browser. So your operating system doesn't come into play at all for this. But that being said, if you wanted to do certain things locally, you could use Windows, you could use Mac, you could use Linux. I use all three depending on what I'm doing in my daily life and I use GitHub for pretty much virtually everything all the time. And hopefully you'll see why along the way. So don't feel like I'm on a Mac, I can't participate. Don't feel like, oh, I'm a Linux user, I can't participate. Again, if you have a web browser, you are good to go and it's that simple. Good questions though, I appreciate them and you're thinking in the right position here. What's really cool though, before we jump too far, when we get to this GitHub action section, you'll learn that GitHub actually supports all of these operating systems for its automation, right? So some of you might be deploying infrastructure on Mac or that is Mac-based infrastructure. Others might be having using Linux-based infrastructure. Some of you might be writing applications for all these different operating systems and GitHub is built to handle all of that. So I know when Brooks and I collaborate, he often uses a Mac and I use my Windows machine and we make commits to each other and you'll see throughout the interactions we have in this bootcamp, it might be helpful for you to know this, just based on this question. I'm gonna be on a Linux machine and Brooks is using his Mac. So as you see us interact with one another, that's kind of the ecosystem that we're working within. And you'll see that he can collaborate with me just fine through this. Are you gonna have any breaks? No, we are driving a tight ship. We will never, ever take a break. So... No, we will be having breaks at the top. Yeah, we'll be having breaks at the top of the hierarchy. Sorry, that was on everyone. My fault too. Always breaks, always breaks. We will be having breaks and what we'll be doing is either at the top of the hour or just whatever is opportune, we'll be doing in there. So yeah, expect those everyone. Yep, absolutely. We gotta step away from these lights a little bit as the time goes on because it's a little warm. Oh yeah. All right, so now in order to request a break though, you're gonna need to submit an issue. That sounds gonna work for breaks. Okay, so we're gonna start, I'm gonna throw up a quick poll, right? Before we really dive into this, I have just a couple of true, false questions for you guys that I kind of just want everybody's, again, participation on. So let's take a look at this statement. GitHub provides developers a place to store project source code. You think that's true? Go ahead and hit true. If you think it's false or you're unsure, go ahead and hit false. And as soon as we, yeah, that's great. Awesome. We got 12, how many other people? We got 29 people. Nobody disagrees that this is true, huh? Oh, some people, we got maybe unsure, okay. We're gonna call it unsure rather than false, right? Because that's important too. Cool. So you're right, right? This is how GitHub is known. It's known as this tool used for, here I'll share these. Everybody can see the results. This is known for hosting billions, if not trillions of lines of source code, right? From developers. And that was its primary purpose when it was first developed. It is now not the case thanks to things like DevOps, right? The push for DevOps said, we need our tooling to do much more than just be a simple version control interface. Let's jump to the next one and take a look at what that has to say. I'll launch this poll for you. GitHub users need extensive command line knowledge. This is something I hear quite a bit. So let's see. See what people think. I wouldn't be surprised. Yup, yup, there we go. Making a little more sense exactly, right? There's this idea that this is true, but some of you might've thought this before this question came up, but if you tuned in just a tad while we were talking throughout this intro, I said we're not gonna use a command line at all. We're gonna go all through that web interface, right? So that's the awesome thing. Think about this when you're trying to talk to your teams. Let's say you have your production team, okay? We love them. They're not developers and that's okay. So GitHub is foreign. It's a foreign tool. It's as foreign to them as Adobe Premiere Pro is to me, okay? They might, your HR people, same situation, right? They might be intimidated to jump into a tool like this because the assumption is that they're gonna be in a terminal using all these command line commands to get any work done and they don't wanna star in the next hacker movie, which they should, because that's a good movie. However, this is a common misconception. So I'm glad that a lot of you seem to have picked up on that or knew that prior. So here's the next one. We're gonna do this for an hour, okay? So get comfy. Placing code on GitHub means my project is open source. Let's see where we land with this one. That's a big one right there because there's a lot of managers if you go to and say, can we put this on GitHub to try to do collaboration? They're real quick if they've been misinformed or if they don't understand or gonna say, wait a minute, anybody in the world can see that. Exactly. And this is just a judging thing for me, not to judge you but to just talk about how this is affected. All right. So this one is a little more split, okay? And this is a very common misconception, right? And there's a reason for it. You'll see when we get to the GitHub webpage, it prides itself on being the home of open source projects. So you see that and it's really easy to immediately think that anything I put on GitHub automatically becomes open source. The actual answer to this is that that's not true at all. Not at all. You can have completely proprietary stuff on GitHub and you can keep it 100% private to your organization. Why does this matter? Well, think of the context we're talking about GitHub in, using it for non-code things like your hiring policies, your job descriptions, right? If let's say your team is hiring and you post the job roles, responsibilities, all that in a file on GitHub that everybody in your organization can see. You've now made it easy for all of your employees to know exactly what the company is looking for and somebody can jump in and say, hey, you said that you want a DevOps engineer, but you're expecting them to have 35 years of Ansible experience, that's impossible. Can let me just edit this and fix this for you to something that's more realistic, right? And these things can happen. And that has nothing to do with open source versus closed source, right? So that's gonna stay 100% proprietary to your company. It's not a code project by any means. And that's a huge misconception that hopefully we can clear up for you. And Matt, if I can just jump in here real quick, that is a major sore point for me working with different companies, particularly HR, the HR departments who've been doing exactly what you said, they put together these descriptions for like a DevOps engineer for AWS. I look at what they've posted and it makes no sense whatsoever. It's not their fault, okay? They're in HR, they're not, they don't particularly care to know about AWS, how long it's been around. So when somebody says, and I've seen this before, somebody said, must have 20 years of AWS experience. So I was like, okay, that's neat. I know of no human being on the planet, including Andy Jazzy, who helped lead the whole thing, who's got that much experience. So when you get into a collaborative environment, and this is why we call this GitHub for everyone, this could be the place where HR puts the wreck out and reaches out to everyone and says, hey, does this make sense? And you can collaborate real-time and really put together a tight document and it's so easy to do. It's actually to the point of, I think, Matt, maybe you can agree or disagree with this, where it's almost to the point of, it was a mistake not to use it. Yeah, well, I would absolutely agree, but I, again, super passionate about GitHub itself. And honestly, that statement of it's a mistake not to use it is not a GitHub-specific statement. It is a version control kind of specific statement. So you should be using something like GitLab, Bitbucket, GitHub. There's others out there. Those are just the major three players in the space. Your teams are gonna benefit exponentially from the ability to collaborate on stuff like that. It's a super easy fix, right? And let's face it, maybe that person that drafted that job requirement for 20 years of AWS experience, maybe they meant to say two and they accidentally bumped a zero on the keyboard. The fact that you had 100 pairs of eyes on it means that you caught that before it went out and it took all of five seconds to fix, which you'll see, it'll be awesome. All right, on to the next one. It is difficult to navigate the GitHub website. Now, if you've never been, if you've never been, we can go with true on this one. If you've never been, we can go with true. Here's the kicker behind this question, it's kind of a gotcha in that the GitHub website, so GitHub, fun fact, GitHub builds GitHub using GitHub. So what I mean by that is all of the source code for GitHub is on GitHub. It's closed source, by the way, at least part of it is. So all of the source code for GitHub is on GitHub, which uses GitHub to then deploy GitHub to its cloud environments, okay? And there are DevOps product, and there's DevOps all throughout GitHub, which does many, many, many, many deploys a day. I'd say on average, probably 50 deploys a day to all sorts of stuff. And that causes this website, the actual web application itself, to change very frequently. One of the best things about being on staff is I got to see all of those changes really early because I had what was called a staff view. So I could see the features come and go, but it also made work really hard sometimes because buttons would move, they would disappear, I would get super cool new features that were useful, and then they'd take them away for some reason, but expect this to be very fluid, exactly, getception. It's gonna be fluid, so if you find it hard today, it might not be hard tomorrow. And if you find it easy today, your time's coming, don't get comfy, your time's coming. All right, we got just a couple more of these, and then this is really gonna help us, and then we'll stop beating this poll horse. GitHub helps project managers view work in progress. I like this question, Matt. I know you do, Brux. I know you do. I like it. I know. Yeah, that's awesome that everybody agrees on this. Now, my follow-up question would be, do we know how? And I bet that's where some really cool mind-blowing stuff is gonna show up. When we talk about how project managers can view this work in progress, because it's much more than just being able to see what changed or what's in the process of changing. Some through insights, we'll take a look at insights, mostly through projects. It's kind of a collection of all of it, right? And if you know where and how to look, using tools like insights, projects, poll requests, issues, the whole thing, you'll see, you'll start to form like this entire map in your head about exactly how fast and how on pace a project is, how behind it is, who is taking on what responsibilities for that project. As a project manager, you'll know who to ping and slack and say, hey, Brooks, I need you to do that review, man. It's been sitting there for two weeks, what's taking you so long? And Brooks is like, I just forgot about it. How about that? And then he goes and he checks it and he takes care of it. And as a project manager, instead of chasing Brooks down for four days, trying to get something done, it was one ping and slack and your job is now easy because Brooks went ahead and took care of that really quickly because he had the right tools. I like the converse argument on that one, do what they called me up and then say, hey, why haven't you done that yet? And I can say, did you not go check GitHub? Exactly. Did you not go check? All right, two more. GitHub is a tool for development teams. It's another check question, isn't it? Exactly. Yes, it is a tool for development teams. It's not a tool limited to development teams though. And that's a huge misconception. This comes every time you look at something on the internet for a course on GitHub or you're in college or whatever, it really seems like this is only for devs, right? Or maybe dev option engineers at this point. And honestly, it's just unfair. I would, when I used to travel, I would use GitHub project boards to build my packing list on what I needed to take with me. And I would just slide the cards over as I packed. So I've used this for all sorts of things. And that's when I say firmly believe in it. It's because I've thought of very creative ways to use the platform and it really helps keep me organized. All right, last one. And then we'll get on to talking about some of these accounts and we'll get back to that catch. Knowing how to write code is necessary to use GitHub. He's a little bit of a trick question, but not much. I can very easily divide the room with how I do it. Now that's gonna say, you did put some tricky ones together, man. This is tricky. Yeah. Well, you know, it's graded, so get it right. And then we'll be fine. Cool. Majority of you say false, which is great. Oh, we switched. Yeah, no, we didn't. Okay, sorry. Which is great, most of you say false. It is not necessary. We have a couple unshers, most likely. I could easily divide the room by saying GitHub has its own language. It's not really a language. It's a markup format for writing awesome documentation. And we're gonna spend some time doing it. And it's gonna, at first you might be like, man, why am I doing this? But once you start using it, you're gonna realize that you can make documentation that is intuitive and has all the cross-linking you could ever want into it and examples and everything really, really quickly. It's, I've used it so much now that I find it really hard to write Word documents or Google Docs documents. I can't use regular Word processors because it takes too long to format them. When, if I use Markdown, it's really, really fast for me. I think I'll go a step beyond that, Matt. I would actually go as far as to say is that I think it's gonna become a required skill. I hope it does. I hope it does too, because at the end of the day, when we're talking about comparing very large documents, again, something like HR where they're setting some sort of legal precedence that's gonna go throughout the organization. And this is a multi-page dense document and somebody wants to make a change to it. Being able to quickly find that change, Markdown set up for it perfectly inside things like GitHub. And so then why am I dealing with this giant document with embedded control characters that I can't even see that when I try to do a diff it's just gonna go nuts. So with that said, Markdown, just everybody, it gives you so much more capability. I don't, let me get off the soapbox on that one. It's a skill you need. We'll touch upon it here. Yeah, we're gonna do some cool stuff with it too. So it might seem a little drab at first, but we're gonna do some really cool things, at least in my opinion. Absolutely. All right, so what is GitHub, right? We've kind of answered this along the way. So I won't beat this horse too much. It is the industry leading tool for source code management, right? And it is becoming, or it's trying to become an industry leader in all things collaboration and project management, right? To include the source code that goes along with that. It really wants to be your entire DevOps one-stop shop. And it's working hard to do that, it has a long way to go. And that's okay, that's our space we constantly iterate, right? GitHub is so important to the world that it is ready for a disaster recovery situation. Fun fact, okay? Wow, that's true. GitHub has more source code on it than any other platform, right? So most of the world's open source projects are on GitHub. So much so that GitHub believes in a disaster scenario they could recover most of the code that is in existence today. They actually purchased, you could look this up. They purchased space in what is called the Arctic Code Vault, right? It's in the Arctic Circle next to the seed bank. We're probably all familiar with the seeds that are stored up there so that we could replant the earth if we needed to. Well, about a year ago they took a snapshot of all of the public repositories on GitHub. So all of the code in the public repositories and they stored that on a drive in the Arctic right now and they updated every now and then but it's stored and ready to go in case of a disaster recovery scenario where we need to restore a bulk of the world's programs. And that's how critical good version control and actually keeping track of this stuff is and that's how widely popular this tool is that there's not much code that we could probably rebuild the world which is mind blowing to me. What's really fun is if you had a GitHub account prior to this, now have a really cool little badge on your GitHub account that says that you're an Arctic Code Vault contributor. So that's super cool. So that's look, that's a little about GitHub, right? We're gonna dig more into it with the Arctic Shows Rapidly Nothing. Should I be concerned that my strawberry seeds will be lost? Beats me, I don't, I mean, the question is are you 20 or are you 70? Right, if you're 70, you don't need, you don't care about those seeds, right? If you're 20, strawberry shortcake might be off the plate later on in the future here. So- Oh my gosh, how did we get on that subject so quick? What strawberry shortcake? How do you not get on that subject? I don't know, man, but we swerved right into it. All right, so that's the GitHub, right? We need to expand this thing to be much more collaborative in our regular work because if we're doing that with source code, like what if we did that with hiring processes? What if we did that with inner team connectivity processes? What if we could recover that in a disaster recovery scenario, right? That's kind of cool. All right, so let's jump into these GitHub accounts. We're gonna kill this PowerPoint at this point. We're gonna talk about GitHub accounts as a whole, okay? Hey, enough of the slides. So if you've ever been to github.com, you're greeted with this super cool screen, changes all the time, right? This is just one of those things they do. They give you some really cool stats and you're prompted to sign up, okay? I already have an account so I'm not gonna go ahead and sign up again. And this is kind of a teaching point. One of the things that comes with GitHub accounts is that you shouldn't have five of them, right? Ideally, you use the same GitHub account for your personal projects as you do for your work projects. GitHub is like built for that. There are plenty of checks and balances in place that ensure that I can't accidentally merge the two where they can't see each other or whatever it might be. There's no harm in using the same account for those things. As a matter of fact, like you can be a part of many groups with the same account. But if we look at some of the pricing, right? This is the gotcha going back to that question. Look at this for, ah, compare features, right? For an individual account, just a user, a regular you and me, it's free, zero dollars. What do you get? Well, unlimited public storage, which is great. Public means Brooks and I can collaborate with you. Public means somebody across the world can collaborate with you. Maybe the DevOps engineers that you were talking to in Discord want to help you with your Kubernetes manifest. So you send them a link to your public repository. And guess what? They help you. But what if it's work related? Or what if I have a super secret Tony Stark project that I'm working on, go Ironman? Well, I can also have private repositories, which means only me or who I allow can see these things. And all of this is free, but this is where the gotcha comes. Look at this, no access to code spaces, right? So what code spaces is, I'll show you, it's an online editor, a text editor. You don't need it at all. It's not something you need in order to use GitHub. It also, there's a reason why it's not on free accounts. It doesn't really benefit the individual user. It really benefits the team or the organization or the enterprise. The reason for that is your developers or whoever's working on your stuff would never need to put a local copy on their machine. They could do all of their work on GitHub without ever having a local file on their machine. If you're just you, that's totally fine, right? You're not running away with company secrets unless it's your company, right? So that's one of the advantages and that's why it's not included. This stuff, this actions minutes. Hey, look, you get a little bit less. This is the catch, this is the gotcha. The free account gets 2,000 minutes. The enterprise gets a whole lot more. But look at this. I don't know how well we can see that, so I'll zoom in. Free to public, free for public repos. How about that? Free for public, right? Because GitHub does focus on open source in collaboration, the more stuff you do publicly, the more features you get. That's the catch for free. You're gonna get more stuff to do it publicly. Same thing with packages. You want to store Docker images on GitHub? What? Might not even know you could do that, but you can, right? You want to store Docker images on GitHub or NPM packages or some of the other artifacts that you're building? That's great. You get 500 megabytes of storage for free in private repositories. Public, unlimited, it's free. It's great. Yeah. Can you take a second real quick here, Patrick has a question and just briefly, because I know we're gonna talk more about later, what exactly is actions? What does that do for us? Actions is an automation tool set that's built into repositories and they execute over time on virtual machines. So when it says actions minutes, it genuinely means that let's make this, hopefully bring it back to something we all maybe understand a little differently is, let's think of an AWS EC2 instance, a virtual machine in the cloud, right? We turn on that virtual machine and we start paying for it by the minute, right? For every minute the virtual machine is on, we get a little bit of charge. GitHub actions is the same thing. For every minute, what's called a workflow, which we'll dive into, for every minute that workflow runs, it's accumulating those minutes. So if you hit more than 2000 minutes, you won't be able to trigger another workflow for that repository. What's crazy is this is a repository basis, okay? So like, let's say you had one private repository. Well, you get 2000 of these action minutes before you have to pay for them. There's the catch, right? Like you could buy more minutes. You could also just create a second private repository and get 2000 more minutes or a third private repository and now you have 6,000 minutes. And if you're slick, you can kind of link all those things together and have unlimited private repository minutes if you did some finangling. And I say that, and I don't know if it's against the terms of service, I haven't dug into it that much. I do know that I've done that for like a lot of proof of concept things for GitHub themselves and nobody's ever like scolded me for that. So unlimited though for public. So this is just quite literally how long your automation process takes. And to kind of put a button on it for you, Patrick, when we're talking and for everyone who's watching about what actions is, one of the things I've used Actions Forged personally is I like to use a framework called Pulumi to create AWS architecture. And basically you write it in Python. And then what I can do is I can push that code up to GitHub and then via GitHub actions, that is the compute time. That actually reads my code. It will create my architecture for me in AWS. And there's a lot of examples of things like that, for, you know, particularly with containerization, deploying containers, the time that it takes for their servers to kind of crunch what you've done and put it out there, those are those minutes that Matt was just showing us. And I think it kind of, I mean, for me personally, Matt, it's one of those moments where I cut my jaw drops a little bit more, because I realized that was free. I did that at no cost. What's so flipping ever? If you went to go hook up Azure Pipelines, you're paying for that. Oh my gosh, AWS y'all? You better buckle up. It's so nuts that it's free as long as you're willing to be public. Like that's like, okay, how many of us have learning experiences when we're trying to figure these things out? Like just set that stuff up for free in a public repository. It doesn't look bad on you if you learn something, right? Like that's why you're here. Like you're not ashamed to be in this bootcamp maybe because you're hanging out with Brooks, but for the most part like you're here so you embrace learning. So why not make that public and get it done for free? And it's not free like Google offers you. Here's $300 in credit. No, it's just free. Like I can't unfree it, it's that free. Well, not to mention this whole thing that you and I have talked about so much when we talk about this engineering stuff that we're working towards. It's the idea that when you're sitting in anything including our videos where we're teaching you something use GitHub, create yourself a little repo based on what you're learning and put your notes in there because of two reasons. One, obviously it's gonna be your notes but two, when you get to that job where you need to remember, wait a minute, Matt, tell me how to do that in GitHub. You can just go to your GitHub repo and look at your notes right there. And this is again why I'm talking about markdown is such a big deal because GitHub will render your markdown very beautifully. So you've always got that stuff available and as bonus points, when you go into that job interview and back me up on this one, Matt when you go into that job interview like we were talking about Kubernetes and they say to you, how would you do that? Nothing, I'm gonna pound the desk nothing will win the day like you're going, well, actually, if you want to let's take a look at my GitHub repo I've actually got some code like that. You've just won the interview. Exactly. And then when you start, you might run into a problem you're like, man, didn't Brooks teach me how to do that with a script in that course? Like you have that script. Just take it to work with you, right? It's a toolbox. So again, what's the catch? Let's go back to that. We'll circle back to that. Well, if it's public, that means everybody can see it. That's the catch. What does GitHub get from this? More code to put into the Arctic Code Vault. There's also this thing that we're not gonna dive too much into detail. It's called GitHub co-pilot. It's a programming bot that you can tie in to like Visual Studio Code and it uses AI to suggest code snippets for you, right? You can actually write a whole lot of code without ever writing code. The data in the code used to train co-pilot comes from public repositories. So what does GitHub get from that? They get to make their stuff better because they can analyze the things that are taking place in the community, right? So that's the catch. GitHub gets to use your public stuff to make GitHub better for your public stuff. It's like that's the catch. So the other catch is there's tiers, right? You see zero, 40 to 10, this isn't exactly accurate. And again, this changes all the time so we're not gonna harp on the price. But what you do need to know is that this is for free, but what if I want some of these things to exist? Let's see if I can find one. Like what if I wanted required reviews on a private repository and I'm an individual user? I can sign up for something called GitHub Pro and it's not listed here, but it does exist, I promise. If for a whopping $4 a month, so what a third, maybe a quarter of the cost of Netflix at this point, you can enable a lot of these features in an unlimited fashion for your private repositories, okay? So like that's what you get out of the upgrade is all the stuff you can do in public repositories, like you get in the private ones. You're also not gonna get support, but that's okay. You're not gonna need it. That support is for like the enterprise servers and stuff like that. It's not for .com. So GitHub has like a lot of different things like product skews, right? So there's .com, which we all use, but there's also enterprise server, which if you're an enterprise admin, maybe you care about, but for this bootcamp, we're not gonna dig into the enterprise side all that much. So then there's team, which is also called organization. They go back and forth between these terms. It looks like it's team today. This is where you want to have like a core group of people you wanna work with. So I'll give you an example. I have a small group of people that I typically work on projects with. We try to launch startup ideas on a regular basis and we use a team or an organization to do that. So all the repositories for our stuff exist inside of this team realm. And then I use my individual account to interact with the team, okay? And I'll show you what that looks like once I log in. I'll show you an organization that I'm a part of and I'll show you how we can all see that stuff. And I might even, I don't know if I can create another one. The limit is if you don't wanna pay for organizations, so here's the other thing. It says team is 40 bucks, but it's not. Like it is, but it isn't. Like you can create a free organization that kind of inherits all this free stuff that we have, oh, sorry, from this column of free stuff here, it kind of inherits that. But as a team, if you want to upgrade your team to do more intense private kind of collaboration then you can do that for a fee. There is no such thing as a free tier on the enterprise, okay? That's the catch is there's these free tiers that are offered that offer you pretty much all of the functionality on public repositories. There is a small fee for the quote unquote pro versions of those account types that give you the access to the advanced stuff on private repositories. And then there's this outlier that's enterprise, which that's probably a decision that's a little higher up on the chain than us. But that allows you to run GitHub on-prem, right? So you're in that situation, maybe you're working with a DOD, finance health, something highly regulatory that says, we can't use a cloud product, well, we can get you GitHub on-premise, you just need enterprise to do it. So we're not gonna harp on that, but that's a huge thing about the account differences in the account types. So I'm gonna log in really quick to my account for you guys. And look, this is my username and I'm perfectly okay with you having that. It doesn't hurt me, it's public. You guys should absolutely go look at some of the repositories that I have, excuse me, I have to authenticate, which we're gonna talk about, which is why I'm logging in. So I'm gonna use my two-factor authentication code. If you steal this, it's okay, it's about to expire in a whopping 10 seconds. And here we go. Okay, so same screen, but if I come over to my profile, you can see I have a user account. It's no different than what you would have when you first sign up. This is the Arctic Code Vault contributor stuff, which is really cool. But at quick glance, so this is the individual user account, right? This is a personal account, not an organization account. Let me ask you about that, Matt, real quick, because I think this is interesting. This is your personal account. Yeah, absolutely. This is the exact same account that you use to interact with me all the time inside the INE space or anything else that we're working on, correct? Absolutely, and yep, and I'll show you exactly that. So that's a great question, actually. I only have this account. This is my only GitHub account, period. I use this for learning, I use this for work, I use this for personal projects. I use this for notes. I genuinely use this for everything. Well, the reason I ask is, and I think it's probably been about two years ago, I worked with an organization up in the Boston area. They actually had separate logins. When you came to work, they had their work-based GitHub account. And I remember looking at that thinking, I think that's a bit inefficient. I think that may not need to be the case. It is 100% in contradiction with what GitHub recommends as the best practice. The best practice recommended by GitHub is you just use one account. It's easier for them to gather the right metrics to help the community if you're doing that. It makes it easier on you. You don't have to manage different logins. Like I just had the two factor my way in. That's one security feature. There's like, what if I had access tokens, another security feature, which we're gonna dive into in a second, for all these different accounts, and I forgot to roll my tokens or whatever it might be. It's just better for me and better for GitHub if I have that one account. It's also better for your organization because like INE, for example, has an organization in GitHub. They didn't create me a brand new INE GitHub account. They said, what is your GitHub handle? And we invited me into the organization as me, okay? So what's really cool about this at first glance, right? Public, first and foremost, 143 repositories. Now, if you think that I have 143 software development projects that I've worked on and deployed, you'd be sorely mistaken, okay? Public, public, public, public, wait a minute, we see a theme. The guy with 143 repositories that spends some time at GitHub as an employee has a lot of public repositories, okay? But it's not limited to that. If I'm sure, if we look through here, look, private, private, private template, right? These are different repository types which we're gonna jump into so don't get hung up on that right now. Don't try to steal my Harry Potter voice react app either. So there's that. I'm kidding, you can't steal it, I don't think. If it's public, it's open source. And you can get it. Yeah, and it's not even a remotely complete project. I was teaching somebody how to do some react stuff. So again, collaboration, right? I do a lot of mentoring with people that are like going through like web development boot camps and oftentimes I will create a repository and we will collaborate in my repository, hence the Harry Potter react voice app thingy. So this is my profile. It's just like anything else, anything else social. Like I can have followers so people can follow the work that I do. I can follow other people. I can have like these are Docker images. This is an MPM package, whatever it might be. I can have all these things and they're all associated with me to a degree. If I come down here though, we see organizations and if we go and we click on this one, this is an organization that myself and these other people are part of, okay? So this is an organization account and we can see that this is private and this is private and this is private and this is public or whatever it might be. And this is at the organization level. This is where we can do fancy things like manage teams, right? So I can create a new team. If I wanted to, I could come in here and I give it its name, its visibility. I can create secret teams. I can't do these things as an individual. It doesn't make sense for me to create a secret team in my name space. So that's the big difference between organizations and users is you get like this name space where you can do people management, right? So I can say, hey, like here are all the people in this, right? And what their permissions are and who and what they can see, okay? So we're gonna pop out of here and we'll go back to my personal account so now we're back to the personal account and you'll see I don't have the ability to manage people. Just don't because I don't need to. This is my individual account. So if we look at I and E, I hope we can look at I and E. I think we can look at I and E. We just won't click into anything. We can see, here's this. We can typically see who's a part of it, right? We see there's 18 different teams and that's because I and E is an organization account and it also contains stuff like this. If you were to go to the URL github.com forward slash internet work expert, you would land on like a public splash page that you probably wouldn't even see that this exists. You would never know that this repository is real because it's listed as private. Same thing with my individual user account. If you go to github.com forward slash Matt Davis 0351 I'll even copy this for you and I'll put it in chat just in case anybody wants to. You're not gonna see any of the private repositories I have and why is that? Well, it's because that's one of the security features is I can decide the visibility both at the organization level and at the user level. I give more control at the organization level. I can set up when I create my teams, I can say, Hey, Brooks is just a member or he's an admin or he's an owner or he's a maintainer and all of these give different levels of rewrite permissions, okay? So if you wanna go there, you can. Another quick thing on your profile is you get this really cool contribution graph. I think it's safe to say I use github just a little bit. There's been a lot of contributions in the last year in 2022 already. I think it might go for the whole year, but whatever. And I can see where those contributions are going, what they're coming from. I can even scroll down and see my contribution history, okay? So let's pause for two seconds and think about this from that project manager point of view. I need to know if Brooks has been working on something or what can I do? I can just go look at his profile. I can scroll down and I can see, oh, Brooks created four repositories, Matt created four repositories, right? Oh, look, there's open pull requests. Not only did this person open three of them in two different repositories, I can quickly see their status. Two of them have been merged, one of them is currently open. What's a pull request? You gotta wait a little later for that. Yep, but immediately on just me, I have very quick, like a 30,000 foot view on what my activity looks like. There's something missing here though that we're gonna work on, it's gonna be kind of cool. Let me jump in here with a question real quick, Matt. Go ahead, Matt, I'd love you. Before we go to break. So if I create a GitHub account and I create a public repo, boom, it's out there for everybody to see. What about if a situation comes up? Well, let's say I want to show off, let's say I've been working on my skills with Rust. And so I want to show off some Rust code. Can I take a private repo and move it to public? Okay, everybody, welcome back. Before we get started, I actually want to ask everybody a question. We don't have this ready as a poll question. It's just something I'm interested in to see if anybody's noticing this. So over in the chat window, if you want to answer yes, no, true, false, one, zero, don't care how you want to do it. I've got a question. Has anybody caught because I didn't know Matt was gonna do this for us? Honestly, I did not know he was gonna do this. Has anybody caught onto the fact that he's been giving us inside info? And I'm not talking about things that you can't find out. It's just things that are hard to find out about GitHub. I'm just curious if anybody else has noticed that that's going on. Because to be honest with you, I didn't catch it until just a moment ago. I was like, oh, he's telling us inside stuff. Yeah. Giving you all the secrets. Yeah, I know, right? Didn't notice. Patrick didn't notice. I didn't either. Exactly. Oh, okay. Oh, Brian. Outstanding. Remember what I said when I started that this is my VM. My personal computers went like, so I only use this VM to teach. Like when I use things regularly, I am in dark mode. Hands down. No excuse. No excuse. I think it shows better on video. We'll play, Brian. I don't like the way it looks. What's really cool is you mentioned dark mode, but I had dark mode on GitHub before it was cool. Oh. I had that staff hookup, right? So I've used like five different, five different dark mode versions for GitHub. Matt doing wheelies in the parking lot. Making us look bad. Yup. So cool. Yeah, I just want to make sure everybody was aware of that. There are things that Matt's teaching us about GitHub, things that he's taught me as well, that it's out there in the documentation. You can find it, but it's just gonna be hard for you to do. So you're getting a little bit of insight, although public info about how we can use GitHub really, really effectively. You might be able to quickly see, I get like feature preview still. Let's see if they quickly have dark mode enabled. See, there's just too many. There's just too many. You want dimmed, you want default. See default's kind of harsh, right? It's like really black. We'll switch it to dimmed. Ah, Dracula. There we go. All right, let me come back to my profile. All right, awesome. I don't think that shows better, but we'll take your word for it. All right, so let's talk about security around the user account. And then we'll talk about security in organizations, okay? So before we move forward on that though, take the time if you didn't do it during the break and create a GitHub account. Just go create a free individual user account. We're about to get into some interactive stuff that you're just gonna get so much more out of this if you have an account ready to go. Like if you don't have two-factor authentication enabled, I'm about to show you that. If you don't have scoped personal access tokens, I'm about to show you that. And these are things that you can apply right here, right now to your GitHub account. Hold on, Matt. We have reached a teachable moment that I have to slam on the brakes and ask you about. Now, this is what it is. Everybody, please pay attention to this one. This is something. One of the discussions you and I had very early about GitHub was talking about sort of the professionalism of what your account looked like. I was really concerned about the idea that I could have some goofball account over here. And I didn't really wanna show it because it's got like, I used a goofy icon for myself. I didn't use like a personal picture or anything like that. Or I didn't use my name. I used something like just whatever I made up. Talk to me, and this is really insider stuff here. Culturally, when we're talking about GitHub, does that even matter? It matters in the sense that you shouldn't think about it. You, like when we had that conversation, you had overthought that. So for example, if we're looking at my profile quickly, this is my name, right? Like in that form of like setting up your profile, like this, I could change this to Bobby Boverson. I'm probably actually gonna change it to my crypto domain name is probably what I'll change it to. However, this is what's called my handle. And it is highly encouraged that you be a little bit creative and a little bit goofy with your handle. For example, I tried to get the handle MD, but like EMDE when I got hired at GitHub. Because everybody is referred to as their handle and MD sounded cool and it would look a little cool. It could have just been a goofy little thing. A lot of the people I knew have fun handles like Hector Sector. That's a handle of somebody I know that very professional still, Beard of EDU. This guy, big, bushy beard and he runs around doing enterprise level enablement. So Beard of EDU. And you just kind of get known is these handles. So you don't have to be super clean and proper with it. Like I went and I had to throw some numbers on there that are sentimental to me, but they just does a lot of Matt Davis is in the world. I'm not very unique in that sense. But I had to do that to get something unique. And then hindsight, if I could do it all over again, I would have a much cooler GitHub handle. Same here. Than what I have. The other thing is like, you're gonna find in the documentation and all over the place with GitHub, emojis exist everywhere, right? And it's just this culture that exists for this tool that says loosen up a little bit. Have a little fun. As long as you don't have something obscene or offensive as a handle, you're good to go. And honestly, if you have something really stuck up like mine, like you probably look down on a little bit. I know very few people that within GitHub specifically that use anything related to their name. I know an Admiral Ackbar who clearly is not Admiral Ackbar. That's his handle. Like you're gonna find a ton of really awesome stuff out there. So as they're creating these accounts, if they're really fretting about something like that, it's not that big a deal, I think is what we could say to them. Make it cool. Make it slick. Don't worry about, oh, I've got to really button this up and make it look exactly a certain way. That's not how this culturally in tech, in the cyber world, this is actually viewed. This is a little bit looser, a little more creative. So yeah, don't worry about that. If you're creating your account as part of this bootcamp or if you're in the future watching this as a recording and you're creating one, don't sweat that. Create something cool. And here's the thing is you can change this later too. But the more organizations you become a part of and like let's say it's a work related account and it's all like federated login and everything, that change could cause a lot of problems. But if it's just you on an individual user account like I am right now and I'm not, in some single sign-on situation with work or anything like that, I could change my username right now and I'd be fine. The problem is now everybody knows me as this. And like I don't want to change it. Hey, Benjamin's got a question for you Matt. Bad in your handle. Notice some problem using actions, pushing something to Docker, using the handle. The Docker does not allow uppercase letters. Yeah, so that's a Docker problem, right? It's not a GitHub problem. There's a lot of weird little stuff like that that you have to consider. What you could do, and this is a little off topic but I'll give you a quick way to do this. In that workflow file that you have for actions, leverage the GitHub actor environment variable to get your username, turn it into lowercase and then send that over to Docker. That's the actual fix for that. We're not gonna dive much deeper in it than that, but you could force lowercase so that Docker does things the way it's supposed to. The other thing is, is it doesn't matter. I don't think like when you type it into the URL, I don't think it matters if it's uppercase, lowercase. But what does matter is spaces. What you'll notice in all of my repository names, there's dashes where there's spaces and they're all lowercase. This is not a requirement. This is just experience bubbling to the surface and me having countless problems mixing case and not including dashes for spaces because plot twist, GitHub adds the dash anyway. So every time I need a space, I use a dash when it comes to naming branches, everything. And I always just do stuff lowercase. There's no like best practice for that. That is just, I've been beaten up by not doing it. So that's how I do it. So that's the quick fix to your problem. And then there's the potential fix is just trust everything in lowercase and question everything with next case. Exactly, exactly. Okay, so if you have an account, then all this will make sense. When you go to github.com forward slash your username, okay, you're gonna see this little profile icon on the top, right? If we click on that, we get all of this stuff. My profile, my repositories, my code spaces, my organizations, my enterprises, you'll see that I kind of fit in all of these, my projects, my discussions. Discussions is new, we'll get to that. My stars, my gist, these are all just different features and the most important piece is the settings, okay? In the settings, we can come down here to this whole access side of things, right? We can look at our password and our authentication. So if I want to change my password, I can hear and right here is what is important, right? I can enable two-factor authentication. Now, there are lots of two-factor authways. The way I signed in earlier was with the Microsoft Authenticator app. Why Microsoft? Well, that's with Microsoft owns github, there's your answer. Am I limited to that? No, that's just the app that I used. You can find the supported authenticator apps in the documentation for github. I can tell you right now, the Microsoft one works, it's easy. The second way is using something like a UB key or you Mac people with the touch bar. That little fingerprint reader also works as your two-factor to get in if you enable it. It's really slick, kind of cool. I don't know if the new Macs with their Apple chips like have any impact on that, but I know the old ones, I used to always use my security key. The security key that's configured is not a UB key, but this is where I would configure that UB key. You can also use the github app on your phone. It's another guest suggested way to log in to github and you can have them text you, right? So as you can see, I have a couple of different two-factor things enabled. And this is simply because if the authenticator app breaks, I can still get in through the mobile app. Or if I'm not on my Mac and I can't use the touch bar because I'm on a Windows machine, I can use the authenticator app to get in, right? Because I work in a lot of different environments, I have multiple two-factor authentication methods set up. These are really easy. This isn't configured. All I do is hit edit. You're about to change this, right? You get all of this stuff. I say set up using this, it will send you my authentication code. I hit continue. I go through these steps and I'm good to go. Now for me, I don't feel like doing the SMS one. I have enough, okay? But pick one, right now would be great. You could use the SMS one if you want, set up your two-factor. It takes two seconds, right? You also have these recovery codes. When you set up two-factor, you're gonna be given a set of recovery codes. Treat them like a secret, keep them safe. You can roll new recovery codes, but this is just helpful if for some reason you don't have access to any of your two-factor authentication methods, you can enter your recovery codes and get into your account, okay? So that is the huge thing. The other thing is like, maybe you're curious, uh-oh. Dang it, y'all know where I am. How about that? You can see what sessions are logged in and what devices, yes, I'm in freezing Las Vegas, Nevada at the moment. That's very cold today, all right? So that was obvious. If I have SSH keys and stuff, like they're here, but you'll notice I don't. I don't have any SSH or GPG keys. I don't have any of this set up, but I don't actually authenticate with a password. Time out. You saw me use a password earlier, Matt, you're a liar, you're right, I am. On the website, I need to put in my password and then I'm prompted for two-factor. When I use automated tooling like GitHub Actions or Git from the terminal, I don't use a password at all. I use an access token, okay? So that is the next piece that I think is really important to set up. That exists under the developer settings. Such a strange place for it to be. It isn't, it isn't, right? Because it's typically for application or programmatic access, but it's still, I would like to see it with the other. Yeah, yeah, just give me something there, it says create this, because for those of you who ever want to start using this from the command line, the first time you try to do it and it says, give me your username and password, you're very quickly gonna get a message that says, we're not using passwords anymore. You need a personal access token. And that's the thing that Matt's showing us right here. Yes, yeah, if you try to use this from the terminal, you will absolutely get that message. So when you come to dev settings, you're gonna end up with three choices, GitHub apps. Like these are applications that you can write that act on your behalf and they interact with the GitHub API, okay? This is not the token that you're gonna paste in at that message. But if we look at what one of these might look like, is you can come in here and this is where you get like your client secrets, your information about the app, like where it's hosted, any type of callback URLs. If you're a developer, all of this stuff kind of make, a web developer specifically, all of this kind of makes sense to you. But if you're not, what you might care about is this, this permissions and events situation. If you're not a developer that doesn't mean you cannot use GitHub apps. GitHub apps are everywhere and they're really helpful. Some of them do things like add badges to pull requests. What's a pull request? We'll get there. But they add badges to it. Some of them interact with JIRA. They might like have a JIRA integration to help move your JIRA issues around based on what happens in GitHub. These are apps and they need specific permissions to do this. And this is where you can come in to deny or accept the different permissions for the application. There's some default permissions those apps need. Developers are gonna say, hey, I need these permissions. They actually build that into a small schema in the app that's outside of the scope. It's there. The second major piece to this is OAuth apps. And these are things that you build that do some OAuth stuff. I don't have anything of like super awesome example in here, but they're very similar to GitHub apps. The only difference is they authenticate a user through OAuth. Kind of simple. So I can get information about my user account. Again, if you're a developer, that makes sense to you. If you're not, it's okay that it doesn't. I just want you to be aware that this exists. This is the one that you should be aware of regardless of who you are. Okay. So these are your personal access tokens. When you tried to do something using Git or if you're trying to do something with GitHub actions, you might be prompted to enter a token. You might see something that says token authentication is required. In the event that you see that, this is what it's talking about. And it basically gives you a token that you can set to have an expiration date. You see this one doesn't expire. Bad. Make sure your tokens expire. This one does expire, okay? When it expires, I need to come in and create a new one. This is the one I'm using today. There's a reason why it expires because you guys are seeing stuff on my account and like whatever, it's part of this VM that I just recycle all the time. And you'll see if you're on an old version of a token, like this one is, you can regenerate it to take advantage of the new token format. This is another thing that changes in GitHub all the time. They're constantly beefing up the security of their personal access tokens, okay? So to create one of these, it's really simple. You create it. You hit generate a new one. You give it a note for boot camp, not boot camp, boot camp. I can set the expiration and then I can scope all of these permissions. And if you want to know more about the details of those is a link right here. But basically, if I just want to be able to use this token to manage stuff in a repository, I can do this. If I never need to use packages, I just don't use packages. If I'm not talking about an org, I don't check org, right? And we talked about what an org was to a small degree. We're gonna get into organization security in a second, right? We might, if I don't want to ever be able to accidentally remove a repo with this token, I don't check this. So all of these permissions get built in. It's not just a password. And then I hit generate and now I have this token. If you go ahead and you log in and use it, you can read and write to my repos. You can't actually delete anything, right? I just limited the scope on this thing. You're only ever gonna see this once and then it goes away. I hope you had it. Guess what? It doesn't work anymore, okay? Try to use it now, it's gone. So that's how you can revoke tokens. How easy was that? I revoked it right here in front of you. So basically the idea I'm at is, this token that we're talking about, it's just a little text string. It's something we're just gonna paste in when it's re-asked for. We can delete them quickly. We can put, and most of all, we can put limits on them. Would you ever recommend somebody like turning on all those check boxes? Yeah, like this one. Would I recommend it? No. Is there a use case for it? Yes. If I'm doing something like developing specific GitHub integrations where I don't know the exact scope of the permissions I'm gonna need, oftentimes I will over-privilege first. This is just my way of doing it and getting adopted. I will over-privilege first and then trim privileges as you go. You could under-privilege first and add them, but some of the debugging is a little bit cryptic if you do it that way. So because I understand the debugging messages for these things in a specific way, I like to over-privilege and then scope backwards. But you'll see like this one, I haven't used it in six months. So like, that's another cool thing. Your security people might need to know. And from the organization point of view, like you could audit this. This one I used just this last week. I used it today, plot twist, right? This one I used in the last three weeks. This is kind of a bad indicator because I used it much sooner than that. I think I used it in the last week to be honest with you. So since this one hasn't been used in six months and this takes two seconds to roll a new one, I'm just gonna go ahead and delete this one too. So as there's actually starting to use GitHub, if when they start running into like problems, it's not working, I have found that like the thing that's always gotten me, man, once I set up the Pat wrong, okay? I'd set up my personal access token. I'm just getting some sort of problem there. And like everybody, I hope everybody saw just how easy that was to do. You generate new token, give it a name, set an expiration on it. Don't let it go forever, okay? In fact, the principle you should always have in mind is least privilege. Like give that token just the privileges it needs. So as you're learning GitHub, if you're finding you're getting permission errors, well, maybe you need to regenerate a new token with a few more permissions and then start using that. But you can find your way to that least, our least permissive token that applies for that particular situation. You can get that. Exactly, and that can be like role-based for like if you're HR, then you don't need packages permissions, right? But if you're a developer, you probably need packages. So once tokens are created, if you just click on them, you can edit them. You can never see that string again. Like the actual string is gone forever. I'll never see it again after that page. But what I can do is I can rename this. Whoa, this one's over scoped. Why is that? Because it's a developer token for me. But you know what I never use on GitHub? I just don't. So I'll come in here and I'll do that. And I could regenerate it to set an expiration date. You can't edit the expiration date, but I can update the token as quick as that. And you'll notice it doesn't show it to me again. Right, now that token has changed its permissions. So your users don't have to roll a new token just because you need them to change their permissions or you want to change the permissions. You just go change them and they work real time. And that's going to change as soon as we do it, right? So we make the change, we rerun the command that was failing because of security, boom, fixed. Yep. Very cool. So that is from the user account point of view. Organizations in depth, we're going to show you how to add some people to those organizations. And we are also going to take a look at some of the additional security features for organizations that take place, okay? So let's go ahead and jump over and do that. What's really fun is now it's going to start getting interactive. If you follow along with this and you create an organization, which costs how much money again? What was that price again? I couldn't remember. 190 free, something like that. Something like that, yeah. Yeah. So if you create an organization, which I encourage you to do, feel free to post your GitHub handles right in the chat and invite each other and follow along with some of the stuff we're doing. Absolutely. Get a feel for it. When we move forward and stuff and you see the repos that we're going to be using, feel free to interact with us too. It'll be super sweet if you do that. So don't hesitate. I'm going to come back over to an org that is pretty empty, but one that I own personally. So we're not going to work in a work org of any kind. We'll go to this one. Okay. Doesn't have any public repositories yet. So if you tried to go to this, this site's not up, so don't even bother trying to go there. We were working on some educational content. This is all just empty. None of this has anything. There are no commits. The whole point is that it's super empty. And I think I'm the only people. Yeah. I'm the only people. So organizations like user accounts. Have repositories as we could expect. They have packages just like a user account did, but then they get these cool things, people and teams. And their settings are a little different. Okay. So in their settings, we can jump down to the security section and we get some other awesome things, which we'll jump to in a second, but the first one we're going to talk about is authentication. If you're a part of this, this org, I can force you to have to two factor in, right? So if I'm managing an organization, I can ensure that everybody that's a part of it has to two factor in. I can also set up a loud list to figure out what IP addresses are allowed into this organization. Now this isn't super in depth, but when we start layering that with things like member privileges, right? The base membership of everybody that can see this org and the people that are a part of it only have read permissions. You can limit the types of repositories that can be created. Right. You can decide what forks and who can use pages and there is a plethora of options in here for you to craft. That very specific use case for you and your teams and how they interact with this. So. Is there a risk? And the answer is there's always a risk, but there are a lot of built in features that you can use to mitigate and scope everything you need from that organization level. And that is the moment. When you realize you need to use an org. When do I use a personal account? When do I use an organization? If it's me. And I'm accepting outside people's contributions. That's my personal account. If I'm forming a team and I need to have administrators in that team, or I need to have in groups of instructors or groups of people that I'm using an organization. And it's very easy to create an organization. I think you just come into these setting, maybe your orgs. It's been a while. Yeah. And you click new organization. And it will take you through this process of setting up an account, just like an account for an org. Okay. That's that. I'm not going to create a new one because we're already here. So what's, what's, what's again, Matt? What's, what is that point at which, what is that thing I'm looking for? What is that thought that goes through my head? What is that requirement that I have that says, I need a new organization. What is that? And like in a pithy, like, what are the things, what is the thing I'm looking for? I use organizations to bundle tasks. So let's say I cloud college, for example, this was a some, some offline in person meet space mentoring that we were going to be doing me in a handful of friends of mine. We're going to set this up and so we created an organization and we never ended up pushing it farther because we got sidetracked on something else, but I needed collaboration with them. I needed them to be able to see more than one repo associated with this bigger idea. So if we scope this bigger idea even bigger and we did something like this, github.com slash github. This is the github organization. Right. So this is everything that is about github. You can see there's 400 repositories. There's all of these people. There's these projects, whatever. This is what they show publicly. These numbers aren't accurate. There's tons of private stuff. Right. And you get this whole read me on what they are and you'll see what they are. So github.com. Going back to our emoji discussion. It's fun. It's playful. It's, this is marked down. Right. And I did this really easily. So github is the idea. Right. It's, it's the product that, that is going out there. Now, if we look at the repositories, there's not 406 github. You know, code bases. You know, you know, you can't drive the idea of github. Or there's some projects that github has worked on, like providing COVID-19 stats to the world health organization. I got to work around with them on that. That was pretty cool. Wow. That's cool. Right. So. From our perspective of I and E, like, I and E is the idea. It's the name of the business. It's the idea. I mean, I know we're in a lot of different spaces, but we need teams and people to work towards that idea with us. So that is the, the, the D mark for me. Okay. A personal project or is this an idea that. He's going to benefit from a team that is a standalone idea. If it's, Hey, I would like to build a course on. Ethereum. I'm not going to create a new org. I might put it in cloud college. I got you. So if it's like a civic project or something like that, we're going to work with part of your community to do something. We're going to build out something that could help say you're, you know, your local area. That sounds like an org type situation right there. Correct? Yes. And it's because there's limitations on personal repositories. So if I go to a personal repository and I pick this one, that's private. This is another one of those gotchas for like, why use a free account? Well. I don't have a people tab. Mm hmm. I don't have a teams tab. That doesn't mean that I can't. Have collaborators. Mm hmm. But the amount of collaborators I have are much, it's much smaller. Right. I think I have like six or something like that. So maybe. If I have six people and we're working on one, like one off project, we won't create an order for that. But if it's a much bigger deal. And we need more than six people in a private repo that, and I need them to be teams because here's the other thing is I'm just going to add people. For example, if I add. If I look for Brooks and I add this. I can only like put you here. Like you're just a collaborator. You're not grouped as an instructor or you're not grouped as a developer or you're not grouped as a project manager. You're just a collaborator. Whereas if we come back over to the organization side of things. Let me do that. We come back here. And I go to people. I now have different kind of tiers of people. I have members. I have outside collaborators. I have invitations. I can see who I failed to invite. I can see these seats. And I don't think this is a pro account. Or whatever it is. Yeah. So team plan charges you a little bit. This is a free org. So like keep that in mind as we show you this stuff. Like this is what you're getting for free. So I can add people to this. No problem. Now I'm not inviting a collaborator. I'm inviting a member. And it's the same thing. I grab Brooks. I can hit invite. And now I can say, well, is Brooks just a member? Or is he a decider? Is he somebody that can have full administrative rights of this project? There's another demarcation point for you. Do you need more than one person to manage what the heck's going on with this project? If so. Maybe I add him as an owner. So we don't trust Brooks. So we're going to add him as a member. We're going to hit send invite. And now he gets this member tag. All right. To this token, I can come in here and do the same thing with teams. I can create a new team and say, Hey, like this is going to be a team of devs. Um, description, build stuff. And I can say. Other members. So other people in the org can find this team or I can have a secret team. Right. So like maybe we have a super secret ninja team that talks junk about Brooks behind his back. And we want to have that team hidden. We can't do that. No, not. No, keep it visible. It's too much fun. That way I can, I can collaborate with the haters. Dang it. Guess what? We'll make it secret anyway. And he'll never know. Right. Or you can make it visible. And Brooks would find out that we're talking about him. Oh, see. You'll be careful with that. I mean, that is the thing right there. The thing where you accidentally not thinking it through, make it visible when you should. And, you know, Matt and I are having fun here, but this could seriously be something where you've come up with a great idea. Like something really, really cool. And you set the Dern visibility wrong. So as you're worried, I know a lot of you are just setting your accounts up for the first time. And so, by the way, hey, Matt, thanks for popping in your share in there for us. That is something you've got to think about y'all when you're doing this again, think make security job zero. And it means not only protecting access, but protecting the data itself. How sensitive is it? I hate to use the word classified because it makes it sound like something from the Department of Defense. But if you've come up with the next great idea, that's some pretty sensitive data. And you're going to want to make sure you've got that thing set to secret. So don't just rush through, think it through. And you can really leverage a lot of these capabilities here to create safe, controlled secret projects. Exactly. So we're going to go with visible. We hit create team. And now if I want to add, I can start a discussion here. First step to collaboration. I don't get this unless they've added it, which honestly, they may have added this to our private namespaces. Let's see. I don't think they did though. Yeah, you'll notice that Brooks has a pending invite, but there's no discussion. He's a collaborator. So our discussion takes place a little different, which again, it's coming, I promise. But in an org, you get like this forum called discussions where we can have a conversation within our team. And only within our team. I can also add those members to it. So now it's just like adding Brooks as a collaborator. I follow him. He's here. He's invited to this organization. We can also invite him to the team, whatever we have limited seats because this is a free org. I have some orgs that aren't free that, that have much more seating that, that goes into them. Okay. So then we can change role. Right. And we, he can be a maintainer. He could be a member and we can further scope that out in the settings. So organizations grant us this. The team management and membership aspect. Also, or they also afford us some really cool stuff in the settings for our repositories. And this kind of goes on to the security side of things. What you'll notice is that orgs. Can enforce things like two factor authentication. Users. Cannot. I don't have the authentication box in a personal repository. I have an organization repository. I have the authentication option. What I do have in an organization are these security features. And you get more. Especially with public repositories, all the stuff is enabled by default with private repositories. We have to do some stuff around here to enable them. And if we're free, we're limited. That's the catch, right? So we can. Enable this dependency graph. What this does is it shows us all the dependencies that are in our source code. If you're not a developer, you don't really care about this. We can enable something called dependable. Well, if we have a bunch of repositories, Brooks, and our users are allowed to create whatever repositories they want, how do we know they're not introducing vulnerabilities into our structure? That'd be a good thing for me to catch, man. It would. The good news is, is GitHub will do that for free automatically for you. You can click in this little check box and every time your users create a new repository, because this is an org level. This is an organization. It is enforcing the rules throughout all of your members. This will automatically be enabled in the moment that that JavaScript library has a, a CVE published. GitHub will aggregate that to its database and a bot will send an alert to you saying we found a vulnerability in your source code. Oh, by the way, here's the fix for it. Just merge it in. Hold up, man. Hold up. Stop right there. Hold up. So what we're saying now is, is that we've gone from, Hey, there's this thing called GitHub that you can put code into. Hey, there's this thing called GitHub. We can create projects and we can collaborate. We can talk to something like this where I've got automated security alerts so that when people are putting code up there, maybe they're good. I mean, you know, it's a civic project. I may have somebody I ran into that says, Hey, I know how to code. No, they don't. And they're starting to put all sorts of garbage in there. This thing will actually catch it for us. Yep. Let me see if I can find one really quick. Here we go. What is this in? Ha. So here is an app that I have. This is a repository. Right. And right here. I didn't do this. This is that depend about feature. We found a potential security vulnerability in my dependency. Okay. I can click on see that dependent bottler. We got some new features and it tells me, Hey, this is a high priority problem that you have in this repository is 17 security vulnerabilities in this code base. Wow. We can click into each one and we get detailed information. We can see all the metrics for it. And we can see what package it's a part of and so on and so forth. We can see the ID of the CVD. So we can dig into it and go from there. Now, because this is a personal repository and I can tell because it's my username and then repository, not cloud college or INE or GitHub or Microsoft and then a repository. It didn't do the automatic fix for me. Okay. But there's a catch. It doesn't do the automatic effect of the fix for me. However, if it was an org and I had this box checked easily upgrade to non vulnerable dependencies, it would apply the fix. So this is a situation where not only as we as developers creating code, trying to work towards a project, but if we have somebody who stays working as the community manager, or if it's actually at a company where there's a project manager because it is all of this available to them just to look at at any time. Yep. And some to a degree, right? If you're only a member, you might not see some of these settings. If you're an owner or an administrator or a maintainer, you might see some of these settings that it's hard to say what GitHub's going to show you because again, it's a rapidly moving project and one week, everybody might be able to see what's enabled, but not change them in the next week, they might hide it. So I can't tell you for certain exactly what your view is going to be when you do go click into this. Sure. What I can tell you for certain is that we can manage these things. And this is enforced to all of our team members, whereas in order to get dependabot set up for this repository, it's public. I didn't have to do anything because it's a public repository in my own namespace. It's just there. But again, I don't get the cool automated fixes for me, but I can jump right in here and read all about the, the CVE, but look, they even, they did this. They said, Hey, like we're not going to automatically fix it for you because you're, you're a free loader in everything. But if you just click this button, here you go. We have everything we need. It's, it's starting this automated process to where it's going to go update our code for us. So even though I'm free, I could just click that button really quickly and bam. Yeah. But I mean, this gets to the point, Matt. And I hope everybody's, I'm, I'm, I'm trying, I'm making a point here because I'm such a, just a absolute hawk when it comes to security that even for situations where you have security teams that are needing to go in and check repos, they basically are getting it handed to them. Here's the latest CVEs. Here's code. This non-compliant to the point of they can really take ownership of that process where I've been in Oregon. I know you have two, Matt, where, you know, typically security has been that team sitting over there. They let you know there's a seat and afterthought. Yeah. They're sitting over there. The thing's already out there. They're not proactive. They're coming out and saying, oh, there's been four CVEs published this week. You need to create some sort of workflow to make sure they're addressed utter nonsense, complete and utter nonsense. Where if you have something like this, you can update your source code, push it back out through automation. Again, talking about things like actions that we'll look at more. And I'm hoping everybody's seeing this is a huge time saver. It's a worry saver. And so there's a worry, a worry denier because it can deny you from worrying, but also because of the visibility. And this is something Matt and I spoke about earlier today. When those questions come up from the management and from project managers about where is this at? I like the answer saying, did you go look and get him? Go look. You can see what's the problem, what we're doing, how it's being resolved. This is an awesome tool for things like that. Now it's not going to give you 100% coverage. Please don't think that y'all know. There's no such thing. You're going to have to get your hands dirty. But as a way to get those low hanging vulnerabilities out of the way, as Matt just showed you, I mean, it was just click, click, click. And he's done. Yeah. And that's on a, on a personal account, right? And to that point, like DevOps, right? What's the big mantra? Shift left, shift left, shift left. Well, what's more left than the source code? Maybe the planning and the schematic, right? Like, yeah, yeah. This is, this is pretty left as far as that goes. So this isn't deployed. This isn't out to the public. And we knew there was a vulnerability in the dependency. Now that's just the dependency. That's not static code analysis. That's not, you know, runtime analysis. It's not some other stuff that you, you could do to check the security of the applications, not a penetration test, right? It is quite simply dependency analysis. There are other things though with GitHub actions that you could enable to do static code analysis. And it's not exactly static code analysis. It's kind of a new thing they're trying to do where they're trying to detect vulnerable patterns and stuff in a specific way. I don't know that the nitty gritty about it, but you can tie that in and have that happen as well. So this personal account on a personal repo has these security features. I can set up a security policy. I don't have one set up. Now what this is, it's just a text document that tells users how to report vulnerabilities. Right? Now we're in collaboration. This is a public repo. Brooks happens to stumble upon it and he's like, Hey man, you're really bad at writing code. And I'm like, yeah, I know. And he's like, I need to report a vulnerability. How do I do it? And instead of saying, well, let's jump on a zoom call Brooks and I'll tell you how to interact. I can just say, read the security policy and it'll tell you exactly how to collaborate with me. So the second thing you'll see is that this code scanning. Right. This is static code analysis. It's not set up for this. And if I click on this, I can configure code QL and some other code scanning tools. Right. It's not configured by default for me and that's okay. Again, personal namespace. We have our advisories. So I can also disclose a new vulnerability. Maybe I find it in a public because I'm doing some bug bounty stuff and I find it in an open source project. I can draft a new advisory to tell everybody about a vulnerability that I just found. So the collaboration about security exists right here. Coming back to the org. We get similar things. The difference is really that it's forced upon the membership and the repos of the org. It's not enabled on a per repository basis. The other thing you can set up is approved domains. And we can then also do some secret management stuff. So we can store encrypted secrets and credentials that we might need for automation pipelines. We can do that in the personal space too. It's just a little different. It's not applied to every repo in the personal space. It's on a per repo basis in the organization space. These settings exist for everything that takes place within our organization. These are blanket. Rules that come into place. Yes. That does not though. That does not eliminate our ability. See cloud college organization. Repository. It does not limit our ability to come in here and have access to the same features. I was going to ask. Very cool. Very cool. So now we're layering it. We're saying by default you look like this and you'll see these were enabled by default and that's an org level rule. This has not been enabled. I could enable that. Right now that's enabled. So I would get automatic fixes for my dependencies that are out of date, which. Scary sometimes. Right. Broken dependency or dependency fixes can break things. So double check everything, but you do get a chance to do that. I get all of these alert and I can say, Hey, like. If you're an admin or I need this security professional to know when something goes wrong, like let me set them up with alerts so that they get everything they know. Or let me make sure the main painter of this repository knows when there's vulnerable dependencies. I can also do fancier things like configuring any type of deployment keys I might need. And I can manage the secrets a little bit different. And I can. Right. But because this isn't a repo in an org. This is just the general security that, that kind of exists for us. And then I can also see the differences in roles here, which I don't get in the personal namespace. I just get collaborators in the organization namespace. I get these fine grain controls over what that means. The other piece of this is in a personal namespace. I invited Brooks to a repository. And he will never be the owner of this repository. I will always be the owner of this repository because it's under my user account. In an organization, if Brooks creates a new repository, he is now the owner of that repository. He can assign that team ownership of a repository. He can decide who gets to see what. He can decide who gets to see what. As far as what teams have visibility on that repository, even though it's within the org. So you can still fire off private repositories that only the people you want to see can see. And manage that without. Eyes that shouldn't see a senior. Okay. Even though you're in an organization together. Exactly. I'm going to go back to that. I'm going to go back to that. I'm going to go back to that again because there's a point I want to make to everybody. And this is not a little point. I'm about to throw something really big at you. I want you to grab on to this. If you look at the research has been done over the past three to four years on DevOps. Cultures inside major corporations. Something kind of scary is happening. The space or the grouping between. Companies that are falling behind. And there's a lot of people that are doing well. And normally it's like. These folks are doing terrible. There's like a nice big bell curve. This is most of the people that over here. Are the people that are really doing well. The thing flips upside down. There's a whole lot of people not doing well. And there's a pretty good amount of people that are doing. Fantastic. So you've got awful and not well in that group. Those groups are spreading right now. I can dig more into the numbers. I don't want to bore you with it is a huge research paper. But I think that's just some of the things that Matt just hit you with about, let's do 10 minutes on this one. Matt. The stuff that Matt just hit you about, about the collaboration, the ability of a security team to quickly see what's going on. The ability of PMs to quickly jump in there and see where a project is to see if something's gone off track. Because they've lost members. Members have been sick. Members have been retasked and they didn't know about it. All those sorts of things that seems so just. What's the point? It's just the lack of a sense of responsibility and the lack of responsibility that we're going to have. The lack of a sense of responsibility that we're going to have in the House community have latched onto and allows them and Matt can back me up on this. This is a critical metric. They can generally, and we'll talk more about Maine and branching later. I don't know if we're going to get to it today or maybe tomorrow. But from the time a change has been pushed to Maine. To its, you know, it shows up on my phone here. Is about an hour. And the only way you're going to do that, y'all, is if you have a tool like this and you understand how to use it. So your team can collaborate real time. Quickly see what's going on and be able to address those issues. So even though we're just kind of showing you what looks like, oh, that's kind of nice. That's kind of nice. No, it's not kind of nice. It's going to be thing that's going to be critical for any organization going forward to be super successful. With what you're seeing happening in the space over the next coming two to three years. And that's going to be critical. And that's going to be critical for any organization going forward. And that's going to be critical for any organization going forward. With what you're seeing happening in the space over the next coming two to three years. Yep. And a lot of that seems like it's only. For source code, right? Dependency management. You're not going to have that in documentation. However. All of the access in the roles and the collaboration pieces behind that are not. And in documentation, people could commit secrets on accident. And get hub scans for those. Yep. So we're going to take a break. Come back in 10 minutes and we'll carry on. Okay. Welcome back everybody. Now moving into the afternoon. What are we going to be looking at next, Matt? After a break. Oh, repo features. Yes, we are going to jump into the different features of GitHub repositories. And again, follow along. We are going to create a repository that at the end of the day is going to be a little bit of quote unquote fun to work within. And it's going to be one that we build upon. For the remaining days of this boot camp. So it's really important that you do get this set up. If you want to play along with us. And I think this is the one, if I'm not mistaken, they really want to do this one. This is a cool one. Well, the good news is last time I checked, you want to do all of them. But yes, this one is, this one is really, no, I wasn't suggesting that. No, no, but everybody listen. I know we're mad. It's going with this one. This is a cool one to do because it'll get you on your way to having a really cool repo that you want to show off. Absolutely. So if you go to get hub.com and you click your little profile icon or yeah, in the right corner and then click your profile. It looks like this. And this is cool, but it's kind of boring. Like there's a lot of things we can do to this that personalized this a little bit more. And we could have like a welcome page. We could have like a resume. We can have a lot of stuff show up right here. But we have to use a repository to do that. And so the first thing we're going to do is actually start that repository. And then once we have that repository created, we're going to talk about all the different features of a repository and kind of demystify some of the stuff. And this goes back to a question that Brooks had asked earlier about issues and what they're for. And I will tell you my issue with issues as it pertains to discussions. And that's a very telling and foreshadowing statement. So the first thing is you can, if you're at regular the github.com landing page, you'll see a green button here that says new. You can click that. If you're on your profile page. And again, we're not in an organization. This is just our, our namespace. Okay. You can click this repositories tab right here. And you can click new from here either way. You can do that. And you'll be greeted with this screen when it chooses to load. Okay. This is creating a new repository. This exists in your namespace. I recommend that you make this public. It's up to you. You're only going to be able to leverage its coolness if you make it public. Okay. The first thing you're greeted with. Is this, if you already have a project somewhere else and you want to put it on github, follow this guide. Maybe you have a bit bucket repository. Maybe you have a Git lab repository. Maybe you sat down and you ran a command in your terminal that was similar to get a knit. And you have a local repository that you need to move up to GitHub. This is your section for that kind of tells you how to do that. We do not have that situation. So we're going to create one from scratch. The next thing we have is a template. And we'll talk about templates as we get into this. But for this case, we're going to use no template. Okay. And what's cool is if I'm an organization, I can set up templates for people to use. So there's some learn code templates. There's some GitHub training templates. And there's even some templates I have on my own namespace. So maybe I have a structure that is very common for repositories. I can create a template for that so that my users, when they create them, it goes really quick. And we'll show you. Is that something I set up because Matt was just asking, and so is Patrick, they don't have any templates. So that's that's something that's automatically populated. Or is that something I know what that is. Okay. That's a catch. I'm on a pro account. I'm willing to bet that it had, that's probably a feature that I get for having a pro account. So that's something that might be worth the four bucks a month to you. I don't know. To put it in perspective to you or for you. I never use this. It's such a rare feature for me to use. I have used it in the past, but very rarely really. You have a pro account and no repository template. Interesting. I don't know what's giving me the ability to see this then. I might have something set in my settings. That allow me to use templates. Let's see. Repositories. That's just showing me a bunch of stuff I'm connected to. I might have something set up in my settings. That's interesting that you can't see it. I thought that was a pretty standard thing to see. So it's weird to me that. Oh, so somebody has it and they're not on pro. Yep. Yep. Yeah. I've got the same sort of thing because I've actually got one project. It's pal faucet. And a pal faucet is actually set up as a template. So when I hit my drop down to my own personal account, boom, pal faucet shows up, but that's the only thing that I have. Here's the other thing I could think of and it wouldn't surprise me if this is the case. And that is. If you have templates available for you to use, you might see this. And if there aren't any templates available to you due to organization membership or the fact that you don't have them set up. It might not even show up, right? Cause at the end of the day, it's a dynamic app, right? We can just render that component. Yep. So that's what I would guess it looks like there's something in the docs about creating a template repo, which we'll get to. Yep. Matt B beat me to it. Nice work, Matt. I was going to try to go. Yeah. Duck duck go that one. But before I could get there, Matt B beat me to it. So yeah, if everybody will look any questions about that, Matt's got a great link down there over to creating template repositories in your account. It will explain how. Yeah. So creating the template repository is really easy. I'll show you how to do that. It's a check box, but I'm guessing that's why this doesn't show up right now is you just don't have any available to you. Right. I can think of some really simple react logic that would do that. So we can give it a name and like, let's go back to that fun culture stuff. You have to give your repository a name, but notice if you can't think of one, good hub suggests one. And you can just click on that and it'll populate it. Nice. But these are all goofy. It's just like, if you're familiar with doctor, all the container names for doctor are all goofy. So these are just goofy names, but you'll see they're all in the case and they all have a dash. And this helps because they become URLs. You don't see spaces in URLs. You see dashes to reflect those spaces. So what is actually going to happen is it's going to be GitHub.com slash Matt Davis 0351 slash studio journey. Okay. Before you move too quick though, some of you are about to end up with a second repository because you already hit next or you're going to name this repository the same as your user name. Hey, and you'll see that we get something interesting that pops up. This is a special repository in this repository creates this added piece to your GitHub profile. And it's really cool. So go ahead and create it with the same name as yours. You can give it a description if you want is optional. Okay. I'm not going to do it. We're going to overwrite it anyway. You can make this public or private. I'm going to make mine public. I have no fear here. We're not going to put anything crazy. So this is what you were talking about a moment ago when you said, let's make this thing public because this is going to be like our resume in GitHub sitting out there. I hate to use the word resume because of all the connotation. Y'all, that's not what I mean, but it's like your public facing piece of GitHub. Is that right, Matt? Yeah, exactly. And you'll see how it ties in once we build it now. It's for teaching point. Earlier Brooks, you asked me if I have a private repository, can I make it public? Right. I think we should find out. So I'm going to set mine as private. And I'm going to try to change it later. Don't do it. Don't do it. We're going to do it. You don't have to follow this. You can set yours as public at the end of the day. Set y'alls to public. Mine's going to be public. We'll spill that spoiler now. Yeah. So the next thing you can initialize it with some files. Okay. Since this one says if we add a read me. It's going to go to our profile. Let's go ahead and add a read me. Now what's the extension on that read me file? Good, sir. It'll automatically be put in, but it's not MD, which is a markdown file. Markdown. Here it comes again. So here's the best practice for you. Every repo should have a read me. It is the thing that shows up when we first click it right here. What gets rendered. You'll see this one. For some reason doesn't like this. This is at a read me. Maybe it's in the wrong spot. Maybe I did something wrong with this repo, whatever. It should render just fine. It's probably empty as a matter of fact. That's, I would bet you a diamond doesn't. Yeah, it's empty. Yep. Yep. So let me go back to a different repository that I have and I'll show you this. Some of you might know this. It could also just be new to everybody. So in here, here's a read me. That's what gets rendered right when I first land in any repository. Honestly, it's what gets rendered when I land in any folder within a repository. See, welcome to oranges. Yeah, whatever. Okay. That's coming from the read me. So always initialize a read me. This again, let's shift our documentation left. Just like we shifted our security left. And we'll give us a landing page for anybody that comes to that repository. Okay. The second thing we have the option to add a get ignore. We don't need to worry about this today. You're using the terminal and you're using like get the tool. Get fun fact. Get is not get hub. They are not associated in any way, shape or form different companies. Then you might want to add a dot get ignore file. I'll show you one later. Okay. So don't, don't fret about that. We actually are going to set one up as we do a little devop stuff with a small web app later. We're going to have to ignore some files. In fact, that's for those of you that are on a Mac. Get push of shame right there. So get that store, huh? The DS store. Exactly. So we'll be looking at that everybody. Definitely. And for those of you who are on a Mac, you're going to want to see that. Yeah. If I see a DS store in your repo, I'm probably going to do a drive by on it and comment that you're silly and you need to add a get ignore file. Exactly. Thanks. The next thing is choosing a license. Hmm. Hmm. Why does this matter? Well, if I'm going to make a project open source, that means I'm probably okay with contributions and other people using it and adding to it and modifying it. So I can add a license to protect that property. It's that simple. Wow. Nice. If you choose add a license, like you pick, like it's not hard. If I want to set up an MIT license, bam, it's going to be set up. I'm not going to do this. I don't need a license on my profile. Read me. It doesn't apply to me. But let's stop there for a second because then this again, y'all, this is one of those things we, Matt and I drive by real fast. We don't make a big deal out of, I'm going to stop them. If I were to have said to you, create an open source project and apply the MIT license to it. How many of you would have gone like, okay, yeah, whatever. Or how many of you have been gone like, um, I don't even know what that means right there. Click, click, and it would be done. That's again, one of these really, it's almost a superpower of GitHub to move your project down the line faster by allowing you to left shift those sorts of things like that. Yep. And if you don't know what license to choose, click, learn more. Wow. There it is. Here's all the information about the different types of licenses. And you can get all sorts of helpful information again, like get hubs that home for open source, right? So anything about open source is going to be at your fingertips. You can also add this later. So you don't have to decide are we open source right now. We can decide that later. We got some default branching, which we're about to talk about branches. And then you probably don't see this. This is a marketplace GitHub app that I have in my name space. So every time I go to create a repository, I can select which GitHub apps I want to apply to that repository as well. At the organization level, you can have these show up and say like Jira, like you can have Jira and you can force that app to be a part of every repository too. Just saying. So when you're ready, hit create. And we wait. And the magic happens. Hey, look at that. Look, I have a read me. It's rendered. It says, hi there. What up? It even has an emoji. Now. Why does this matter? If I come back over to my profile, I get this really cool thing not showing up. We'll see why in a minute, I guess it should show up here. It probably takes a minute to propagate to be honest. Oh, ha. I know why mine doesn't show up. And look at that. It even told us what the problem is. Isn't that nice? Exactly. Remember, I made mine private. Oh, shucks. Let's go ahead and go to the settings. And on this general tab, if I just scroll all the way down, you can see all the different stuff. Oh, let's enable discussions too. While we're here. Let's enable. Danger zone. Oh, change visibility. We're going to click that. We're going to say make it public. And it's going to warn you what you can do. And then it's going to ask you to type the name into the box and hit change. Wasn't that easy. So now it's public and I enabled this thing called discussions. So if you don't see this tab. Code issues, performance discussions. Go into your settings. Scroll down until you find discussions and click that checkbox. And just as easy as you can turn it on. If you're like, Oh, should have never done that. Turn it off. Exactly. So now if we come back to my handy dandy profile. Look at this. Look at that. This renders. So this is really cool because you can say you don't have many of those options. Are you on a pro account question? Which options do you have? If you can tell me the options you have, I can help a little easier. I think. Right. So this is really cool. Maybe I've seen a lot of cool ideas with this. I've seen guest books to where you can come to somebody's profile and they have a button in there. Read me that says, click this to sign the guest book and it adds your name to a list of all the people that have visited their profile. I've seen people put their resumes up here. I've seen people put their top five projects up here. And I have a cool task to show you a little bit of automation for hours, but I encourage you to come up with something and be creative. If you do a little bit of Google foo here, I'll go back to mine in just a second and you'll be able to see the tabs. If you do a little bit of Google foo about GitHub profile, read me's, you're going to see a lot of really awesome ideas that you can set up and have as a GitHub profile, steal them. Yeah. This is bad though. Like we don't want this. So we're going to end up changing ours as we go over these features. So this is now changed and says, if you want to edit it, you can edit it. So these are the tags I have. Oh, you mean in the settings, you don't have those. Yeah. You should. You got to be under the general tab. I almost guarantee you have the danger zone because that's where the leading a repository is. Yeah, Patrick, you should have that danger zone at the very bottom because you've got to have that delete repo. Take another look and take another peak. Yeah. In all circumstances, you have the delete repo. Problem. Yeah. So it's under the general time. Yep. He found it. Cool. Thanks for looking at it. Cool. All right. So let's start and we're just going to go top to bottom left to right. Okay. We're going to talk about all the features that exist here at a very high level. And then tomorrow and the following day, we're going to get hands on dirty with those features. And then we're going to make sure that you ask the questions about them today so that we can just drive and do and interact with them tomorrow and the next day. Okay. The goldfish memory feature. Yeah, it is a good memory feature. No, it's not because I was like, wait, what was I doing? Yeah, but you can never be upset because you never remember why you're upset. So it works out. So first things first, this, this left hand thing, the first part of this locator, I guess is your name space. So is it an org or is it a personal account? And the second one is the name of the repo. Right. This is all appended to the end of github.com. If you look at your URL up here, it's github.com slash namespace slash repository name. Right. This is why we put dashes and not spaces. So it's not a problem. It's simply, okay. If your repo name has uppercase letters, it just gets squashed into lowercase letters anyway. So it's not a problem. At least in the URL. I'm pretty positive. Okay, second to that is we have this, this little pill that tells us the visibility. If you ever try to go to a repository and you get a 404 air, like if Brooks sent me a link that I didn't have access to because it was private, but if you ever try to go to a repository and you get a 404, immediately double check that you're a collaborator or that you have read access at a minimum to that repository. You probably didn't 404 because there was an error. You most likely 404 because you're unauthorized. We get this pin button. This is new. Never seen this before. My best guess is that it pins this to your popular repositories tab. Because this automatically shows up. Watching and unwatching. This is really cool. If I go to, let's say I'm really interested in pandas. I'm going to search all a get hum. And I'm going to go to the pandas dev, not pandas, the animal, but no, no. Python pandas, the other animal. Yep. And I want to know when they do stuff. I want to get notified when pull requests go in or whatever. I can click this button. And I can watch and I can set what type of alerts I'm going to get, but this is going to tell me like how I'm going to get alerted when repository actions happen here. That is a huge deal y'all. That is the sort of stuff that somebody in your organization pops up one day and says, Hey, we need to take a look at something because it looks like they just updated the pandas code. And everybody's looking like, how did they know about this? It's just that simple. They are not that smart. They don't work harder than you. No, no, no, no. They just got features like this that are taking advantage of. So in a project where you're watching, you know, and again, we're talking about code here, but this could be documentation. So it could be the, you know, again, some civic project where you're setting up the requirements and rules for how the community is going to contribute to something. If there's ever a change, let me know. For example, you know, we're talking about, you know, like local government setting up rules and regulations for a city or something like that. If they put those rules and regulations instead of in some, pardon me, some stupid word document or on some stupid website, if they did it in places like GitHub, where there's collaboration, you could go in there and do a watch and if there was ever change, you would know about it. So I'm hoping that don't get too close to the action here ago. This is just a thing for developers or this is just a thing for code. It applies to anything and that really can empower an organization to keep a tab on what's going on in terms of documentation, code and so forth and so on. Exactly. That's a great point. Another example just to take it away from code is let's say you have an organization, MyCorp, and it has a hiring manager team. You're a part of that team and you have a repository that says job postings and you need to know when a new job is created or new role is created. You can watch that repo and you will get an email alert that a new job posting has been added. You need to go collaborate on that to make sure you're not getting an AWS candidate with 200 years of experience. Exactly. By the way, speaking of that, I'm not going to name the company, but there's a company that I know something about that has the worst hiring practices that I've ever seen. It's not the one I'm at right now. They do it slick, but it's some other company and their hiring process is a hot mess and one of the problems is the amount of documentation that's generated for any candidate whatsoever. When you hear things like that or you're experiencing things like that, y'all, think of things like this, like saying, hey, why aren't we creating repos for this stuff? Everybody just dumps their documents in. We all watch it. When there's a change, we can see what happens. This isn't an enabling tool in that aspect and that's one of the powers. I know we're sitting on watch for a second, but we've got to make a big deal out of it so you don't miss the opportunity of what this tool can do for you and your organization. So opposite to that, maybe things are too noisy. If I click on watch, I will, I can say, hey, never notify me and I will never get a notification on this repository. Or I can say only notify me if I get an app mentioned. Now, the extra cool thing about that is, oh, that didn't, why didn't you watch? Watch. Okay, whatever. The other cool thing about this is this button can trigger automation. Okay. Let's think from a non code point of view. What if I had this repository and Brooks lands in my name space and he's like, man, Matt, this project's really cool. And I'm like, I know, Brooks, I made it. And he's like, I want to keep track of it. And I want to, you know, make sure I see all the updates. So he clicks watch. Well, I could manually find out who all of my watchers are and send them a thank you email. But I think that I'm not paid to do that and I have better things to do. What I could do is when he clicks watch, I could tie automation into this that automatically mentions Brooks in a comment and says, Hey, Brooks, thanks for watching the repo. Really interested in the project. If you ever want to contribute, consider checking out this documentation and how to contribute to the project. By the way, contributions are welcome. And I could automate that. Yep. So that's another new code has everything to do with community management and shifting quality to the left again, because quality isn't just product quality, it's experience quality. So you'll, you may have noticed, mine says pen, but pandas is sponsor. If for some reason you do have an open source project, you can set up a sponsorship program to where people can like tip you for using your project. That's what that is. So like if you used pandas a lot and you're like, man, I really want to pay the maintainers, like give them a tip for like maintaining this giant library, you can do that here. Which means if you have the idea in your head for giants open source project, but you don't want to waste time on it because you're not going to make any money, you can also set that up to where people can tip you just saying. The next thing it's great out right here because forking is not enabled and this repository is locked. It's most likely because it's this very special repository. If I go to a different repo in my namespace, like glowing aqua umbrella, you can see the fork button exists. If you click fork, it will create a copy of this repo in your namespace. For example, now we'll dive deeper into forking later. Okay, tomorrow as we go to do things, but just understand that that is a button that says, Hey, I would like a copy of this repository, but I don't have access to it. Right. I'm not added as a collaborator. I'll show you an example of that. It'll probably take a little bit of time. But if I were, I am not a part of pandas, I do not have access to the pandas repository, but if I want a copy of pandas, I can click fork and I can click on this and it is going to copy this entire open source library repository into my namespace. So now I can work on my own pandas project. Maybe I want to extend pandas. Okay. Maybe I want to contribute back to pandas. This would be a required step for me to send a change to pandas because I need to be able to have right access and pandas is not going to give me right access to their organization, but I always have right access to my namespace. And we'll dive deeper in the forks later tomorrow because cloning is scary and forks are scary and they're very similar. And I'll tell you everybody a great reason why forking can save today to something funny that happened just recently. So the next thing is this star count. It's just like watchers. Only it's like, I'm not paying attention to alerts. I'm just, I think your project is cool. Again, that fires an event that we can listen to that we can pass some automation into and say, hey, like, that's really cool. Thank you. Then we get into this first tab, which is the code tab. This is where you see what's in the repository and we keep saying repository, but let me demystify what a repository is. It's a folder. It's a very fancy folder. So we all have folders. We got our family photos in there. We got our monthly budget in there. You have all the jokes that we tell about Brooks on the back end in there, whatever it might be that top level folder, like my documents folder, that's this repository name. Like that's just the top level folder. So repository is just a fancy folder that remembers some history. And if you think about it like that, you're going to be just fine. So the code tab shows us that folder. We can add folders to this. We see that over in pandas. Look, here's a folder. Here's a folder. Here's a file. It's no different than a big, giant, funny folder. But when we're on the code tab, we immediately see the read me for whatever folder that we're in. And in this case, we're in the root folder. If we were to go into scripts for pandas, now we're in the scripts folder and they do not have a read me. So nothing is rendered. Okay, so we can navigate this just like you're now navigating through a file explorer, which I think I have one here, right? It's no different. Baby, come back. It's no different than navigating through this. Okay, so I can click into AWS and I can see that stuff there. Same thing. As a matter of fact, if I were to click into my home folder and find my I and E folder, this just happens to be the repository that I've created for this bootcamp. So we could actually go take a look at that and you would see the repository maps perfectly with what I see in my file explorer. We're not going to go through that. I think you guys get that. You're all smart and have computer prowess. Okay, so the code tab just shows us a file explorer. It also renders files. Watch, look, if I come over here and say let me click on so cool run in vulture.py, check it out. Here's the code syntax highlighting everything. This is what's in that file. Great. If it's marked down, same thing. Same thing. Markdown rendered by default in the read me. Oh, it's a fancy read me status badges. We'll talk about that later. Right. I can even click into that read me. And now I can see that that file standalone on its own. Let's find a different file. Here's the YAML file. Where's the text file? Here we go. Here's a text file. And it shows us what's in that text file. So this code tab is helpful for very quickly without downloading these two local machine, seeing what is in each of these files. Okay. This is also where we edit stuff. There's a little pencil right here in the right hand corner of the file. If I click on that, I get an editor right here. And this is all commented out because it's marked down and we're going to get to this in a minute. So don't don't jump ahead unless you're real comfortable with repository features, but we'll jump back into this and we'll edit it in a minute. So if I hit cancel, we kind of edit that out. Okay. I can go back to the code tab and it's here. If I ever need to know where I am, I can look right here and I get the file path. So this is the root folder, but this is the file path thing that I'm looking at. So if I click pandas and I come into CI and I come into depths and then I come into this, you'll see I get a trail of breadcrumbs telling me where I'm at in the repo. If you don't see that, it's because you're in the root pro tip. All right. The next thing also the code tab is where you manage branches. We'll get into branches. It's where you can add more files. It's where you can go to a specific file. It's where you can figure out how to clone a repository. That's all on the code tab. This is like the main tab that you're going to land on to do stuff. The next tab is the most controversial tab in tab history. So much so that they created a brand new feature about it. It's the issues tab. Now issues sounds like a bad thing, right? If we come to look at pandas, look at how many issues pandas had. What? 3.3 thousand. Is pandas really that broken? There's like three Python developers right now that are like, yes. The truth of the matter is it's probably not. When you're going to do something on GitHub traditionally, this is changing, okay, but traditionally it starts with an issue. The work starts with an issue. I'll say it again. Everything starts with an issue. Need to create a new job role? Open an issue. Have an idea? Open an issue. Need to do a bug fix? Open an issue. Think this boot camp is great? Open an issue. This is the one, y'all, that when I was talking to Matt about the first time, I had one of my first moments because it occurred to me that this really shows off something about GitHub that it's about doing work. That's the point. It's about doing work. It's like, what do we do to keep up with what we're doing? Issues. Throw an issue up in there. It's a great way. Not only for that, but again, thinking about managers and stuff like that, trying to figure out what's going on. Go look at issues. You can see what we're trying to tackle right now. So this is cool. You click the issues tab. We're on pandas for the record. You can search any repository. We're going to jump into this. We're going to create some issues and stuff later. So again, theory today. Pack up later. We can scroll down this and we can see, hey, here's a bug. Here's an enhancement. These are all tagged. Boom. Project manager. Hey, what, what's in the pipeline? What's in the backlog? Click on the issues tab. Do yourself a favor. Oh, look, it's nicely organized. Here's a needs triage. Here's an extension thing. So here's docs. Hey, missing links in the docs. I don't know that they have ideas in there, right? It's up to you to decide what issues are used for. But the idea is issues are used for everything. We might be able to sort to see if they have like an idea label. Yeah, ideas. Yep. They've got an ideas. So if we look at ideas, here you go. Disk. What do we think that might mean? Discussion, right? Yup. This is not a broken thing. This is not a feature. This is not a change. This is a conversation. Right. And if we look into it, this is what's great. Oh my God. Project manager comes by says, Hey, where are we at? We'll go check the issue because we've updated the issue and you can see all the conversations that we are having. Look, JB opened the issue. He said, Hey, this is what the issue is about. Topper commented on the issue. JB commented. This person commented. All of these are comments. They've even mixed in some changes and linked to other things that all pertain to this work. Boom, from a project management from a work in progress from a I need to know what's going on point of view. It's all in front of my face. I look, he added a tag. He referenced it somewhere. If I click on this, bam, this is where it was mentioned so I can go look at where all the cross links to this discussion was going through. And if you think issues are a bad thing, this is issue number thirty nine thousand one hundred and thirty three for pandas. So simmer down, create issues. Guess how much they cost for the first thousand. Guess how much the remaining ones cost is no limit. Just create issues. They're free. They're super duper free. Okay. So what's great about these two is you can set up issue templates. Let's come over to pandas. Notice how this one says discussion. This one says bug. This one says enhancement. They probably follow a structure. So if I, since it's a public repo, found an issue, right? So if some other team realized 20 years of AWS experience isn't acceptable, or if a student took your course and noticed something wrong, they wanted to contribute a fix. They could say, Hey, new issue. Look at this. These are templates. These are templates. And I can just create a blank issue too. If these don't fit my needs. If I click this, I say get started. It opens this issue and it gives me this little form to fill out. And it's handy dandy. All issues are going to look the same. So if we go look at a bug, all bug issues are going to have this structure to them. Real quick. By the way, guess what they're written in? Markdown. Markdown. And that's why we get cool things like checkboxes, syntax highlighting for code, images, expanded details, you name it. It's all here. By the way, for any of y'all who are who have experience with Jupiter notebooks, when you put a Jupiter notebook with the proper extension into GitHub, it executes that Jupiter notebook. I got you. I got you. Show me. Show me. Show me. Show me. Y'all, this is a big deal. If you're trying to get a job as a data analyst or something like that, you've put together some really slick things with pandas like we just been showing you, you put that into a Jupiter notebook, you put that into your GitHub repo. When you're at the interview, when you're showing you what you can do and stuff like that, and they run that particular notebook, it'll actually execute the code inside there, your Python and put those and actually show like if there's going to be a graph generated something like that, it'll put it on the page for you. It is very slick in that regard. So I see the question chat from Benjamin. I'm going to get out of the way why you answer this one just in case you. I'll answer that. I'll answer that in a second. So shout out to my wife who built this, by the way, stunning data scientist threw together this right. So look, this is the readme. It's funny and there's links. And here's what Brooks is talking about. This is a the execution happened. You just did everybody see that? This is a Jupiter notebook that is just the the P and Y B or whatever the file extension the IP Y and B that file is committed the notebook renders. So it's really cool. I'm sure somewhere in here there's graphs and other fun stuff. Okay. The data that you all are seeing that is not stuff that she typed in there. That is the execution for the code that she's like, for example, we can see line 13 right where she does the value counts. GitHub will execute that for you and then put the result right there up underneath it. It'll actually execute the block. So if you need to show off capabilities for data or for example, even better, if you're just going to a meeting and you want to show off a proof of concept because you're in some data driven organization where all the decisions are made on data and you want to show that off. This becomes a really slick way of showing this off outside of going, oh, let's go put together a PowerPoint presentation. And it's not limited to pandas. It's Jupyter Notebooks, whatever you can do with Jupyter Notebooks. That's true. Thank you. I said that wrong. Thank it renders. Yeah. So, um, yeah, shameless plug on that. Super cool. Beware though. Sometimes that gets a little wonky. Sometimes it doesn't. So double just double check it's strange. It's cool, but it's strange. So the question is do we even need Jira having GitHub issues? You are really hoping that I divide the room. I'm getting under the desk. Bye everybody. I'll go ahead and answer this. Personal opinion. No, you don't. Right. Right. You absolutely don't. Now, does that mean that you go into your organization using Jira? You sit at the eye of whoever made that decision is asking like, you're silly. We're switching to GitHub issues. They're probably going to be like, you're crazy. No, you're not. Yeah. What you can do is integrate Jira with GitHub issues. Right. So this is how you do the whole DevOps grassroots movement stuff. You integrate Jira with GitHub. Then when you create issues on GitHub, it automatically populates Jira. And then as you slowly get people accustomed to using GitHub issues, you slowly phase out Jira. Right. That's the, that's the actual answer. How, how you would go about that. If you decide to make that shift. Now, here's the thing. No problem with using Jira and GitHub. Right. There could be plenty of tickets and stuff that you track in Jira that aren't suitable for things like GitHub. For example, if you are making video content and you're tracking that work in progress in Jira, GitHub is not the place for video content. It doesn't handle those type of files very well. So you wouldn't necessarily want to do that. Now you could manage that whole project in GitHub and never upload a file because you can just add a link to a readme file that points to the video, whatever. You can do that. You have to understand that you are asking an entire organization to learn a brand new tool just because you think it's cool and you're not wrong. You're absolutely right. It's really cool. It's also really useful. It's also a productivity increase because it's not as bloated as Jira is. However, that is a giant ask. So it's better to just integrate the two. And then as you work on new projects, your new projects use strictly GitHub. Your old existing projects can kind of be a hybrid kind of thing. And you can slowly phase that out. There's a bunch of strategies to go about it. The shorter answer is no, you don't, you don't need them at all. The long answer is find a way to make them work together. But what you're going to find, Benjamin, is a lot of organizations spend a lot of time, money and effort learning how to use Jira, trying to get it to work the way they want. Bending their own, bending their own processes to fit Jira. And so then when you go forward and you say, Hey, there's this other thing that's really easy. There's going to be, you know, it's, it's almost like, okay, so we wasted time and effort. So you've got to be really kind of sensitive to it and careful with it. That's why Matt's suggestion about go grassroots, show the interconnect, show how we can use GitHub. We can still have it send stuff to Jira. We can get that one to one sort of mapping between what's happening here and what's happening there. There's a lot of stuff you can read on it to, that makes it not that big a deal. So yeah, but careful with it, man, don't just run in there and say, this is what, because they'll, oh, they'll be so angry ease into it. To continue down this side rabbit hole, just to break this up a little bit. If you search for the GitHub marketplace. You'll find a link. It's github.com slash marketplace. Okay. And you could come in here and you could search for Jira. You will find, if you look carefully, you'll see that this is verified and it's, it's from at Lazian themselves, which. Okay. Probably pretty safe. This is about integration with Jira and GitHub. And you can set up a plan and add this. Now, guess how much this costs. Wow. What's the catch? Okay. The catch is at Lazian might set a price to use this. They might say, Hey, in order to use that integration, we're going to charge you. GitHub doesn't all of these GitHub apps are regulated by their developer. Right. So if we looked at this, this is another one. It's from a verified publisher. They meet some requirements that GitHub sets. It has some sort of integration. They have a free trial. Oh, that's not the same as free. Is it, but that's not GitHub that decided that that's, that's this organization. Okay. So GitHub offers you these integrations for the low, low cost of absolutely free. But the maintainer might say, not so much man, pay me. Okay. So that's the situation that we end up in. So to do that integration, come grab the Jiro software plus GitHub, set up a plan, go ahead, take a look at this. And you can tie those things together, lickety split. It's probably not difficult to time in at all. Okay. So that's how you can do that. So issues, I think we get what they are. They're everything. Just talk, have conversation. Hey, Brooks, have an idea. Oh, don't tell me in Slack open an issue. Exactly. Right. You know why? Because this, let's go back to, let's go back to pandas. Right. This is why 3.3,000 issues. Those are only the open ones, my friends. 18,000 closed issues. Remember that time, Brooks, six months ago where we, we had that discussion, we fixed that thing. I think it's coming up again. Do you remember how we fixed it? I have no clue, man. Let's just go try to find that in an old issue that, oh, look, right here. Yep. Oh, and I have the issue and I have our entire discussion around it. And I can very easily replicate that fix because I have history of our discussions. Hey, Brooks, remember that time that our manager said that we didn't do something, even though we were actually doing something. And now he's decided to give me all of your bonus. Yeah. I think I can find the issue that supports otherwise. Like, let's go do that together. Right. Let's go find it. Exactly. History is key. That is, it's, that's the fancy behind the folder, right? It's just folder with fancy. So creating issues is easy. Click the new issue button. Give it a title. Some issue. Give it a body. Some markdown. Hit submit. What up? New issue. Check it out. If I come back to issues, I have an open issue. If I'm watching, I got an alert. If I click into the issue, uh-oh, time out. Slow down. What up? Look at who created the issue. I can see who created it. I can see how old it is. I don't even have to click in. Now I click into it though, because I'm fancy. I'm fancy and I want to see what's in it. Bam. Here we go. Issue body. Who is the owner of it, right? Or the owner of the repo. It was created by the owner. But what if I want help? What if I want to assign this to somebody, right? Oh, well, Jira gives us the ability to say a task belongs to somebody. Well, so let's get up. I'm going to assign this to myself. Look at that. I'm going to add a label. Oh, it's a bug. Cool. I'm going to, oh, we're not going to add it to a project board yet. Nice try suckers. Same with milestones. We're not going to add it there yet. Pull requests. We're not going to add it there yet. I can subscribe or unsubscribe for notifications. I can pin this issue to the top of the issues tab. I can manage its visibility. Okay. And look, I can also see the history of the behavior I took to this issue. And now if we go look at it in the issues tab, who's it assigned to me? It's a bug. I don't even have to click into this if I'm managing a project. That's powerful. And real quick, just if you could point something out to me, Matt, because this has always kind of got my attention. I noticed there's a number one down there. Hash hash one. What does that mean? I mean, obviously it's there for a reason. It is just telling you. So this is the first time an issue was ever created. So this is issue number one. Watch what happens. Let's create a new one. Issue two. Why issue two. Right. I'm going to submit a new issue. And I'm going to come back to issues and you'll see it's number two. Okay. So it's just serialization to track things. And this is helpful because. If I want to comment on an issue or maybe I made a mistake. So I'm going to edit an issue and I'm going to say C. And I'm going to say number two. Look at that. Hey, did everybody see that? Did everybody see that it looked inside there. It looked right inside and said, this relates to that. If I just type number one. It typically shows up. If it doesn't show up, that doesn't mean you can't do it. If I hit preview. It still takes me to the first issue itself. References in a way. But as long as like another issue. Yeah, you can pop them in there. And that is a cool way to reference. Okay. So that's enough on the dead horse on issues there for. Everything. Everything. So much so. That GitHub created. We're going to skip pull requests for a second. Get hub created this discussions thing. And you'll see pandas does not have discussions enabled. I enabled it on this repository. This is a new feature or newer feature. So that issues can be issues. And discussions can live somewhere else. So if you choose to manage it that way, you can. You can come in here. Grab any issue that already exists. And say convert to a discussion. Maybe ideas. I understand. Convert this issue. Now, here's the thing. It closed it. Because it moved it to discussions. So now when I open a new issue. What numbers should it be? Hmm. Let's see. There's only issue number one up there. Right. So this is obviously going to be issue number two. Wrong. Issue number four. Hey. Because. Two. What's the original issue? I understand. Convert this issue. Now here's the thing. It closed it. Because it moved it to discussions. So what's the original issue? Three is the discussion. See how it's referenced right here. So what that tells me is all discussions. Are issues. They're just in a new tab. Okay. But it breaks that. But it breaks that idea apart, right? So that as they're working inside GitHub. An issue is an issue. Like this is the thing going on. If you want to talk about it. That's something else. And we can reference back and forth. Using those numbers. And you'll notice I, I have participants instead of a signees. I can still add labels. I can't put it on project boards or anything like that. Right. So the issue has much more flexibility and visibility. Then a discussion does. Which one should you use? Figure it out. Whichever one you like. I will probably. Never use discussions until discussions, but chairs more and add some more features to it. Only because. I'm stubborn. That's the answer. Okay. So you're not wrong by keeping your discussions and issues. I like them in issues because then they can be managed a little differently. So let's jump back to pull requests. Pull requests. Are issues. Weird. Every pull request is an issue. Not all issues are pull requests. Pull requests say, Hey, I made a change and I would like you to. Move that change in to the code base. Can you do that? And we can see what changed. We'll dive into those a little later, but they're very similar to the issues tab. You create a new pull request state. They're so similar to issues. That it's like they are issues. Yep. They're issues with a change attached to them. I enabled discussions by clicking on the settings tab under general. And again, I'm on a pro account, so I don't know if you'll see it. And I scrolled down to features and somewhere in here was the discussions box. And this is how much I don't believe in discussion. Cool. So we're just going to turn those off. You don't have to turn them off. I think they're good. I think they're, they just have a long way to go until they're at a maturity and I'm comfortable with using them. Okay. So if I want to make a change, it's a pull request. I want to talk about something that's an issue. So the way this works is work starts with an issue. It then gets a branch, which we'll get into branching tomorrow. That branch gets a pull request. And that's the flow of work, the pull request is the work. Okay. Very cool. So before we go to break here, does anybody have any last is any other questions floating around about issues? Pull requests, discussions. It's quite a subject and as Matt, and this is one of the reasons, but I'm so excited that y'all get to hear this from Matt. You're probably not going to hear somebody say what he just said about issues and discussions. You're just not going to hear that you're going to hear more. I don't want to say told the GitHub line, but they're going to follow more along with whatever. If they're GitHub, they're going to say what GitHub says. If they're working for GitHub as a contractor, they're going to say that you're tending to hear a little bit more of the inside stuff here. So as you're hearing this, don't be surprised at looking at other people who may be talking about this material who don't quite say it in the same way. Again, this is the inside information about it. And it doesn't look like we have any questions right now on that. So can we take another brief, our last break of the day? We'll do, we'll do 10 minutes. That's fine. And then we'll come back and what are we going to talk about when we come back? We got one more feature to cover and then we're going to jump into Markdown and then you're going to go and you're going to get your homework project that will work on tomorrow. Okay, everybody, welcome back. So what we're going to be doing now for the, we've got a little more than 30 minutes. I think we're going to talk about projects and then Markdown and then a little bit of the read me stuff. Is that right, Matt? That's the goal. We'll see what we can get. If we don't get all the way through that, that's okay. We can kick the tomorrow off with something. So the last immediate feature that we're going to cover the project managers are going to rejoice on this is this projects tab. Okay. This is super, super cool. It is a built-in project board or combine that you might have and other tools. So I can quickly come in here and say, Hey, I want to create a new project board. I'm going to call this the boot camp project. What did we learn about names? Don't do it. There you go. I can use a template. Now I don't have to set these templates up and we're going to get into a better template later. So we're not going to use one now, but some of these templates have built-in automation, right? Which is really, really cool about them. But the automation can be a little bit fickle at times. So I'm going to go without it for now. And I'm just going to hit create project. And what's really cool is now I can say, I'm going to add a column. It's going to be our backlog. Right. I'm going to create that. I can add another one and say in progress, whatever it might be. I'm going to create a third one. I'm just going to call it done. Okay. And what's cool about this is now, if I need immediate visibility on what's being worked on is a project manager or project contributor. I can click into the project. And I see this. The first thing I can do is I can add a card by just clicking this little plus symbol right here, which also takes Mark down, which we'll get to in a second. I can say, hi Brooks. Check me out. And I hit add. And there we go. Now I have this card that I can now move around by just clicking and dragging into each of these sections. So this card, can outline work. It can outline ideas. We can have as many of these columns as we want to this project board. Adding another one is easy. So I'm going to add one called ready for review. And I don't want that to be after done. So I can drag that to reorder that too. Okay. And this is great, but it gets even better. Because now if I come back to my issues, which is the suggested way to do this, right? Adding those cards are okay, but you get some really cool things. If you add issues instead. So if I go over into the issue, I can now associate it with the project. That's going to add it to a project. If I build in some automation, I can add it. To the column in the project. So I'm going to add that. To the column in the project. So I'm going to add this to the backlog. All right, within the issue. So now if I come back to the project, I click into it. You'll see the difference immediately. The card is very bleak and drab. The issue is a card, but it shows me who it's assigned to. It shows me the labels that are applied to it. If I click it, it pops open the issue over here. I can read about it and whatever I might need to look at. And if I want more info, I can click this link and it opens the issue in a new tab. The card doesn't do that for me. The only thing I can do with the card is move it around. I can still move this around. Right. And you'll see this updates in the issue right now. It's updated to in progress. And now it's updated to ready for review. And it just goes about that. So we can track. All the stuff we might want to. On the project board using issues. Now guess what? If pull requests are issues, we can also add pull requests. So we can add pull requests to the board so we can see the actual work and remember pull request is the actual change. It's the real work. It's not the talk. We can see where that real work is. We can see who did it and we can see it. We can see what our backlog looks like. And all of this can be automated. By default, by just adding some automation to stuff. If I click into this, these three little dots, I can say, hey, manage the automation and I can set a preset. On where it goes and how it works. And I can update that. I can manage that with actions too, if I wanted to. But this makes it really simple. All work starts at an issue. Even if it's an idea. It gets added to the project board to the backlog column. And you can have as many project boards as you like for the low, low cost of. There's still no catch. Have your project boards. They're free. You can add it here. You can assign it like maybe your workflow is once it's in progress, we then assign somebody to it. And so on and so forth. And you can click in to see everything. What you don't get though is like the weird like burn down rates and other stuff that like more robust project management tools might give you. It's a little harder to predict time. You can, you can set up things called milestones, but they're a lesser used feature. And then somebody had asked about the insights tab. This just kind of gives you a bunch of stats about the repo. You can see poll requests, what issues were closed, how many active issues you might have, who's contributing, what the community looks like. So this is just a lot of like stats about the repo. Just to quickly cover that insights tab. So those are the big major features that just give us boom, instant immediate feedback on what's going on, right? To include. If you're really fancy with your read me and some people get really fancy like build status and version badges and stuff of what's going on. This doesn't just apply to code. Maybe this is version one of a job posting and you just put, Hey, this is version one of the job posting, whatever it might be. Okay. Those are the main features that are going to exist. We're going to talk about what it means to clone and fork as we talk about what a get flow looks like. Okay, but this is just the main features that exist in the read me. We are going to take a small diversion, right? And I said we're not going to do code and it's not really code, but it's going to help us write documentation. We're going to take a small diversion. I'm posting a link in the chat right now. For that is not it. I just accidentally copied all kinds of crazy stuff off of that pandas. I almost pasted you all of their badges. So this is a cheat sheet for how to write Markdown and you don't have to do this in GitHub, but don't close this repo. I'm going to show you my favorite online Markdown editor. It's called hack MD.io. This is my favorite place to be. You can sign in with GitHub. If you want, which is what I'm going to do. I have this all associated with my. GitHub account. I'm going to click this green new note button. And this is going to launch me into this really cool real time editor. Now there is a catch, a small catch to this. GitHub has its own Markdown language. It's based on the bigger Markdown standard. So most things work. HackMD has its own Markdown language. So not everything I do in HackMD will translate to GitHub. Everything I'm going to show you and everything that you have in that guide that I linked you will translate. I'm not going to show you the fancy HackMD stuff. So you don't have to worry about it there. But you'll see this can link right to repositories. I can push and pull. I'm going to use this as my editor. We're not going to tie in that integration either. But Markdown kind of works like this. The aqua Thorpe favorite word, word of the day. Also known as your hashtag or your pound sign depending on how older and hip you are is going to be a heading. And if I just type it here. It starts suggesting, Hey, do I want an H1 and H2 with three four or five, right? Or tags and I can just put that in and now I can start typing. Welcome bootcamp. Awesome. If I want to make a list. Or I can say, let's, let's skip the list. So I'm just paragraph text. Hey, how are you all finding the bootcamp? Great. I can add checkboxes with simple little dashes. And this is the power of, of Markdown. It's good. It's bad. Brooks looks funny. Okay. What? Oh, but we don't need your input on that one. We already know. Okay. So we can do these simple things. What if I want to quickly build a table name. Age. Hair color. Right. I can come down here. Some of you have written Markdown before. If you haven't, I just changed word processing for you completely. Okay. Okay. So I'm going to go back to my buddy. Um, 67. Hair color bald. Okay. Cool. I'm very quickly building a table. Um, Angel. Um, And why he's building that table. Let me point out something to everybody. This is a sort of low level thing that allows you to make quick comparisons between different versions of a file. Oh yeah. We'll dive into diffs tomorrow though. Oh yeah. Yeah. Yeah. It's just text. There's no funky stuff that we see inside word. No funky stuff that we see inside a Google document. That is their little control characters to make things work. It's just text and because so many organizations are embracing Markdown. As you can see right there, it renders out very nicely. Yeah. That's a really good point on like a Google doc. It would be really impossible for me to tell if you added a row to this table or added a column to this table. Um, And I think that when we get into the power of what's called a diff tomorrow, we could very easily see what changed about this table because it is just text. So you can do all sorts of stuff we could do. Um, Here is some code. I could say, I don't know. Sudo. Matt. Is awesome. Okay. And now this is like raw text. So I could actually copy and paste this into a terminal and I could do a little bit of a tasky encoding or new line endings that could screw up that. Um, I could even say, um, Here is some like informational text. Right. And it highlights it a little funny. It's a quote or I could do block quotes or I could say, Hey, like I want. Um, Jason actually will do Python. I can, I can specify a language like maybe I need to write code. And I can have this code block that has syntax highlighting. And notice that everybody it's actually rendering it exactly like say, if you were inside something like visual studio code. Uh, It gives you that look. And he's just done and look, all it was was three ticks to start at three ticks to end it, specify the language and you've got a really, really cool output. I can add subheadings. I can also say, Hey, like, I want this to be bold. So I can bold an individual word. I can italicize an individual word. Really funny. Right. So like, I'm not, it's, it is super sweet. Right. Thank you. That's so, uh, this is why I can't use word processors. You know how fast it was to do all of this. I would have to click all that silly UI. To actually in like format a file like this. And it's crazy. And look, I can go, Oh, I want just a break in the page. Yeah. It's, I can do so much fancy stuff to include. Um, Links really quick. Right. I could say. Do a reference link. Yeah. Matt's. Get hub. Right. And then a ctps colon slash, slash, get hub. And now if I gave this to somebody, they could just click that link in the Markdown and go to my GitHub. It's that simple. Yep. And the thing about it is also, other than, is a great hair color. Yeah. Brian got us on that when he sure did. Just two other things real quick. I want to point out. I think I can remember my second point. I'm a stall on the first one. I think I can remember. For those of you who are not familiar with, there's an ad. There's a application called pan doc P A N. D O C. When you start out with Markdown, you can easily take this thing into other formats. Like if you needed to take this and shoot it into a word file, because somebody's just got to have a dot doc X. You start with this. You run it through pan doc, pan doc can present that for you. Not only that. And to Matt's point about. Word processors and stuff like that. There's a lot of other extensions that we can take advantage of with Markdown. For example, being able to create slide presentations with something like this with a system like mermaid that Matt just showed me recently. We can create really cool slide presentations and they're text based. I challenge you to put together. A presentation and PowerPoint. I'm going to show you how to do that. You can quickly go through and find changes that somebody would have made when it's rendered in simple text like this. And you need to take it through a very contrived process where say somebody creates it. An editor double checks it. It has to go through legal to make sure the company can is okay with it going out. It has to go through a final process of upper level management saying it's cool. Doing that on changes is next to impossible. I've been there. Done that. It's not a pretty thing. This makes it easy. So this is something we're going to talk about. In a, in a following days, but this is a web hosted slide presentation. And it's ugly. And it's supposed to be. It was just a simple proof of concept. This was designed and built using Pandoc. Coupled with GitHub actions. And every one of these slides you see is actually just a Markdown file. So consider, I need to collaborate on a presentation. Have you ever needed to know what changed in a PowerPoint presentation? Well, with something like this, all of these slides, let me get back to it. Of course, it's going to be fickle to get back to it. Let me head back. The only downfall is how this is deployed is a little bit frustrating. Yeah. But I'll make, I'll, I'll, I will mitigate that by pointing out that, Hey, have you ever tried to collaborate on a PowerPoint file? Ain't going to happen. Ain't going to happen. It's a nightmare. Impossible. Right. So if I come back into that repository. I know it's very awesome named. And I look at this slides folder. You'll see slide one is a Markdown file. Welcome is a Markdown file. Slide with notes. This is simply a Markdown file. If I look at it. Here it is. Like these are the slides. And then I added like speaker notes to the slide. Yeah. With some Pandoc fanciness. Right. But all of this is built with an automated pipeline. And that's what's important. But nonetheless. So that's just another reason that that's in GitHub. That's my code. That's, that's Markdown. That's my code. So Markdown is super flexible to Brooks's point. If you come to like Google docs, you can. There's plugins that will let you write Markdown. And it'll render it over and do the formatting for you. We are going to take a small diversion. Right. And I said, we're not going to do code. It's not really code, but it's going to help us write documentation. We're going to take a small diversion. I'm posting a link in the description. And I'm going to put it in the description. We're going to take a small diversion. I'm posting a link in the chat right now. For that is not it. I just accidentally copied all kinds of crazy stuff. Also that pandas. Oh, I almost pasted you all of their badges. So this is a cheat sheet for how to write Markdown. And you don't have to do this in GitHub, but don't close this repo. I'm going to show you my favorite online Markdown editor. It's called hack MD.io. This is my favorite place to be. You can sign in with GitHub if you want, which is what I'm going to do. I have this all associated with my. GitHub account. I'm going to click this green new note button. And this is going to launch me into this really cool real time editor. Now there is a catch, a small catch to this. GitHub has its own Markdown editor. GitHub has its own Markdown language. It's based on the bigger Markdown standard. So most things work. Hack MD has its own Markdown language. So not everything I do in Hack MD will translate to GitHub. Everything I'm going to show you and everything that you have in that guide that I linked you will translate. I'm not going to show you the fancy hack MD stuff. So you don't have to worry about it there. But you'll see this can link right to repositories. I can push and pull. I could use this as my editor. We're not going to tie in that integration either. But Markdown kind of works like this. The aqua Thorpe favorite word word of the day. Also known as your hashtag or your pound sign, depending on how older and hip you are is going to be a heading. And if I just type it here. It starts suggesting, Hey, do I want an H1 and H2 with three or four or five, right? Or tags. And I can just put that in. And now I can start typing welcome boot camp. Awesome. If I want to make a list. Or I can say, let's, let's get the list. Some just paragraph text. Hey, how are you all finding the boot camp? Great. I can add checkboxes with simple little dashes. And this is the power of, of Markdown. It's good. It's bad. Brooks looks funny. Okay. Oh, but we don't need your input on that one. We already know. Okay. So we can do these simple things. What if I want to quickly build a table name. Age. Hair color. Right. I can come down here. Some of you have written Markdown before. If you haven't, I just changed word processing for you completely. Buddy. 67. Hair color bald. Okay. Cool. I'm very quickly building a table. Angel. And why he's building that table. Let me point out something to everybody. This is a sort of low level thing that allows you to make quick comparisons between different versions of a file. I'm just going to dive into this tomorrow though. Oh yeah, but I'm just, I'm setting you up here because you can see on the left, everything is just text. It's just, there's no funky stuff that we see inside word, no funky stuff that we see inside a Google document that is their little control characters to make things work. It's just text and because so many organizations are embracing Markdown, as you can see right there, it renders out very nicely. Yeah. That's a really good point on, on like a Google doc, it would be really impossible for me to tell if you added a row to this table or added a column to this table. When we get into the power of what's called a diff tomorrow, we could very easily see what changed about this table because it is just text. So you can do all sorts of stuff we could do. Here is some code. I could say, I don't know. That is awesome. Okay. And now this is like raw text. So I could actually copy and paste this into a terminal and I wouldn't have to worry about like asking coding or new line endings that could screw up that. I could even say here is some like informational text. Right. And it highlights it a little funny. It's a quote or I could do block quotes or I could say, hey, like I want Jason actually will do Python. I can, I can specify a language. Like maybe I need to write code even though this isn't about code. Maybe I need to write code and I can have this code block that has syntax highlighting. And notice that everybody it's actually rendering it exactly like say if you were inside something like visual studio code. It gives you that look. It is just done and look all it was was three ticks to start at three ticks to in it specified the language and you've got a really, really cool output. I can add subheadings. I can also say, hey, like I want this to be bold. So I can bold an individual word. I can italicize an individual word really funny. Right. So like I'm not it's it is super sweet. Right. Thank you. That's so this is why I can't use word processors. You know how fast it was to do all of this. I would have to click all that silly UI to actually in like format a file like this. It's crazy. And look, I can go, oh, I want just a break in the page. Yeah. It's I can do so much fancy stuff to include. Links really quick. Right. I could say I do a reference link. Yeah. Matt's github. Right. And then a ctps colon slash, slash github.com. Slash Matt Davis. 0351. And now if I gave this to somebody, they could just click that link in the markdown and go to my github. It's that simple. Yep. And the thing about it is also other than long as a great hair color. Yeah, Brian got us on that when he sure did. Just two other things real quick. I want to point out. I think I can remember my second point. I'm a stall on the first one. I remember for those of you who are not familiar with, there's an ad. There's a application called pan doc P A N D O C. When you start out with markdown, you can easily take this thing into other formats. Like if you needed to take this and shoot it into a word file, because somebody's just got to have a dot doc X. You start with this. You write it through pan doc. Pan doc can present that for you. Not only that. But you can also do that. You can also do that. So to Matt's point about word processors and stuff like that. There's a lot of other extensions that we can take advantage of with markdown. For example, being able to create slide presentations with something like this was with a system like mermaid that Matt just showed me recently. We can create really cool slide presentations and their text based. I challenge you to put together. A presentation and PowerPoint. You can do that. You can do that. You can do that. You can do that. You can do that. And find changes that somebody would have made when it's rendered in simple text like this. And you need to take it through a very contrived process where say somebody creates it. An editor double checks it. It has to go through legal to make sure the company can is okay with it going out. It has to go through a final process of upper level management saying it's cool. Doing that on changes is next to impossible. I've been there, done that. It's not a pretty thing. This is something we're going to talk about in a following days, but this is a web hosted slide presentation and it's ugly and it's supposed to be. It was just a simple proof of concept. This was designed and built using Pandoc coupled with GitHub actions and every one of these slides you see is actually just a markdown file. So consider I need to collaborate on a presentation. Have you ever needed to know what changed in a PowerPoint presentation? Well, with something like this, all of these slides, let me get back to it. Of course, it's going to be fickle to get back to it. Let me head back. The only downfall is how this is deployed is a little bit frustrating. Yeah, yeah. But I'll make, I'll mitigate that by pointing out that, Hey, have you ever tried to collaborate on a PowerPoint file and going to happen ain't going to happen. It's a nightmare. Impossible. Right. So if I come back into that repository, I know it's very awesome named and I look at the slides folder. You'll see slide one is a markdown file. Welcome is a markdown file slide with notes. This is simply a markdown file. If I look at it, here it is like these are the slides and then I added like speaker notes to the slide with some pan doc fanciness, right? But all of this is built with an automated pipeline. And that's what's important. But nonetheless, so that's just another reason that that's in GitHub. That's not code. That's, that's markdown. So markdown is super flexible to Brooks's point. If you come to like Google docs, you can, there's plugins that will let you write markdown and I'll render it over and do the formatting for you. So you've gotten marked down a little bit. So now I'm going to show you GitHub flavored markdown to a small degree. It's not any different. Everything that I wrote in hack and D would work over here on GitHub. All right. They just have a couple of tweaks that you can make and we're probably not going to dive too much into those, but I want to show you GitHub's markdown editor specifically. And I'm going to give you a task that you can do today. And I would genuinely put effort into it because it's like, you have to keep it, right? It's your, your account, your profile, your everything. So like, let's make it cool. So back into our repository. Where do we go for code? Code tab, right? We want to edit this. Read me. How do we do that? There's a little pencil and click that pencil. And here is our markdown, right? And there's some little ideas in here. So you'll notice this is a comment on line three to 17. It's a comment. If you know HTML, it's an HTML comment because markdown renders into HTML. So on hack MD, it's the same thing. Like it's just a comment and this doesn't show up, right? Like it's never going to render. Okay. Everybody see that it's the, it's the less than exclamation dash dash and then it ends with the dash dash greater than symbol and anything you put in there. Yeah. Bang in there. You'll see it. If you, if you click edit, you'll see the start of it on there it is. Yep. And the end on 16. What's cool about this is you can use these comments to say, I'm going to add objectives section or whatever section you might want to have. Right. And then maybe down here, I want to have another section for add skills section, right? You can whatever this becomes really helpful in your issues like your issue templates because we might include a comment that says attach a screenshot of the behavior or include a synopsis of the blog or whatever, right? Like you can give instructions and they don't render. So we have hi there. You can change that to whatever you want. But if we're going to make a change, like we're editing this file real time. I'm going to say edit me and I don't know what it looks like, but I want to see it, right? Because this is really cool. Like how can D like shows this to me right now. The GitHub does too. You just have to click this preview button. And now you can see the changes that exist. So in order to save these changes, because even though I change this file, if I just go back to the code tab, it's going to say, Hey, you made some changes. You sure you want to leave? No, I'm not sure. I want to, I want to make these changes or maybe I don't. So I hit cancel and it just takes me back. Maybe I screwed up editing the wrong file. I come all the way down here to the bottom and make a commit and you don't have to worry about what this is today. We're going to dive into all of this tomorrow. But I don't suggest doing this either. We're going to dive in the branches tomorrow. So I want you to commit directly to main this one time in this one time only. I want you to commit directly to main and you're going to hit commit changes and put in a description. Put in a, yeah, we'll dive into that. But if y'all want to do it as an optional jump in there. So now I have a new, a new read me. What's funny is it's not usable because again, get help flavor. Markdown says these little check boxes, like they're usable over here. Oh, if I can click properly, they're not usable in a read me, but they are usable in issues. Right. So like, Hey, issues take markdown, right? So we can do the same thing. I'm an issue. Uh, do, do, do task one. Task two, I hit preview. I can see what that's going to look like. I can update the comment and look, now we can check it off. And what's really cool is if you add these check boxes to an issue up here, it says like this issue has two tasks. So now if you're, if you're thinking project management, you're seeing like, Hey, you can use your, this issue is in progress and it has three out of five tasks complete. And it's assigned to this person and everything else. So the question is any opinion on using VS code for markdown work, I use it exclusively for markdown work, unless I am using hack MD. Most of the time I have a repository down on my local machine. And I use VS code for that. VS code will render markdown. It does it with no problem. Yeah. Let me, I think I can very quickly show you. Let me open VS code here. I might have some markdown. Okay. Cool. This is super secret markdown, but I can't seem to zoom in, but trust me. It's just slow. If I click this button here. It renders markdown just fine. Yeah. I know it's a little messy because it's my workspace and it's all weird and I didn't prep it for display. But you can render markdown just fine. Yeah. In VS code. On that, on that, on that point, Brian, yeah, I backed it up completely. I use VS code quite a bit because it's, it's easy to use. However, and this is not an endorsement. This is just a personal Brooks. Matter of fact, I'm going to cover up my INE thing right here just for a second. If you ever have somebody who's like, I want to do markdown, but I'm not interested in all that nerdyness y'all are doing. I can't recommend type or a TYP or a enough. It's a really simple application. You do have to pay for it. But for my experience, if you have folks that just don't want to do or learn how to do it. That's a great little lap. It does pretty good integration. It doesn't have integration, but the, the, the hashtagging it uses the control character it uses works really well with GitHub. So if you've got to go with something that's really just simple. They can just type away type or, but other than that, VS code is just fantastic. And oh, by the way, like so many things we're seeing here. Absolutely free. It's just a great code. Awesome free. And then. Yeah. Like VS code is what I would typically use. But again, I wanted to keep this in the web, right? Like the whole point was I didn't want you to have VS code. I didn't want you to set it up. I want to show you how to do this with the web. Now, since you're asking about VS code, I'm going to show you something cool. I'm going to throw you a bone. I'm going to throw you a bone. Okay. What are you going to do? VS code has an online editor. Guess who owns VS code. Uh, Microsoft Microsoft. Oh, shoot. Guess who owns GitHub. Ah, Microsoft. So it's almost like there's probably a feature. That allows me to do this. So if I click this Markdown file and I see it here. And I press the period on my keyboard. What? I just pressed the period. I didn't do anything fancy. I just pressed the period key. He just pressed the period key. It just launched. An online VS code editor for me for my Markdown. It does have a terminal. I think I never use this. I just know it exists. So bear with me. Yep. Brian, that was slick. That is a very slick feature. I think there's a terminal somewhere. There is dude. I forget where it is, but you can launch it. You can go through your entire get flow process right here in this. So you can, if you use it, you're used to get, and you know, get, you can get ad, get commit, get push, all of that. And it goes right back into the repository. So now caveat. I don't know if this is the pro feature or not. I know when this was being developed, it was only available to enterprise people under the, the code name of code spaces. So code spaces would let you like spin up these editors for specific repos. I saw a post on LinkedIn that said, if I did this, that this feature was it was now in existence. So if you can't do it, it could be a pro account thing, but it opens the exact file right there. There's got to be a terminal somewhere. View. It's there somewhere. There it is. It was there. Terminal got it. Right. So, okay. So terminals are not available in the web editor, but if you're used to this code using the, the visual commit thing. Cool. It works fine. I'm just free. If you're using the visual commit, you can create your pull requests and add your commits here. But again, please don't let that bog you down. Don't also let me stop you from playing and experimenting, but you can also just edit like this, right? What you can't do that for is issues, right? If you're creating an issue, you can't open VS code for an issue. Won't work. So that's the downfall, but there is that built in editor. So it's really cool, right? If I'm a developer or I'm scratch that, if I'm an employee and I have access to a repo and my company doesn't want that code to live locally on my machine, because maybe it's a government thing or a highly regulated industry. Yep. It doesn't have to. I can still leverage all of that and you VS code savvy people. I'll tell you this. If you're familiar with dev containers, some of you dev ops people might be like dev containers inside of VS code. I can add a dev container file to a repo. And then when I press the period key, I get all of the desired extensions and VS code configuration that I want. So again, y'all, that was nothing but hitting the period key. Yeah. That was something you would just never know. Like, I guess you got to be on the inside to know that. That's the best insider info. Again, y'all, that's, that's what I was saying. This is why I was so excited to have Matt teach you all this because this is that insider stuff that just doesn't show up. And to be honest with you, after Matt showed this to me, I did some searching. I don't see a lot of people who even know about that trick. Yeah. So glad I didn't accidentally. I've been so confused. Yeah, exactly. Right. It's weird. It's weird. There's a lot of weird shortcuts. A lot of them have been disabled for me at this point. Like the staff's view of this, like I could see all sorts of stuff by just, I could toggle my view from staff to, to regular user. Here's another super fancy thing I didn't cover. We'll cover it a little later. Yeah. Yeah. Yeah. I'm sorry. If I come into here and I type slash. They're not enabled. You can also do some slash commands right in issues and pull requests and stuff like that. That might be an organization thing though, but there's a lot of like little bitty hidden features that kind of exist. All over GitHub. Which is kind of cool, but that's one of them. So you've asked code people, you really want to use it. And you can do that. You can do this. You can use it. You can put this stuff over, but like what doesn't render is like Hack and D lets you do this. I could say info. This is info. And it does this really cool thing. And it puts this green box around it. But if I take that over to GitHub. This is where these things differ. And I try to preview that. It doesn't, it doesn't preview it. So there is a little bit of. I don't know what you're talking about here, which is like, I know Brooks throughout his, his recommendation for that type of stuff, but you have to look out for the differences in how GitHub is going to, going to render that. Here's another, I'll leave you with one last super cool thing before I give you your final piece. Let's say I have a link to sketch pad. Nope. This is a good one. Yeah. This is a good one. Y'all watch this trick. Actually. I don't know how to. We're going to do a super safe Google search. Okay. We're going to search for cats. If you're afraid of cats, close your eyes. I'm going to hit right click on this cat photo and I'm going to copy the link. It's all I'm going to do is I'm going to copy the link and I'm going to not put it in my read me. I guess I will screw it. It'll be fun. I'm just going to come into my read me and I'm just going to paste it. Boom. And GitHub. Should. Oh, why don't you do it? Is it only issues? It could only be issues. Yeah. I think it's issues, dude. So if I do that in an issue, because like maybe I took a screenshot of the problem. Right. And I paste that. Oh, does it have to be a picture picture? Let's see. Yeah. Well, you've got the link unless it's doing a preview type thing. Save image as we'll just save it. Yeah. I know I had the link. It's being finicky. You can. Yeah. I'm going to take these and put them in. It'll create a permanent link. So I'm going to copy the picture. Notice how I copied the JPEG, not the link. And now I paste that in. That's going to give you your absolute. Yeah. Yeah. You can, I promise you that you can take pictures and paste them directly and without building, you don't have to build the markdown link. Right. And it will create like a permalink. And it'll like upload it to GitHub and it'll give you this crazy URL and it'll always be there for you. They store them indefinitely. So you can just have pictures show up. For example, if I come back into that, that one little pandas thing that I have here. We find it. We were just there. We were just there. We'll come to my orgs. That's how the picture got there for that pandas thing. I showed you earlier. So if I come in here and I look up pandas. Like this picture, if I click edit, you'll see that. Oh, she actually never mind. She resized it. So there's a trick is she, she wrote a little HTML. So here's another pro tip. You can write HTML inside of Markdown. So she wrote some HTML so that she could specify some attributes to this picture, but most of the time you can just paste the picture directly in. So like if you had a gift, you could paste that gift in or whatever it might be. And it will create a permanent link for you. I don't know why it's making me look foolish. I guess I got away with too much today that didn't backfire on me. So it had to throw one my way. Yeah. So that's last little bits of pro tips. So what we're going to leave you with and it's in. I gave you the guide from Markdown. Okay. I, if you were to look in this, this read me originally, it had some ideas in the comments. I asked you to Google up some cool read me profile, read me ideas. I want you to just take some time and write some Markdown, just so you can get used to it. Take some time, write some Markdown and commit it to your, your profile, read me. Okay. That's it. Just, just commit it here so that when we view your profile, we can see what you did. And if you do something really cool, we're going to, we're going to ask a couple of you to like share them with us tomorrow because we want to see them. Absolutely. Okay. So why this is important, not just is it great to like build your GitHub footprint. But if you want to participate in doing some of this non code related automation stuff that we're going to do, it's going to take place against this read me. So it's really important that you do have that set up and configured. So I'm going to leave the remaining time for you guys to ask questions about what we covered thus far. I know we didn't get into like get flow and all of that. That's coming tomorrow. There's a lot of schedule people. All of that's coming. So if you have questions about features or accounts or whatever it might be, the floor is now yours. Go ahead, type them up, ask us our questions. And if you don't have questions, we will see you tomorrow at the same time, at the same place to continue this. And be sure if you didn't do it today, create that GitHub account. Please get that thing set up. Jump in there. Follow the instructions about creating a repo that's named after your handle and create that read me file before we go for any of you because I don't want to know what's going to disappear. Grab the link, the one to the markdown.org or slash cheat that sheet. Grab that link right now while you have a moment. Put it into a web browser tab. So you've got it so that you can work on this again. This is going to be like, I love the way you said it, Matt. This is your footprint. This is the first footprint into GitHub. So spend a little time with it. Fancy it up. Put some of your capabilities in there. Some of the things you've worked on, put something in there you can show off in tomorrow. If you want to, we'll ask you to post up your GitHub URL and we'll throw it to the screen so everybody can see it. So do something fancy. Good morning. Good morning. Good morning, everybody. Welcome back to day two or welcome to day two of GitHub for everyone. I hope everybody had a great evening. I hope everything went well for you. I know there's a lot of stuff going on in the world. A lot of concerns about things, but I'm hoping for the next few hours we can focus, get right down to business and learn more about GitHub with Matt. Just to give you a little idea of what we're going to be doing today. We're going to be talking about collaborating. Matt's going to talk to us about get flow. This is not a little thing. It's pretty cool. And then beyond that, if we have time, one of the things I'm really excited that we're going to have the opportunity to get to is going to be actions. And this is something that Matt knows quite a bit about taught me quite a bit about, but that's something that's going to be really cool to share it with all of you. But before we get started, hopefully all of you had an opportunity to do some homework. And that is create your GitHub account. If you didn't do it yesterday and set up that special repo that Matt showed us where we set up that read me. If you have done that. And if you don't mind sharing, by the way, feel free to share. Let's see that posted your URL over in the QA. And let's all take a look at what you've done. Yeah, let's see those profiles. Put a couple in chat. I'm really curious. I'm super excited to see what you guys. In particular, there's one, there's one person in the room that I do want to call out. And I don't want to embarrass anybody, but their initials are Matt B. What happened was is I had Matt B's window open from yesterday. I had. Yes, exactly. I had tea in my mouth. I look over and Matt's updated his with a picture of general Kenobi. So I see, oh, I see. Hello there. Hello there and spent on my freaking monitor. So thanks, Matt. Appreciate that. No, it was really that. Yes. Yes. Matt mission accomplished. No, it was really good, Matt. That was well done. I really like what you did there. So for any of you, if you would like to go ahead, drop in there into the. Drop into the Q and a drop your URLs in there. You can drop it into the chat, into the chat. What a knucklehead. Drop it into the chat, especially you, Matt. There we go. Everybody, there's Matt. If you want to jump in and take a look at what he, Matt did. Very well done, Matt. Very well done. If anybody else has one that they'd like to pop in there, go right ahead. There we go. Gravy. Awesome. Oh, interesting. Look at that question for you on these links. Did you manually put these in here one by one? This looks very similar to something that I have in mind, which is why I'm asking. Very cool. Okay, cool. Yeah. Okay. So you used the markdown. So you did, you manually typed them in. Cool. Yeah. So the other thing on links, haha. Funny, funny plot twist. Yesterday I was bragging about the fact that you could just copy and paste pictures and things. And it broke on me, right? If you guys remember, right? If you don't copy the link, you're going to copy the image. As soon as you guys left, it worked just fine. So I'll give you that example really quick. And then we'll check out this other profile that just got posted. Right click on it. You don't want to copy the link. You're going to copy the image. So if I copy the image, I can then put it in the middle of like an issue. So if I, if we delete this and I hit paste, I'm going to copy this really strange URL. So it permalinked it. And now I have that picture right here as a part of my comment. And all I did was, was copy and paste. So that's like super convenient in a really easy way to just be, I guess a little more visual with your, your issue writing and your markdown usage. If you're on like hack and D it does the same thing. It just uploads it to imager rather than, than GitHub. But the advantage of doing it on GitHub is it. It uploads it to the GitHub servers and it's not going to go anywhere. Exactly. Exactly. Got a question. When we get, when will we get the recorded sessions? Adam, I don't know if you're there, sir. If you even want to speak to us. Is there a timetable for publishing a, the cleaned up version of this. Yeah, typically it takes the production team about a week. Two weeks at most to get this course. And then you can edit it down and kind of put into a way that can be ingested on the platform. So usually about a week or two weeks at, at the most. Yup. So yeah, if you come back on the platform, Baron week two weeks, you should see it out there. I didn't even cleaned up a little bit with some of our nonsense gone. All right, we got an initial profile here, which is good. You got it set up and that's, that's honestly what the important part was, was making sure that you have it. So. This is great. This is great. See, this is, this is where you kick it in. This is where you start it. Y'all, this is, this is good stuff. So yeah. So even though if, if you haven't done it, or you just didn't want to share a URL, if you're getting to this place right here where you're just getting it set up. Good job, y'all. Very, very good. So these are really cool, right? Because they're, they're profile landing pages in like, I'm not connected to Matt at all on GitHub, but by just landing on his profile, I can guess a few things about him because of this read me. Right. I can look at the fact that maybe in a past life or in an alternate universe or some string theory situation, he can hook me up with Luke Skywalker, right? So maybe that possibility exists. I can also see some of the stuff that he's into. It's, it's mostly about me and Mark down, but that's fine. I'd be into me too. It's a, it's a map thing. I'm guessing. So I can see stuff about him, which is really cool. And this starts to highlight a social feature of GitHub, which I don't typically highlight. And it's this followers and following section. Okay. Just like Twitter or LinkedIn, you can use GitHub as a social platform as well. You'll see Matt's following five people and he's got 47 followers. He must be up to something interesting. If so many people find him interesting, right? And you can just click this follow button and you will then have like that feed and that feed shows up for you. I forget exactly where I think it's just here at the base GitHub screen. Like there's like this feed. I can see everybody that's, that's followed me. I should be able to see some of the stuff that, that you guys are doing. So you can see like who is starring your repositories. You can see who's cloning and far who's forking. I'm pretty sure you can see forks. There's a whole lot of stuff that, that you can see from the social aspect, right? So don't hesitate to take two seconds, go to each other's profiles or find projects and people that are contributing to projects that you care about and follow them because you can start using this as a little bit of a professional profile too. And if some of you were like network engineers or dev ops engineers that were kind of focusing on networking, it'd be really awesome. If you guys networked on GitHub, because you probably had to have a lot of overlap that you can share with one another on the types of infrastructure code files you're using in stuff like that. So maybe you have super fancy scripts that, that you've worked with that would benefit somebody. It's a really good place for that. And it's also one of those things where employers might check in the sense of, I see a lot on job applications nowadays. It says, what's your GitHub? You put in your GitHub handle. I go to your profile. I see who you're following. All right. And then based on who you're following. Let's go back based on who you're following. Like I can, maybe one of these people happens to be one of the references that you've listed. I can then click on their stuff. I can just kind of go down the rabbit hole, get a little creepy and research you more than I should. But it gives employers that, that visibility. So very similar to LinkedIn, except instead of saying, Hey, I worked on Terraform templates to stand up network infrastructure. I can actually go see some of the templates that you've worked with and I can see what you've been doing. I can tell how you're writing your, your files and stuff, right? I can also see interesting stuff. Just, I used to do this when I had to, to give interviews when I was an interviewer at GitHub. I would check to see if you had a GitHub account, which oddly enough, it's not a requirement for hiring. But if you did, I would come look at things like your, your contribution graph. Right. Just because I have 1100 contributions in a year, like what are they? Are they contributions to documentation? But if you're telling me that you're really good at Ansible playbooks and you have zero Ansible contributions in your GitHub, I'm probably going to have different questions for you when we talk. Whereas if you tell me that you've used Ansible for two or three years and I come to your GitHub account and I can see that your contributions are in the form of Ansible related things, then we don't have to dig as deep into that topic in the interview because you've already answered most of the questions that I have. And now I can just maybe focus on you a little bit. So you can use this so much to your advantage by, by just kind of getting through some of the technical hoopla that goes on in interviews by, by giving it to your interviewers up front. And isn't that one of the strange things about GitHub Matt is because everybody thinks of it as just some sort of, you know, version control system. When in actuality, if you start looking at things like, here's like what Matt has, you know, this becomes like really an online resume of my work, what I've done, what is out there, like here's a, here's a Lola's. You know, just you can dig in, see what she's been doing, what she's been working on. It's like it really adds some heft to your resume, to the hiring process and can be something that, and this is just me personally, I think it really sets you apart. Yeah, see, like this is, this is a great example. I'm glad this, this got posted. But I see this, I see there's 44 repos. I see that you are engaging in a community, even though your account seems to be new ish, which is okay. And I can very quickly look at what you've done. And what I see is a ton of stuff from, from try hack me. So what that tells me is like, you're an active learner and you can do things in a self-guided manner. Right. And now we get to talk about like, I, maybe I didn't know anything about try hack me. And I was interviewing you, I could go to try to hack me and pull up things that match this, just to see what tasks you did. So now I can have that conversation with you. So this shows so much about you and your personality. By just doing these and right, like this is a write up and, and this is a write up. So it looks like you've done the write ups, which is great. Or you're starting the write ups. I don't want to dig too much in here and expose you, but they're, they're public for a reason, right? So no, that's great. Tons of markdown is huge. It shows that you're taking notes. I've learned so much about you from just looking at how you keep organized. And I haven't had to ask you a single question. So it's, it's super cool to be able to do that. Um, and I can also see where you worked, right? So there's so many things that we can tie in. I can see what organizations you're a part of. Right. Maybe try hack me has a GitHub organization. I don't, I don't remember if they do. It's been a long time since I used that platform, but like I know, like when I was self teaching myself how to program, there were a couple like bootcamp kind of course things that I entered and they all had GitHub orgs. So if you go look at like my org membership, I think one of them was like learn Co. When I was learning Swift and that's on there. So there's a lot of cool stuff that you can do. Uh, Or that I can get about you and learn about you without ever having talked to you, which is so cool. And I can just see what your network is. And I can also see like who you, like the things you like, you know, like what have you starred? I'm very curious, you know, like I can see so much about who you are. So I can see that you're plugged in with, with certain things in this security domain. And that's super, super helpful for me. So as much as LinkedIn is a great hiring tool, I don't think many cats anymore. I don't know about you guys, but I think we're done with them as much as LinkedIn is a great hiring tool from a recruiter's perspective. GitHub becomes a really big insightful tool from the interviewer's perspective, especially like once you get into that, I'm going to meet with the team kind of level of things. Like I don't want to have a conversation with somebody about, you know, tell me a time when you wrote a Terraform script or whatever, like that's boring, like show me one that you've written. Or I've already seen enough of them. So like, let's talk about, you know, what you found challenging in one of them or let's talk about like why you did that weird thing, because I want to know how you think and maybe you solved a problem that I didn't know existed. And we can just talk like people a whole lot easier. If I've already seen your work, I don't have to do the whole coding challenge. Here's leak code 2.0 for you. So very cool. Super beneficial. I encourage you to everybody that's posting their GitHub handles. Hopefully there's more, right? I think Lola was the last one that we got in the chat. That's cool though. Yeah, follow each other. Yeah, absolutely. And again, if you haven't done this, do it, get started. It's one of those things, y'all. I would rather if I was doing, you know, mentoring advice to you about careers and stuff like that, get ahead of the curb on this one, because this is becoming very much a standard and major organizations, AWS, Microsoft, Google, any big place like that. It's pretty common to go, okay, does this person have a GitHub page? Let's go look or better yet on your resume, or maybe on your LinkedIn profile, you've got your URL sitting there. So we can just go out and just take a look at it. It can be, it can make a big difference in terms of your market ability to be. So again, take a moment sometime, make a little bit, put a little bit of effort into it. It's worth it. It really is worth it. And I'm going to piggyback on this corporate jargon one-on-one to drive home and or highlight another feature. Okay. So we have the user account name, and then we have the repo name. And what we learned yesterday that is that if it's the same, if the repo name is that of our GitHub handle, it's a special repo, right? And it gives us that public profile. There's another special repo. There's like another secret repo that exists. That's kind of cool. Let me show it to you. If it loads. So where, oh, where are you? Should be easy to find. Should be in repos, right? Exactly. And it's also similar to my name. And you'll see this. It's my handle.github.io. This is a special repo that allows me to deploy static web pages using GitHub. So yesterday I showed you that really ugly slide show that was all built with Markdown. That was, uh, that was all hosted on GitHub. And to this point, all of this code is hosted on GitHub. And I use this to demo. Like how like you could use GitHub to set up your portfolio. Right. I know I mentioned my mentor a lot of like web dev kits. So I throw this in here because I try to teach them. GitHub. And then I say, Hey, like, you know, you're learning web development, create your pro, your portfolio now. And, and just deploy it out on GitHub. Don't worry about how to deploy to AWS. Don't worry about how to use Heroku. Don't just put it in GitHub and let GitHub deploy it. So what's really cool is there's this feature called pages. And GitHub pages is really good at deploying static. That's the key here. Static web pages. Nothing server side. So if you're running a PHP server, you're running go as you should be, you're running a Node.js express server. It's not going to work. It has to all be client side static web pages, but GitHub can deploy it. And what's cool is it can deploy it in a couple of different ways. What you saw yesterday was Markdown. Those slides, those were all Markdown files, not a, not a single bit of JavaScript, not a single bit of HTML or anything like that. In this case, it's HTML, it's JavaScript. It's a little bit of CSS and it gets all deployed out on, on GitHub pages. It's really easy to enable. And there's a reason why I use this, this repo name and we'll get to that. It's really easy to enable. If you go into the settings and you come down to pages, you'll see, here you go. You'll see pages designed to host your personal organization or project pages from a GitHub repository. But what you'll notice is my URL. Some of you guys are freaking out because it's HTTP and not HTTPS, but that's okay. I'll have for this. You'll notice that my URL is not a GitHub URL. It's a domain that I own. So you might have caught that back here with this C name record that exists. But as long as I just set up a little text file called C name, GitHub understands how to go look at the domains that I have registered, there's like a little setup thing for it. And I can change the domain. So it would be github.com slash Matt Davis 0351.github.io. It would be a really jumbled crazy URL and that's okay too. It still works. But if you want to tie in your own to make something professional or a portfolio, you absolutely can. So this is typically used for a couple of things like hosting that portfolio or a personal site. Or things like documentation and slide shows. So it's very simple. You come down here and you pick a source on like where you want it deployed from, and then you pick whether you want it to be deployed from the root folder or a docs folder and you hit save. And that's all you have to do. And it will, it will publish this. And now when I go to it, I have a statically deployed. Nothing website at the moment to just show that there is, you know, all these little bubbles that are moving. I don't know how well they're rendering. Like that's just JavaScript running on the back end. So it does run JavaScript in your browser. It does do all the fancy CSS hover stuff that you could want. You can do it really, really fancy and do this and like react. If you really wanted to, you just can't make any server side calls. Right. So to the point of I am interviewing you or I'm an employer. If I notice that you have that really special repository. Get hub.io your name. Get hub.io. I'm going to go take a look at this page. And once I have this set up, I can do this for any repo. So if I come back in here and we're going to go ahead and I'm just going to create a brand new repo to show you how fast it is. It does support SSL. Yes. You can enforce HTTPS. It's in this. It's in the setting. I just didn't go through that trouble because I didn't let that was a one extra thing that I didn't want to burden on somebody that's never written a line of HTML. I'll post up the page for Brian right there in the chat. Cool. Thank you. Yep. So I'll show you how fast it is to enable this. And I have very frequently used this for documentation along the way. So at a read me. So if I'm documenting my project or I've done like I've created a lot of manuals like training manuals for things and deployed them out through GitHub pages. So I'm going to show you something called Docsify. Yes. I'll put that in chat. In case you're interested. Docsify. Yes. Is really easy and fast to set up as GitHub pages and it gives you. I can show it to you here. Actually. Docsify. Uses their own thing to do their docs. Right. So this is what it looks like you hit get started and you have to get started with the table of contents code snippets and what's cool is every one of these pages is marked down so you can write this exact same documentation for your project or your scripts or whatever you're doing using something like Docsify and you can deploy it right alongside the code. Yep. So here's the new repo that I created. Sorry to jump around a little there. Here's the new repo. It doesn't have anything deployed out. I'm going to go to settings. I'm going to click on pages. You'll see it's it's not enabled. I'm going to say do it from the main branch root folder. And now I'm going to come in here and I'm going to say choose a theme because I don't want to write any code. It's just not what I'm after. And I'm going to go ahead and I can browse the themes. They look a little like this one looks a little like this. Let's see what this one is. This one's kind of boring. We don't want that one. Oh, Merlo's a good one, man. No, no, no. Chardonnay's better. So here we go. That's not like any of these. Okay, cool. This one's a little more documentation like, right? Yep. I'm going to go ahead and I'm going to hit select. It's going to update a new markdown for a file in the root of my repo called index. So index MD not HTML, not JS, not whatever MD markdown our friend, right? If we look at it. This is what it looks like. It just looks like normal markdown. If it renders through GitHub. We can commit that. Oh, it wants to take it off of there. Okay. It has decided that it wants to by default, GitHub has said you should deploy this from this GH pages branch. And we'll talk about branches in a minute. Trust me. This is so that you can keep your code a little bit separate. How dare you. This is so you can keep your code a little bit separate from the documentation that's deployed out. You'll notice on this branch, there is no. Index MD, but on this branch, there is. So we have to change our settings. And we're going to say, don't deploy. Oh, it did it for us. How about that? So it's, it's being published right now. It says it's ready. It might be ready. Sometimes it takes a little bit of time. But what you'll notice is it automatically put in my domain name. And then it routed to what's in this repo. So this is because I have that other special repo over here set up. If I didn't have this, I like, if I deleted this repo, I get some jumbled mess of a URL. Which is totally just fine. If I don't intend to point anybody to it, because I can always get this link from the settings. But like if I wanted to show off that this is my portfolio, or if I wanted to use this as like an interview piece, I don't want you to have to. You know, click on randomly generated link names. So we'll go ahead and click it and look that fast. We have. Our site deployed out. It's static. If we want to edit it, it's really easy. It couldn't be easier to edit. You guys have already learned a little mark about markdown. So if we come into here. And we edit this instead of saying welcome to get a pages. We're going to say get hub. Or everyone. That's the only change we're going to make. We'll commit that. And it's going to go ahead and deploy that out. And I'm showing you this because there's a very weird thing that happens with pages. And if you don't know it, you're going to think it's broken half the time. So it's still loaded this. That's weird, right? Get up pages, leverages your browser's cash. And it will store its initial state. Forever. And you're never going to be able to get this thing. To reload. Not the way you expect it to. What we end up doing is we open up. The inspector on a page. And then you should be able to. Oh, can you not do it on Firefox on Chrome? You can. Right click this and it'll say like hard reload. And that's like the best way to get that cash all cleared out. I don't use Firefox typically. So I have no clue what I'm doing over here. They say for you for, for, for, for y'all just to anybody use, you want to clear your cash, do a hard reload on it. And it'll pick it up. Exactly. If you're on Chrome, it's really simple. Open up the inspector, right click this and then hit like. Do it. I think it says perform a hard reload and it will clear the cash. Yep. Control. Control shift R. There we go. Thank you. What up? Not a Firefox user. I don't know if that works on Chrome or whatever, but you see, so once the cash is cleared, it updates. So. Why is that important? It's kind of is like, if I am building documentation that maybe I'm pointing developers to, let's, let's pretend for a minute that I'm developing. A development kit, like a library or module for Python or a package for NPM or for node. And I would want my developers to know how to use it. I could also be writing the markdown documentation up to the side, and I can host the docs for my package right alongside the package all from the same repo. Maybe I am doing job postings. I don't know that I would put that out here. But again, like training manuals, things that I want people to see because here's the kicker. This is Publix. 100% of the time. Unless you're like on enterprise. So let me backtrack a little bit. If you're on enterprise and you're doing. Super internal stuff. You can have private pages for me and you on regular user accounts, even in organization accounts. The pages part is public, even if the repo is private. So that's cool too, though, because I can have a private, I can have a private, so that's cool too, though, because I can have a private repository that nobody can see, but pages is public, and they can see what I've deployed out publicly. So this is a really simple, easy way to get clean, crisp, good-looking docs up and running right alongside your project with zero effort or host a portfolio or, or something. So this is another thing that I kind of look for. If I happen to see that special repo, which this one is not, right? I will go look for that. And what's cool is it just kind of gets your whole URL. So. So at this point you base it was, we basically have is like a free static hosting website that we have complete control over. It's not being, you know, it's not where you've got to worry about, you know, a social media type thing. You own this. And the other thing I hope you all noticed was that it really just, well, other than the fact that we didn't do DNS, we didn't have to do a CNAME entry into a DNS system. We just created a file also because Matt set his, his, you know, base page that, that IO page. Now you'll notice how curly fiesta is now like hierarchically up under it. So without us even have to do any thinking. We're just automatically getting a hierarchy of files, pages, projects that just start getting built out. And it was easy to do. It was simple. I mean, this morning Matt is, for example, I was sitting there fighting my freaking S3 bucket static pages. And it's just, it drives me nuts. As much as I know about AWS, it still drives me nuts because I keep thinking something's going to happen. I'm going to get a huge charge because people are going to start pulling stuff out of the bucket. It goes out of region. It starts blowing up. I've got to work the DNS. Whereas I hope everybody saw right here. That was, that was, it didn't take any brain work. That's just easy. I want you to pass. Got a question. Please repeat the format of the special repo. Yep. Sure thing. I will show it to you again. And that really only applies if you want to do a custom domain. Right. So keep that in mind too. It is. So it's your username. Dot, GitHub. And that will allow you. So that'll be like your default root route. So let's, let's think of a CTP routing a little bit. The root route will always point towards this repo, your username dot GitHub.io to Brooks's point. If you deploy pages from another repo, it becomes a route. So if I deployed pages from oranges, it would be. Matt Davis 0351.github.io slash oranges. This is what the URL becomes. If I remember right. It's been a long time because I've had DNS set up forever on it. I think it goes with this as your URL by default. GitHub.io. Yeah, it does. So that still doesn't look bad. Maybe you don't want to go like you're a student or something. I don't know. And you don't want to go buy a domain or maybe you have no idea how to buy a domain or, or whatever. That's not a barrier to entry, right? Whereas like if I wanted to deploy my web project portfolio thing somewhere, I have to figure out where to deploy it, how to deploy it. I don't know any of that. All right. I'm learning how to code for the first time or maybe I just need docs. I don't want to go through all of those hoops just for some documentation on something. Well, this URL is not a bad thing to have. You can just make it a little more custom. And then each repo that you deploy pages becomes a route. So it's kind of cool. By the way, y'all, you'll notice that that when Matt brought that up for us, that page, those formatting, that was using Jekyll, J-E-K-Y-L-L. So that gives you some really cool formatting, but that's not the only one. If like, I'm a big fan of Hugo, H-U-G-O. With Hugo, I could do the same thing. And with just literally just a few commands on my personal laptop, I could run up a new site. Then when I'm all done, I just push it up to the repo. Boom. It's up and running. And it's so simple. And when you start talking about GitFlow here just a bit, you'll see why when we start talking about GitFlow and updating web pages, it just gets simple when you start doing stuff like this. Yep. So fun fact. Inside info. Here you go. Inside info alerts. Cool. Breaking news. GitHub originally was built on Ruby on Rails. So that's, there's still a lot of features that are Ruby on the back end, which is why Jekyll in core, like is something that we can use so easily, right? So Jekyll is a Ruby ecosystem thing. So you can use Jekyll. And then it's a browser. So you can use things, JavaScript. So Doxify is another super good advantage or like library thing to use. I've always used the Doxify one over Jekyll just because that's where I'm more comfortable. But I've worked with teams that use the Jekyll one all the time. There was a couple others. I forget them off the top of my head that I used. And then honestly, if you don't want to use any fancy stuff, because maybe you just want to do it, like here is just an index HTML. This is the exact loremipsum that you guys saw on that portfolio. You can just create the static website. Like here's the CSS for it. Like it's not like I did anything magical. Right. It's just a little bit of web stuff. Exactly. But if you're not a developer, if you don't write code, if you want to stay away from that and you still need nice looking stuff, Jekyll, Doxify, Hugo, other libraries exist for you. Exactly. You know, and going back to y'all to what we said, you know, this is not just for developers. This is for everyone. So if you're just putting together a collection of documents about your company, say you're hiring process or something like that. You set up a repo. You can do this just as easily there. Create a nice web page. And then when people start saying, well, I need to go look at it and see what's out there. You don't even have to send them to the GitHub repo where they might be initially a little concerned because they don't like they've got the skills to understand GitHub. Send them to the pretty page. Exactly. Exactly. Yep. And you'll notice this is private, but we could still see the page. You guys can't see the repo. You can't make edits on the repo, but you could see the page. So you could have sensitive stuff in the repo. And then have. Not sensitive. Publicly publishable stuff on the GitHub pages. So you totally do that. And it's just fine. You can do that. You can do that. So you totally do that. And it's just fine. Interesting things to think about. Another cool feature that I feel like was going to get overlooked. If we didn't take a little bit of a time on it. Okay. Questions, comments, concerns going once going twice. Little bonus material, everybody. Just a little bonus material. Yeah. Who's asleep. Raise your hand if you're sleeping. All right. Yes. We're going to jump in now into collaborating within a repository. I encourage you to follow along. Yep. If you follow along though, I will preface this by saying. Choose a different repo name. And the reason for that is. The repository that we're about to create and work within is going to be the one that you get to take with you. So if you already have a repository named hot dog flavored water. And all of a sudden you try to take my hot dog flavored water. It's not going to work because you already have something with that name. So name it something completely different from, from what I'm going to name it. If you want to follow along, which I encourage, right? This is another way to build that contribution graph. And the other way to network using GitHub is a social tool rather than strictly a code management tool. Hopefully that for everybody piece is really starting to hit home. So I know this, this might be a little boring at this point because you've seen me create four or five different repositories, but repetitions keys. We're going to create a new repository. And GitHub and my internet is being a tad bit slow right now. So it's, it'll load when it loads. I am, ooh, we could talk about templates. We'll get to it. Yeah. Okay. So this repository is going to be called GitHub for everyone. Weird, very creative name. Whoever came up with that is a genius. And I'm just going to add a description because we didn't have it before and I want to show you where it shows up. So I'm going to say this is a repo to hold class files and notes for students or attendees rather spelling everything wrong. Tendies to take with them after they give me 12 hours of their lives. That's fair. Cool. I'm going to say public and I'm going to say add and read me. Why? Because we always add or read me. This is what we do. Okay. And I'm not going to add a getting more. I'm not going to add a license at this point in time. I guess we could let's add a license. I don't actually know because I don't know what I need license structure is. So we'll skip that. I was going to throw in my key, but whatever, just skip it, man. We don't want this. Cool. Fine. Cool. Create repository. Boom. Boom. Boom. Boom. Boom. Boom. Hey, see where the description populated? What up? It's also over here in the about section. Yeah. You're not going to see that poll request badge thing there. That is a GitHub app that I have installed on my account. Remember yesterday I showed you guys the question level. It's a wonderful question. It's a great market place. I think it's called poll request badge. As a matter of fact. Yeah. It's right here. So this app is what I have. See edit my plan. I'm already, I have it there. So this is installed on my account, which is why I see that option. You're not going to see that unless you have it installed on yours. Look how expensive it is though. Oh my. Woo. Pages is really expensive too. Super duper expensive. It's also free. So still no catch yet. Or not much of a catch at least. All right. So we have GitHub for everyone. And now we're going to start talking really about the collaboration behind this. And to do that, Brooks and I are going to behave as if we're working on a project. The real joke there is that Brooks and I are going to behave, but we're going to behave like we're working on a project to make this repost something better than, than this read me. And the task that we have that we're going to solve today is we're going to build a contributing document. So there's this special document for GitHub. It's not special in any sense other than what it's named and where it lives. It lives in a folder that's called dot GitHub. This is a hidden folder. So it's dot GitHub. You'll see us create it. So don't stress about writing it down. And inside of there, it's called contributing.md. And like read me is all capitalized. We write it in all capital letters. It's just standard practice for this. The contributing md. Is a guide. It's a set of rules. And recommendations. That change for every single project out there. And they basically inform people who want to contribute. How to do so. So let's take a quick look to see if we can find one really quick. We'll go back to my, my handy dandy pandas repo. This is a fairly standard practice across the ecosystem. Isn't it? It is. So the problem is, is some people place it in the root of the repo. Yeah. We have the read me. We have the license, which is in the root of the repo. And others place it in this dot GitHub folder. And both are correct. Right. So it's just up to you to, to figure it out. If you were to look at the docs, they would say you're both correct. I've always found it easier. For things that involve configuration of the repo. To be in a dot GitHub folder. Like templates. Remember, we talked about the issue templates that Panda has. Pandas has like bug reports and an enhancements and features. We showed you that when we were talking about issues yesterday. All those templates are right here. So it's a configuration for the repo. So therefore we put it in dot GitHub. One sec. Sorry about that. It's allergy season here and I am suffering, suffering. So here we have it right here, contributing MD. So let's go ahead and take a look at that. So there's a simple says contributing to pandas. A detailed overview on how to contribute can be found in the contributing guide. Let's see where they put that. They have that deployed out to their website. So theirs was very simple. They just linked to their website where they have a much bigger. More robust thing. Now, is this a GitHub pages site or not? That's the trick. We'll never know. And it very well could be. But we will never ever know if this is deployed with GitHub pages and that's okay. Now you don't have to link out to a website at all. So let's see if we can get to the VS code repo. Here's extensions. Let's see if they have one. We check the root. That was fast. Nothing in the root. So we check the dot GitHub folder. Lo and behold, it's almost as if people set this up as a part of the community. So let's take a look. Boom. We're going to contribute a new sample. See the sample guideline. There's didn't go anywhere special. There's actually linked to a file in the same folder. Watch if we just go back one. It's right here. Sample guideline next to contributing MD. They could have just put this as one file. So maybe after you learn what you're going to learn today, you can suggest that over to Microsoft and contribute back to VS code extension samples. But here's just their guide on how to do this. And it's simply just helping you contribute to them in a way that they know how to understand it's, it's their guide on speaking their language so that you can effectively help them. This is super important for pretty much every single project that has ever existed that expects or welcomes contributions. So if you're working within a repository and it doesn't have to be code. Okay. It can be HR stuff. It can be security stuff. It could be whatever you want. It doesn't have to be code. But if at any point you're saying, Hey, I know I want to collaborate with people at some point. One of the first things you should add to this repository is a contributing guide. Right. Like let's figure out what that looks like. The other thing to note about that or another thing to note about that is it's not permanent. You're allowed to change your mind. You're allowed to make those changes and to update that file as your project grows and evolves. That's the cool thing about this. None of it is completely set in stone until ever. And which also means you can go back on your decisions as well. And we'll show you how to see that history a little bit as we build some. Absolutely. I mean, what y'all are hearing, you know, this is the best practice. And that's again, one of the reasons I was excited to have Matt come and teach this thing was because that's the way you do it correctly. You know, you create your repo, you create your README.md. You can create or right there drop that contributing.md. Set your rules for collaboration. That way you're really doing it right. It's not like, oh, we just have a thing. No, you're structurally building this sucker correctly to set it up for your community. Like Matt said, you're doing code. You're doing documentation. You're doing hiring process. Like how do we, you know, we need to formalize how we hire people. That's your first couple of steps to really doing it right. Absolutely. So collaborating only matters if there's more than one person, right? Right now, I need to know how many people have access to this repo. So we're going to find that out. I find that out by going to the settings and clicking the collaborators tab. And we log in and we can see who has access. Zero collaborators. The repository is public. So you guys can all see it, but I have zero collaborators. This has been a problem that I've faced a lot in life. And it's probably why I teach is I just don't have very many friends. And so I force all of you guys to listen to me and that's why we're here. But in this case, I'm lucky enough that Brooks is at work too. And he's paid to be my friend today. So he's going to be my friend. So I'm going to go ahead and I'm going to add Brooks is a collaborator to my repository and don't feel too sad. I genuinely do have friends. Massive bowling leg you're on. Yeah, man, we lost last night. Oh, it's bad. So we got Brooks and his wonderful face and we're going to go ahead and we're going to add him to the repository. And whenever he accepts that invite, which he's looking out for, so you'll have to bear with us as get a like updates it stuff. It might be a little slow. So feel free to ask questions and quite literally all, even though I'm not set to show you my screen when I'm looking at him, if you could scroll to the top real quick, Matt, so I can show him the, you see the little bell up there icon with a little blue dot. That's what I'm looking for because that's where it's going to show up. It's going to be a notification. And so I look over here and I can see I've got a notification from Matt. I just simply click on it. It's so easy. I'm just clicking here. There's no code happening and I can either accept or decline this case. I'll choose accept. He also got an email too. That's the other thing you're not. Oh, that's true. That's true. He didn't have to necessarily check GitHub, the notifications. That is the first place like I always check for stuff because I'm really used to being on the platform and I ignore my email. Yep. But if you're somebody that doesn't know your email, you would have also seen an email that you got an invite to this repository. It's another place you can see it. And I've seen this a lot when I was out, you know, traveling all of the country is integration via Slack. You would see it pop there too. Yes. But anyway, I'll just let y'all know what's happened. So what I did was I got the invitation clicked on it, choose accept. As soon as you choose accept, what it'll do is it'll navigate you right to that repo. So for now, for me on my screen, I'm looking at our GitHub for everyone repo inside Matt's account. So it just took me right, like the word Matt showing you that. So again, super easy to add people just say, hey, open it up and they're there. So easy. Yep. So now he's a collaborator, right? Pretty cool. He sees he's on this page. This is where it landed him. So back over in our settings from our view as the owner of the repo, we see that he's a collaborator and I can, I can list my collaborators if I really want it's there. Now, what does this mean? It means he can do. Almost everything. He can't delete this repo. I'm pretty certain, but he can do most of the management. I don't think he can set up things like branch protections and stuff like that. I think that has to be done on me, but outside of that he can do quite a bit. Let's see if there's kind of scope it for y'all. Like right now what you're seeing there in his ribbon bar and Matt's ribbon bar for code issue pull request and all that. I have all of that except settings. Yeah, so exactly. Perfect. So here is where I can set some of the stuff he can do under these moderation options. So like I can limit things to existing users with comes to interactions with this as it goes on. So we're not going to change any of these. That's not the scope of what we have going on. The point is we now have Brooks. With me in this repository and we are ready to begin contributing. So. Let's do the first thing that we need to do. And that's create our contributing document, right? Oh, how would we go about doing that? Well. The first thing is to collaborate. Weird. We're going to collaborate before we work. Now, yesterday. We talked about how to have conversation on GitHub. And we pointed out two locations to do that. The first location being discussions. The second location being issues. So if we look here, we don't have discussions enabled on this repository. So Brooks and I are going to start by saying. Hey, let's create an issue. So I'm going to go in here. I'm going to create an issue. And I'm going to say the title of the issue is going to be plan. The. Tributeen.md file. I'm not going to type that up, dude. So I am not, I hate to, to, to get up on a soapbox here, but notice the thing that we did here. It would have been really easy. Matter of fact, it's open right now. I can do new file. Create contributing MD. And I can push it up into the repo. That's not how we do it. We start by having a discussion like, what are we going to do? And we use issues to track that and keep also keep this in mind, y'all, when you're thinking about this, when it comes down to things that you're doing at work and you want to sort of make sure it's very clear to whoever may be looking in to say, okay, what are y'all doing issues, conversations is the way to do that. And with the issues, they can say, oh, they're working on the contributing dot markdown. I know it sounds like that's almost like a, so what Brooks, what's the big deal? Here's the big deal. That's the visibility into your work that you can use. So that you don't have to get emails, slack messages, anything like that. They can just go and see what you're working on. So before you start click clacking around and creating files, create an issue. And then that way you can see what's going on there. And then, and I don't think we're going to do this for this map. We're going, I don't think we're going to a project board. But if there was a project board, these issues project board. All right. So we'll do a project board. They can go look at the project and see where things are going on again, without slowing you down without having you to stop what you're doing and interact with a person like with a project manager. It can all just be seen here. Exactly. So I have this issue. I gave it a title. Now look, there are a couple other best practice things. When we're talking about commit messages and titles for things, these things matter. I want to be able at quick glance to understand what exactly I, it is I'm looking at what exactly the change was. So for example, when you updated your profile, read me last night, if you just hit commit, the message that was that came with that commit probably said something like update, read me.md. That's descriptive. Okay, cool. You updated the read me.md. But it doesn't really help when 400 commits say update, read me.md. And you need to find the one that broke stuff. Yeah. I love those messages by the way, y'all. You love some grinds my gears breaks my heart. Run around in circles. Can't stand it. So good commit messages matter in the case of an issue. Good titles matter because there is no commit message. So this is very direct. We're going to plan the country. Everybody hang on something just went wrong. Lost. Yeah, Matt says we lost the audio. I'm muted. I'm back. Here we go. Okay. Okay. It was Patrick. Hey, hey, careful. This is online now. Yeah. In the future that are watching it today is February 24th. Look it up. Okay. Hopefully we got the screen sharing back. We did. Is everybody see it okay? You see it. Lola. I'm going to read just take two seconds to repopulate my pain. Whatever Lola. Cool. Thanks. Okay. Thank you everybody. Cool. Awesome. Wow. What a fun time that was. So technology is wonderful. Which is why we need super solid direct titles for things so that we know what we were working on when things broke. Okay. So in the case of an issue, this is, this is really helpful. Now it's, if I want to know what this issue is going to look like, I can hit preview. Okay. No problem. And you'll notice I threw some emojis in. Why? Well, culture. That's why it is. About the fact that we need to convey as much intent is possible. And we also have to read with positive intent. This type of stuff shouldn't be burdening work. It should all be lightweight. Enjoyable stuff that we're working on. So in this case, I threw a couple of emojis. This is what it's going to look like when it renders. I also, since Brooks is a collaborator, I can add mention him. And if you remember yesterday on this, this watch thing. If he has. His mentions turned on. He's going to get an alert in his email. He's also going to get an alert up in the notifications panel. And once I submit this, he's going to get a ping. It's going to be a good time. There's another thing I think I'm going to set up before I submit this issue. And I'm going to add a label to it. Because there happens to be a default label. Of documentation. But it also means that in two weeks, when Brooks hasn't responded to this issue, he can't say he didn't know. Did not know. Right. He can't say it because I said, Hey, I mentioned you directly. So once I submit this, he's going to get a ping. It's going to be a good time. I'm going to get a ping. I'm going to get a ping. I'm going to get a ping. I'm going to get a ping. I'm going to get a ping. I'm going to get a ping. I'm going to get a ping. Documentation. But I also want another label. And this label doesn't exist yet. So I'm actually going to type it in right here. And this is going to be. External. Contribution. And I'm going to make this label because I. Want to give people. The opportunity if they create issues in the repository later. It's going to be an external contribution. And the idea here is, is that as you're looking through your issues, these tags, oh my gosh, I'm sorry, y'all. I'm an AWS engineer and I screen tags all day long. You tag everything. This gives us when we get into issues, the ability to quickly find things. I don't remember if you remember seeing it from yesterday, Matt will show us in a second, but that's the point of tagging. So we can see categories quickly. Of what the issues are about. Exactly. And since this didn't exist. I don't have a project board set up. We get a button that says create new label. So if I just create that, it's going to pop up. I can give it a description. I can randomly generate the color. Let's pick something fun. That's not fun, but it'll work. And this is what the labels are going to look like. I don't have a project board set up. And I don't have it in a sign-in setup because. Well, we don't have anybody to assign this task to. I don't have anybody to assign it to. I don't have anybody to assign it to. However. It's the two of us. So we could kind of narrow that down if we really wanted to. But I'm going to hit submit. And now. Brooks got a ping. That says you've been at mentioned. And we have an issue. In the repository. And here's that view that Brooks was just talking about. We can quickly see, Hey, this is what the title of the issue is. This is a very important thing. And it matters for external contribution. Click into that real quick, man, please. And that right there on my side, y'all, again, going back up to the bell, clicking on the bell, I get the notification that I've been, there's, you know, something has popped up. I click on it. And without having to go, Oh, how do I get all of these issues? No, I just clicked on it and boom, I'm sitting right there where Matt's at. I'm going to see what's going on. Makes it super easy to collaborate. Exactly. I'll be able to show it to you from, from this end. Although mine is messy. So I have to, I have to work around that. Cool. So we have this here. He got a pain. He knows that I'm ready to have a conversation with him. So it starts. And we'll wait for his reply. He's going to reply in some way, shape or form. And once he does, or while he's doing that, we're going to go ahead and we're going to quickly set up a project board. So here's another great thing about this. This is asynchronous, but I don't have to be blocked waiting on Brooks to answer me before I can do something. I'm off over here doing the next part of this while he's addressing what I sent over to him. So I'm going to call this project planning because I'm nice and basic. I am not going to make this automated. I'm going to create a project. I'm going to add a column called needs triage. I'm going to create another one called in progress. And you can name these whatever you want. And I'm going to call this one done. Now the reality of it is if this wasn't a bootcamp, I might have 15 columns up here, right? I might have like a ready for review column. I might have a backlog column. I might have a blocked column. I might have some other tier of triage column. You never know. Every project is different, but for demo sake, we don't, we don't need anything super crazy. So while we wait on him. As we still wait on him. I'm going to go ahead and I'm going to add this to the project. Oh, look at that. It just popped right up there. Didn't that say that without even doing anything. I'm going to hit project planning. It's going to add. And it's a waiting triage, which means I can then drop it in the column. So I'm going to say, Hey, needs triage. And here's Brooks. He commented. Awful. It's trash. Okay. If I come over here and I refresh my notifications. Here it is right here. I have a mention in this repository. It doesn't say who mentioned, but I can see who is a part of the repository. And if I just click on that, it takes me right to the mention of I'm trash because Brooks is a nice guy. So here we are on that awful idea. We've added this to triage. So I'm simply going to say this. I'm going to go. I'm going to respond to him with this cause ha ha. That's funny. And I'm going to say at Brooks. Great. I've added this to the project board. After break. Let's triage it. There we go. And by the way, y'all, this is, this is happening very chatter. Between he and I sing in my browser. And what he, what y'all are seeing in his browser right now. Without me mucking around or doing anything. I just, it's updating, updating, updating. And so it becomes, you know, it's, it's a great way to communicate. And it's really the thing about this as a tool is, is transparent. It just gets out of our way and lets us talk. And you'll see in the project board, since I added that to the issue, it's, it's already in the needs triage category. And it's waiting for us. When we get back from our super wonderful break. See for a few of you have. And that's implementing a get flow strategy for your projects. And in this section, we are going to talk about branch strategy, what branches are. And just some of the ways that you can pull this off. Now go back to the very first day. Very first 30 minutes. We, we set some expectations. Then I set this magical expectation that says. I can't solve your problems. I have no idea what magical recipe you need. To solve your projects problems. And it also means. I don't know what branch strategy is right for you. I'm going to show you a very basic branch strategy to teach you the concept of branches and show you the benefit of branches. It's probably not enough for a giant web application. It's going to be way more than enough for some documentation stuff. It's probably going to fall somewhere in the middle of, if you're working on a small, like personal project or a project with four or five people, it's probably enough. So let me go ahead and move some stuff out of my way really quick. So I can get a super Uber fancy drawing tablet. And I would say this y'all, this is this is the thing that gets people trying to understand branching and all that sort of stuff. So this is something to really just let it go right into your brain here. So the way we're going to go about this is I'm going to give you an example. I'm going to give you an example. I'm going to give you an example. I'm going to give you an example for you. Plot twist. I am an instructor. Not an artist. Matter of fact, I'm a bad instructor when it comes to being an artist. I don't even do stick fingers. Well, here we go. So what we're going to do is I'm going to diagram this out for you. And hopefully it doesn't end up being like. Crazy cryptic and horribly written. So, and then I'll come back into the repo and we'll show you how we apply that concept using GitHub. Okay. So hopefully that makes sense. So we have our fancy little screen here and hopefully these are thick enough. I've never used this program. So we'll see. Let's say we have this wonderful file. This is file a, right? I'm super fancy on this. So this is file a in file a. It lives on a branch. And that branch is called Maine. Okay. Maine is the, the branch that we're used to seeing, right? We come up here. It says where I'm branch main, man. Read me as right here. A is a whole lot easier to write than read me though. So bear with me. Right. We have file a. We have a couple of things that we need to do. We're trying to create file B and the way Brooks is saying is he's going to create file B, B as in boy thing. Oh, yeah. File E T is what Brooks is going to create. And he's saying that, Hey, I, I just saved that file or commit. We're going to say C for commit. We'll put calm. Right. I commit that file directly to Maine. That's right. Now that file is living right next to file A. This program really hates quick B's. It's, it's living right next to, to file A. Now, in a documentation project, is this a problem? Not really. There's nothing that can break in this scenario. If there was automation attached to Maine, like spinning up new environments or changing and altering resources, then this is a bad idea because it could break. If there was software like, uh, or, or an Apple web app, like GitHub deployed off of Maine, this is a terrible idea. And you should be strung up by your feet for 25 minutes at a minimum screaming, I will not commit to Maine over and over and over again until you never commit to Maine again. Terrible idea. Don't do it. The bigger issue is this is a bad habit and we all have gotten into it because if you have limited GitHub experience, you've worked on your name space a lot. And if you commit to Maine and if you break your own projects, you probably don't care, but when we're talking about collaboration, this is a really big, big, big, big issue. And if you do this, you are not in any way, shape or form actually benefiting from using GitHub. So this idea of committing directly to Maine is bad. Don't do it. Ever. But it's so easy, Matt. Right. So listen, we're going to, we're going to start a little campfire. We're going to grab some candles. We're going to stand around the campfire and we're all going to chant, I will not commit to Maine. I will not commit to Maine. Okay. Please don't do it. But I want to talk about my feelings about committing to Maine. This is not a safe space when we commit to Maine. Okay. Now, don't be, don't be silly. Right. What is Maine? Well, Maine is a friendly name given to the default branch. So in some ways, in some ways, could we almost say that's release? No, no, never. It's Maine. Oh, see, I knew they're very good. Tell, why, why not? What is it? What do we, what do we talk about in play? Okay. Right. So Maine is, is often what's called the default branch. It doesn't have to be. You can name your default branch, whatever you want to name it. But it is what you've probably heard in DevOps space trunk. Okay. The default branch is trunk, right? In DevOps, we say that all the time, commit to trunk, commit to trunk, whatever. Maine is just a friendly name for that. So anytime you're doing the Brooks Seahorn commit method, default branch or to trunk or to Maine, and in some cases cats, you should scold yourself because you're wrong. Okay. And I'm not going to tell you you're wrong often. And I said, I can't give you a recipe. But if you do this, the recipe is you're wrong. Stop doing it. Okay. All right. Good. I'm glad that we agree. Creates. All right. So let's talk about the right way to do this. Here's my branch. It's lovely. This is Maine. Okay. Maine has a file on it. It doesn't matter. It has tons of files. It has a hundred files. It has 4,000 files. It has zero files. Normally here it has stuff on it. Okay. If I want to make a change to Maine, notice how I didn't say in the last example that changes to Maine are bad because they're not. Commits to Maine are bad, right? Changes to Maine need to happen. We need to edit files. We need to make changes. We need to add stuff, remove stuff, fix bugs, create better documentation. These are things we need to do. It's called work. Crap. They got us again, dude. We're working. Oh, no, right. Dang. So it's called work. It has to happen. I didn't say you can't change Maine. Said you're not allowed to commit to Maine. And honestly, GitHub blocks this from happening. Happening. It's called branch protection and I know that's spelled all kinds of weird here, but protection, it's called branch protection and it stops you. It prevents you. It does not allow you to commit to Maine. If it's configured, here is the problem with branch protection. It's an enterprise feature or a paid org feature. Okay. Remember the catch. What's the catch? This is one of them. Unless the repo is public, okay, we can enable a limited set of branch protections on public repositories, even if we're not in Oregon. All that good stuff, but it is limited. So we can stop commits from Maine and we can even force reviews and other things. So let's look at a real strategy. I have Maine and at the same point in time, here's a point in time. Genesis for our repository. I create a new repository. Here's a point in time. Genesis for our repository. I create another branch. Okay. This is going to be called dev. Right. We're working with me or features or whatever dev works. All of our changes are going to take place here. Um, Maine is going to be like the, the tell all source of truth that I shouldn't change unless I know the world is golden in PG for me. Dev. However, is where work happens. Okay. Now dev has everything that Maine has at the time the branch was created. So let's take a look at this. We have a read me. Correct. We have no branches other than Maine. If I click here, I look at Maine. I also see that it's that fancy word, the default branch. Everybody's tracking a hope. If I create a new branch called dev, it's created from Maine. Now we're on dev. Well, it has a read me. Well, guess what Maine has a read me. And these files are in sync. So essentially what is dev? Well, from a GitHub for everybody point of view, it's just a copy. Oh my God, this program hate circles. Did you test drive this thing? This thing is just not one. No, I found a web one for Linux and it is what it is right because I'm also pumping my external stylist in through a VM. So I just think it's a little bit. Yeah, yeah, exactly. So it's essentially a copy of Maine from that point in time when the branch was created. Okay, we can think about it like that. So now if I want to work on, we'll call it a feature. Here's a third branch like our contributing MD file. We're just going to name this C. I need to create a branch off of dev to do that. So that's exactly what I am going to do. So I have dev selected. Watch what happens if I try to do this from Maine. I'm going to say this is contrib MD file. Notice how I named my branch very deliberately. This branch is going to be us working on the contributors and our contribution MD, right? It's a very deliberate name, but look down here. It says create the branch from Maine. That's not exactly what I just said we were going to do, right? Nope, not at all. Shucks. How do we fix that? Well, we delete it. We switch to the dev branch and now we type the same thing. Confib MD file, whatever from dev. So now this has changed. So we are going to branch from dev. If I click this button. Boom. Well, it looks like these are the same. This branch is up to date with Maine. That's interesting. If we click on on dev, it's up to date with Maine. Fine. It's not really easy for us to tell where this branch came from. When we look at this in these views, right? We can't see so much that this got branched from dev. Yeah, I was going to say, like, yeah, that's exactly what I was going to say. You know, like right now, just me looking at it, just let me dump any knowledge I have about good ones. Everybody noticed that it's really tough to figure out where we are right now. Yep, all we have is this branch. So what do we do about it? Well, we make it very clear what our branch strategy is for projects. And this is, there's no way to find that information quickly and easily on GitHub. So it's a matter of discipline and it's a matter of understanding what your team's branch strategy is document it. That's the best thing I could say is document it somewhere. So here we are at this point in time. We've created a branch for a feature, which in our case is the contributors MD. What we are going to do is we are going to add stuff. Text, right? We're going to build that file. And when we are ready, we are going to open what is called a poll request. From the feature branch into the dev branch. Does everybody get that feature branch dev branch? If you're not familiar with GitHub and you start to get a little paranoid when you start hearing people go a million miles an hour talking about, well, there's a feature branch that we're going to have right now. And you hear those sorts of terms, it ain't no big thing. That's all it is. It's just another branch. Don't let stuff like that freak you out when you hear it. That's what it is. Isn't it simple? It's really, it's just, and like Matt said, this is about discipline. This is about making sure you're following a process. And when you do that, as you'll see in a moment, just how easy it is, it keeps things really clean. So we are going to open a poll request from feature to dev, right? Because remember, Maine is like our gold standard only ever merge into Maine once we know that dev is stable, like all, like we're stable with our changes. We've ran our tests or whatever. Now I'm kind of mixing the, hey, this is documentation with, hey, this is a developer practice too, right? So like CI and deploying out and monitoring health for the first day or two before saying everything is fine happens probably off of dev for you. It doesn't. It's going to happen off of a release branch, but I'll show you that. Um, so we're going to open a poll request and poll request is simply our request that you pull my changes from the feature into the branch that I want them in. This is where collaboration on work begins in this poll request. Okay. Is this the part, the kind of Matt where I'm kind of saying, hey, I want to have a conversation about some changes I'd like to make. Yep. That's one of the things that's going to happen here. And it's also going to be where you actually make the changes, right? So we'll talk about changes. We'll both implement changes. The whole team will jump on the project and work on it. It's often not one person writing a document. It's often not one person working on source code or a feature. And this is where we can do that together. Okay. So to finish this flow for you, before I show you how this works, when we are ready and we have merged that into dev and dev has decided, so we're merged back into dev right here. And the development branch has gone through its tests and it has decided that everything is fine. And our team agrees that we're going to have a release. We are going to create a release branch from dev, which contains a copy of everything from main and everything from the feature branch at this point in time. And we will release this out. Once we do our monitoring and all of our health checks and everything, and we've decided that the release is stable, then release does a double merge back to dev and back to main so that now these are equal. And this branch is deleted because the feature has been rolled in. That is a very basic L and then release is deleted. You don't need it anymore. You're already deployed. So then you rinse and repeat. I copy to the feature or to the dev branch. I create my feature branch. I merge into the dev branch. I merge into release and then release pops into main and dev and goes away. So let me back it up to second Matt to make sure I'm right. So we've got a main branch. We've got a dev branch. We can have feature branches. We can actually have a lot of feature branches out there, couldn't we? You could have an unlimited number of branches because guess what they cost Brooks? A hundred and three. A hundred and three dollars. Exactly. So when I'm doing this and I'm coming off main, let's say like we're just talking about documentation. So right now we've got to read me file up there and main. We're going to go into dev and we're going to add this contributing markdown file. And let's say it's got eight or nine sections in it. Could each of those sections be looked at as a feature? You could. I would argue that something like that is really small and you're creating more work than you need to to have each section be a feature. What is better to have happen is each section be a commit, which is an individual save point to that file, which we'll talk about as we do it. Where the file itself is the feature. Now that being said, features should be deliberate, right? A login button is a feature. The entire login form is probably a feature, but the entire login page is probably bigger than a feature, right? You probably have a base page kind of template that you're going to slap a form on top of. Maybe. I don't know what your project looks like, but features should be small and deliberate in self-encapsulating to the point where if you needed to remove the feature, does everything else break? Think about it like that, because what you can always do is roll back. That's the advantage of branches. It's a little outside of the scope of welcome to GitHub for everybody. But features shouldn't change 400 files. Features shouldn't change six files, most likely. Features should focus on just their feature. So if I'm thinking about it from a developer point of view, I might have a config file that changes. I might have a test file that changes. And I might have a source code file that changes for a feature, maybe two or three source code files that change, right? A couple of JavaScript files, the test for it, and the configuration if I need to, right? Exactly. That's probably it. That's a feature, okay? It's not the front end to the back end. Let's update the API and build the login screen, right? It's not that. It's small, deliberate changes. And then to a file, we'll talk about commits, because that better goes into where you're after. In fact, y'all, Matt's doing something here, and I hope you're catching it. He's really setting us up for the pro-level DevOps situation. Those features that Matt's talking about, those are where? Those are items in the backlog. Those are items in the backlog. How do we make sure that we're being good developers as we write code? One of the most important things you can do is modularization, okay? It's the sort of thing where I can make a change to one thing and I don't break the world. And that's exactly what Matt just taught us. That feature right there that you see on the screen, that's one little modular piece tied to a backlog item, okay, going right back to your backlog, that allows all this stuff to roll together. So you can see that what's, and this is one of the things that Matt was teaching me about this that I kind of grin about quite a bit. It's almost like if you implement this correctly, it helps to reinforce proper programming, etiquette, design, paradigm, whatever words you want to do. Let's just call it the right way, okay? That's what helps enforce this is following the sort of branching strategy he's showing us here. Exactly. Fun fact, GitHub insider pro tip, that release branch thing I showed you here, GitHub never, ever deploys from Main. There are a bunch of other branches that deployed. Main is, oh shoot, we need to recover our platform because something really, really, really, really bad happened. Now hold on, let's talk for a second here because that's really interesting. So then Main becomes like a restoration point. Like if everything blows up, like if we have to scrape down to nothing, we've got to start over. That's what Main's for. Our pushing though is coming from these release branches where we're pushing back to dev, but we're also pushing to Main, right? So that Main's up to date, but then the actual push to the world, that is whatever feature I just pushed to the iPhone iOS app, that's coming out of that branch right there. Is that right? Yep. So we deploy from release and we monitor and we make sure it's stable. And Main is always stable. Okay, now hold on, hold on. Stop right there, everybody. Goodness gracious, what just went by you was a truck if you didn't catch it. Well, we talk about the best performing DevOps organizations in the world. One of the things they have absolutely on their side is their mean time to recovery. It's called MTTR. Matt just showed you one of the tricks to it right there. You deploy from the feature branch, you keep an eye on what's going on when the world freaking blows up. Guess what do we do? What do we do, Matt? Got to roll it back, man. And then what have we got to roll it back from? Main. Wow. So that's from kind of a developer point of view. Now, I'm going to go in here and I'm going to delete some branches. Okay, because we're going to pull this away from developer and DevOps base back to GitHub for everybody. And this is too much for what we're trying to do. Okay, so to do that in GitHub, there's this little branch icon next to the drop down for the branch selection. And you can click on that branch and then you have trash cans over here. So I'm going to delete this and I'm going to delete this. So now I'm down to one branch. But what's interesting about this is if I click the, if I go back into the branches and I click the all branches tab, oh, they removed it. You used to be able to see all the unused, or the all the old branches for history. Oh, darn it. They did. I know. Oh, well, skip that. Forget I said that rewind. Darn it. So let's talk about something that makes sense for not developers. Now, look, that's what I just covered is one branch strategy for maybe code. The truth of the matter is your, your strategy is probably much, much more involved in that, right? It's probably main and then a dev branch from which we pull fee. Actually, I'll draw it a little different. I'll draw it a little different. Some of you guys are going to benefit from this. So this is still the dev example. Okay. We have our main branch. And from that, we have a development branch and somewhere along the line, we develop a feature and then we merge that back in. We might develop another feature and merge that back in. We might develop another feature and merge that back in. And now we're ready for release. So we pumped to the release branch and maybe that release goes to a test environment. So maybe we pump a second branch out to prod or whatever it might be, right? And then we decide which one to merge back into main and back into dev, whatever it might be. You might have A, B testing scenarios and stuff and those branches are going to come off of development prior to hitting release. Like maybe you hit staging and then from staging, you go to release. I don't know what your strategy is. The point being in all of these scenarios, we still haven't merged or committed to main, right? That's the important piece. So let's drive this back to the non-dev. We still like you. You're still included the everyone part. We have our main branch, also known as our stable branch. Stable, right? Shouldn't change. But we don't need this extra later of branches for what we're doing, especially on the documentation front. So we are going to just have feature branches. So if I'm going to work on a contributing MD, I'm going to create a feature branch. I'm going to make my changes to my file. And when I am ready and I have approvals, I'm going to open the poll request from the feature branch back into main. For your personal projects, for your small-time work, for your non-super technical stuff, this is the bare minimum scenario. No commits to main ever. Only poll request merges ever. So would you recommend math for all of us that are doing this? Even when we're just mucking around, just do this. Just branch update. We're going to end up approving our own feature and poll request. But isn't this just like the way to do it? And it's just the right habit to have. And because it's this, right? This is the reason I made a change to this file. So this file now lives here on main. Maybe in this file, I committed a password. Whoops, we need that to go away. We can just recover this branch back into its spot and delete the history and do some other magic and we can make that go away. Again, this is stable. It allows us to react to bad things happening. So even so, you're not immune in a small project to accidentally uploading a password. You're not immune to putting your credit card number on GitHub. You're not immune to misclicking. You're not like none of that stuff. You're human, right? So you're going to get caught up most of you. There might be a weird lizard person or something. That's okay. What a high five. But most of us are human and mistakes are going to happen. You are doing yourself a favor by creating the lifeline of a stable main branch and protecting that at all costs. Okay, let's go take a look. As a matter of fact, in our settings, down in branches, and we'll see what we can get with a pro account on a public repo. Okay. Look at this. Branch protection rules to disable force pushing, protect branches from being deleted, like our development branch, and require status checks before merging. What this means is, if Brooks or somebody was trying to, or even me, the owner was trying to merge a pull request back into main with failing tests or without approval, it would be blocked and it would not be able to happen. So you can prevent this from happening on accident, and you should. So let's do that. Let's add a rule. Branch name, we're going to say main, because that's the name of the branch that we want to protect. Require a pull request before merging. When enabled, all commits must be made on a non-protected branch and submitted via pull request before they can be merged into a branch. Done. Now, guess what? You can't commit to main. Not going to happen. Never going to be allowed. It's just not going to happen. So you just made it easy on yourself. The next time you try to accidentally do it, GitHub's going to tell you fat chance, and you're going to be just fine. So required approvals. This is a fun thing. If I don't check this, I can merge without somebody giving me a thumbs up. So that means let's just enable this, and I'll show you what that looks like. We'll start with one thing. So we'll come back to code. If I try to make an edit to this, and I come down here, it shouldn't let me. I might because I'm like super admin. It lets me, of course. How dare you? I knew we weren't going to get away with everything. Why didn't you? Oh, because it's coming from a branch. Sorry. Require side commits. It's not here. There is a way to prevent it, and I forget exactly what it is. You can absolutely lock this down somehow. It's in there. I promise you might have to dig in the docs, but you can absolutely lock this down. You can do things like requiring conversations, sign commit, man. Dude, it's there somewhere. We'll have to look that up everybody on our next point and we'll find it for you. Yeah, I know it's a thing, and it also could be not an enterprise. Like that might be one of the features I don't get not being an enterprise. Oh, yeah. Yeah, that's true. That's possible. So let's take a look at it though. I'm going to do a different edit because that's silly. Let's look at where we're at. I'm going to create a new branch, and what's cool is I can create one on the fly here. It's a very bad name. And now we're at that pull request phase where it's saying open a pull request, and it's asking to take our branch, our compare branch, the one that we just made our changes on, our feature branch, and move it into main, the base branch. We would use a title and we would put a good commit message, which we will when we demo this real time. That's terrible. It is, it is. And see now it's doing stuff. I could go and set up my continuous integration right here. I can set up my approvals or whatever. You'll see that I don't have any requested reviewers or anything like that. And now when I merge that, I can delete the branch because I don't need it. And my changes have made it into main. That little piece was deleted. And I can see the history that, hey, like, I merged the pull request to number two, which shows me the files that were changed. And we'll get into that in a minute into main. And that's what happened at this point in history. And we're going to dive really deep into this here in a moment. So if I'm going a little quick, don't fret, we'll get there. We're definitely going to come back to that. Because that's a really cool thing right there. That's a super critical. We'll come back to it. So that was a relatively worthless branch protection for our situation. So let's go ahead and edit this again. Wait, what was that back there? Default brand. Okay, cool. We're going to make this a little bit more blocking. So we're going to say required approvals. So this means somebody has to physically approve the pull request or else it will not let us merge. Required number of approvals before merging. We're going to say one and on enterprise, you're allowed to make it to where you can't be your own approval. Okay. But since this isn't a personal namespace, that's kind of silly. So if we did the same situation, I'm going to make an edit. Not up there down here. I'm going to create a branch and I'm going to open the pull request. Notice how it automatically goes to opening a pull request. This is a conversation that comes up a lot is, well, when do I open a pull request for a branch? Well, in this case, GitHub is suggesting that on the very first change, you open the pull request. And there's a reason for that. And we'll show you as we demo. But now you'll see this review required. You need at least one approval with somebody that has right access to the repository. So a collaborator and merging is blocked. If I try this, it warns me because I'm the owner and I'm in personal namespace that I have to very deliberately use my administrator powers to do this without an approval. And it's actually going to tell everybody that I did that. Right? So it's going to call me out for doing this. And that's okay sometimes. But I can't accidentally merge without that approval. Now, I'm going to hit cancel quickly. And if I were to add Brooks as a reviewer, guess what just happened? This updated to pending reviewer and Brooks just got a notification that says you've been requested for review. And to do that, it's a little bit tricky. And he's going to go into this files change tab. And there's going to be a review changes button. And he's going to have to hit approve and then submit review, essentially in order for it to approve. And it's a really, we'll get, we'll show you that four or five more times. But it's really in depth and difficult to find at times. So once that review comes in, this will unblock itself. So that is how we can protect main branches and enforce this branch strategy idea. And we did it in this format. So this is enough for small things. I wouldn't build an application this way. Like if I was working on my personal portfolio, I would do it like this. That's fine. If I was working on INE.com or whatever, like I probably would have a much better, more robust branch strategy than that. Right. Cause there's customers involved. It's not just me and my personal portfolio. So we're still seeing here. So you got the eyes. Does everybody see the eyes? He's looking at it. He's looking at it right now. So while he's poking around at that, if we go back into these, these protection rules, we'll just take another look at these. There are some cool things like requiring that those, any continuous integration you set up passes. But this is another good one required review from code owners. Code owners is like the contributing MD. It's a very special file that just is a list of usernames. And it says like these people like own the code here. So it's somebody from that list would have to approve the project. Now that's really helpful if you're doing intra team or inter team community like collaboration. If we were going to have the production team open pull requests into our instructor project, then we're probably not going to allow them to approve their own pull requests. And it's not that we don't like them. It's just, we know where our direction with the project we're working on is and they're a collaborator, not an owner. So we would set ourselves up as somebody on our team would need to approve their pull request, even though we fully welcome it 100% of the time. So I'm reviewing over here. Everything looks good to me. And I've got three options, y'all. I can do a comment, approve, or request changes. Now request changes will force me to make a change, right? It'll block merging until I make the change. Comment will just have a conversation with me. And approve says everything looks good to me. Go ahead and merge that and it'll unlock my ability to merge. So what I'm going to do right over here is I'm going to put an LGIMO. Looks good in my opinion. I've chose approve and I'm going to hit submit review. And you'll see this here. It seems like they've just moved the interface. So sorry if this seems crazy. As I mentioned, this is constantly being updated. I cannot click approve on my own review. It says pull request authors can't approve their own pull request. So there's always UI changes with GitHub, which is a good thing. So it looks good in my opinion and you'll see I have an approval. I can see who approved it. And so what you might want to do is if you're working in a bigger team, require two approvals. That's what we always do at GitHub. You had to have two approvals and you could see who approved it. So now when I merge this and it breaks something, blood's on Brooks hands, not mine. Very interesting. And there we go. So I can delete the branch because the files were merged into main and there's our change. And I'm seeing everything that just happened over here on my side as well, y'all, as I'm sitting on this as he merged, as the branch disappeared, I see that update automatically. So if you're in a managerial role, if you're just trying to watch the project, as those things are clicked in, you can see real time exactly what's going on. Right. So what we're going to do before our next break really quick is we are going to start our work. So we had our team meeting. We agreed Brooks and I are going to take this in progress. So what I am going to do is I am going to take our get flow, which means create a branch, edit a file and open a pull request to stage us and get us ready to contribute on the work. This is going to take, it's going to be this fast. I'm going to do it a little different. I'm going to let GitHub create the branch for me. Now, if I had this on my computer, I would need to use get. And I can say like get branch, create or whatever the command is off the earth. What I forget off some hand. I think it's use branch dash B, whatever. Use gh at goober. I don't use gh because I automate a lot of my get prop or my get. Yeah, that's right and gh is a GitHub tool that wraps. So it's not always available for those of you who wonder what the nerds here were going on about from the command line. You can use get g i t. But GitHub also has their own commands command line tool set called gh. That I kind of like it. It's pretty cool. It's their CLI and there you go. Like, you know, gh issue list like list all the issues for the branch that we're sitting on right now. There's also another one. If you're interested in alternative tools, it's called get flow. I don't know. Oh, yeah. Yeah. Yeah. That's a good one. I think this is it. Yeah, they have a tool that like does the auto branching and stuff like when you do stuff. So get flow is a tool that you can use. But these are alternative tools. I don't use them. I use get because I automate a lot of stuff and you could with this. By the way, for those of you keeping score, the GitHub CLI is written and go. Oh, God. We have to take a break. So we're going to let, we're going to let GitHub create the branch for me. And I can do that really easily by getting my keyboard back in place. And what I can do is I've been editing the read me. I'm actually going to add a new file. So I'm going to add a file. I'm going to create a new file. And remember where we said this one was going to live in dot GitHub. And then I'm going to type slash and it's named contributing dot MD guide for contributions. It's all I'm going to do. I'm going to make this small change. This is what it's going to look like before our break. I'm going to come into this and I have two choices commit directly to main. And again, through advanced security features and in organizations and teams, this will be disabled or create a new branch. And in here, I can rename it to add contrib MD. If I do this, GitHub now created that branch for me automatically. I didn't have to do any magic. It did it for me. And now it opened a poll request. I'm going to say this PR add contributing MD to the project. Right. I titled the poll request for what it is. This PR creates and adds a dot GitHub slash contributing MD file to the repo. Now, useful body information. I, when I reference this in six months, I'm going to know exactly what the purpose of this poll request is very deliberate, just like building application features, everything we do from titles is very deliberate. Now, what I didn't do that was deliberate is my first commit wasn't deliberate and it was disgusting and I'll show you that as we go forward after break. And we are back everyone. Hey, hope you had a great little break there. Grab some coffee, whatever else you need as we move on in. So catch us back up. Where are we at right now, Matt? All right. At this point, we've had our team meeting. We decided that this is the task that we're going to work on. This adding a contributing MD file. We have created a new branch to do that work so that we can protect Maine, which now has a dot GitHub folder. Right. So if we look at Maine, you'll see there's no dot GitHub folder because these are not in sync anymore. The changes are happening over here on the contributing MD branch. And inside of there, we created a contributing MD file and we opened a poll request that says I would like to merge that branch into Maine. And what Brooks and I are going to do on this or within this poll request is no longer have the discussion about the work. We are actually going to proceed with the work. But the first thing we're going to do before we do that is we're going to link this poll request with the issue. Okay. And just like down here, we have a signease. Well, we know Brooks and myself are working on this. So let's add ourselves as a signease. We have no reviewers, but we need at least one review. So I opened the poll request and as we learned, I can't be my own reviewer. So when we're ready for a review, we'll add that. We're going to add a label. Again, this is documentation. It's about external contributions. Let's go ahead and not add it to the project board. Rather, let's link it to the issue that is on the project board. So you'll see it comes down here. We could filter that issue if we just said one, which is where the issue numbers come in handy. We also only have one issue. So it shows up. And by linking that, if we see where it's at, it will also close the issue when we're done with the works. We don't have to go manually close that issue. So everything gets cleaned up automatically. Is that what I'm hearing you say? Absolutely. And you could take it a step further to automate the deletion of the branch once the merge is successful. Don't we get an option for that when we do this though? I think we do. Yeah, I think you can do a merge and delete, but you can force that at the organ. So we link that to the issue. Let's go look at our project board again, because this is where it gets pretty cool. But again, seat of a project manager or team member needing to view work in progress. Our card has changed a little bit. We now have this dropdown that says linked pull request. So we can see the actual work that we are attempting to do, the discussion about what we were going to build. And then we can very quickly and easily see the work as it happens, as it is attached to this card. So from a visibility standpoint, I think we're looking really good. We could also see, hey, there's a review required on this. It's open right now. We can tell because of the colors, which you'll get used to as you use the platform right away. We know that it's not just a card that's in work in progress. There's actual work taking place. We see who's working on it too, which is pretty good. So let's jump over back to our pull request. And now we can do some work. If I want to see the file that has been changed, which is really beneficial, there's this files change tab. So I'm going to click on that. And it shows me something very important here. And this is going to be more important as you have old files that you're working on. With new files, it's almost always green on the right side because you've done nothing but add things. With old files, if you remove things on this left hand side, it'll be red. And on the right hand side, it'll be green. And let me grab a URL really quick and I'll show you this. I'm going to use this repo here as an example of some good and bad practices. Here we go. So here is an example. A dependency was updated in this file. And so the old version of the file was actions core was 1.2.0. The new version of the file is actions core is 1.2.6. And that is the commit or the saved text to the file. We'll come back to this repo. I can see this on a lot of things. If we click here, no, it doesn't want to show us the diff. The reason it's not showing the diff there is because that file is huge. And it doesn't show us the diff on tries to keep it small. So here we go. This was just in addition. There was no deletion. Just in addition up here, but a deletion down here. So we can see exactly what has changed from the past to the current thing that we want to save, which is also called a commit. So every time we quote, unquote, save something, or as you saw when you edited things for the first time, like when you come in here and you edit, it says commit. That is exactly what you're doing. You are creating a hash value that points to a period in time of what is now different and forever until the end of time, we will be able to reference these changes all for the low, low price of 100% free. Okay, so super awesome. We can see what changed. So this is great. Need to hand a document to the legal department because somebody said that you're asking them to do tasks that weren't in the job description and you can prove that it was. Well, here's the point in time where you can prove that it was or maybe somebody suggests a change to the job description like fixing 20 years of AWS to two years of AWS. You could see what got changed in that file by viewing a commit. And viewing a commit is really easy. Every time we do something, we get this little value over here that's called commit. That's the hash for the commit. If you just click into that, you will view the details of the commit. The other thing is you'll view the title of the commit. Commits like you saw over here, right? This commit message, which it says create read me MD, right? Which would be wrong. If we update this, we're not creating the read me up D or we're not creating it. We're, we're updating the read me MD, right? So we might want to change that to update, but even then that's a bad commit message. So what you're seeing here, and I'll show you how I got here from the code tab. There's this thing over here right under the green box right here that says how many commits a repository has. If I just click on that, I end up in this space. Each one of these bold links is a commit message. So the commit message was adding doctor file name option. Somebody made a commit. This is a public contribution where they added some stuff to make this project better from their branch. And I thought we could see that, but I guess not. Now, this is the part right here, Matt, where you and I were going on about yesterday about 10,000 line file. It's a document. It could be anything from code to, Hey, this is going to be the new rules for our homeowners association. And it's got tons of lines in it. That's how you can use and get up super quick. Okay, what changed? Yep, exactly. You can just go see the commits. And if we scroll down enough, we're going to realize that there's this person that sometimes breaks good habits. You'll notice that since this was a personal project for me, I kind of slacked off on my commit messages. I said update main.js update main.js update main.js. But something clearly wasn't working because I have all these commits that say update main.js. So which one is the right one or which one is the problem? And this is why having good commit messages matters. Because if I was hunting for the problem, I would need to click into every single one of these just to find out which one is the update main.js commit that I actually care to look at. And if I would have just been more deliberate, for example, on this one, if I would have said commit message, change the core.setValuedValue to not parse string literals or something, right? I could have given myself a much better Easter egg to come back to two years later as I look at this code again. I have no idea what update I made to main.js as I stand here in front of you today or in front of my webcam creep. So as I stand here, I have no idea what update that is. But if I click on this bump actions core from 1.2 to 1.2.6, and in this file specifically, I don't even need to click that. I know exactly what happened. Add docker file name option is getting better. I don't know to what file or to where, whereas add tag input to docker gpr action, that is a really good commit message. I don't have to click into that. I know what that person did. We can click into it anyway, just to show you what they did, right? Notice how the line number, it might be hard to see because of dark mode, but the line number starts at 12. It didn't show us lines one through 11 and it stops at 19. We don't know how many more lines are in this file. We kind of do because we see other changes. There's over 70 lines in this file and we only see a small subset of them around the change that happened to Brooks's point. Do not be surprised y'all in big organizations that use GitHub all the time to find situations where there are like junior engineers, like folks that are fresh out of college, they go to do something like this. They put a bad message in there and the approver, their boss, just declines it right there. So there's no forget, just will absolutely trash it down. And honestly, I would suggest doing that yourselves. Like it sounds mean, but you're doing your team a favor by not allowing bad practices to exist. So honestly, like typically if you're contributing on any of my personal projects and stuff like that, if you have bad commit messages, I reject you. If you have bad poll request bodies, like if I click into the poll request that you've submitted and it looks like this, like this is okay because it's very deliberate. But if it doesn't look good, like I'm going to deny it. What I want to see is something that I can go back to. So when we look at Panda's poll request, like this poll request is okay. There could be much more detail about it. So take the initial upfront investment, build good commit messages, build good titles, supply good poll request and issue bodies. And it will save you hours, if not days later fixing stuff. Actually, I just saw something really cool. So we're going to click back into one. Here are all those checks. Remember, we looked at our branch protection rules and we said, hey, require checks to pass. These are all sorts of tests for their continuous integration that Panda's has built in and all of these have to pass or else they cannot merge this poll request. So this looks daunting and it is, genuinely it is. But if you have a production ready system, you're going to have these tests. And it's just, this is why we don't commit right to main because what if one of these tests failed, but we committed to main and main deployed everything out because we're reckless and we're doing what Brooks is doing, then we have a bigger problem. If we just make sure CI passes on this branch, then we can go back into main. So, yeah, that was kind of an interesting thing. Same thing. This is a contribution to Panda's. I can click into the files changed. And we see just what changed in this file. If I want to see the whole file because I'm just absolutely crazy, I can do that by clicking this three little dots up here and hitting view file. Oops, with one mouse button, not both of them. And now it's just taken me to that whole file from where it was committed. And you'll see this file is 147 lines long. But again, to Brooks's point, we're only seeing the five or six lines that were affected by the matter. Right. Exactly. And by the way, for those of you who are like learning Python and stuff like that, I hope you're seeing the idea that within GitHub, being able to set up branches and do things like that and fork things over, you can learn a lot of really good coding practices from other people's repos. That's a super solid point, right? Like let's say I use Pandas because I know they have a big code base in their public. So let's say I wanted to know about Python testing or something. I could search through here and try to find where they keep their tests. It's probably in Pandas testing. And I could say, oh, like, let's look at what the hypothesis Pi is or whatever. And I could see how Python for a real big project is written. Another really cool use case for this is if you're a DevOps engineer and you want to know how to set up GitHub actions and stuff, click into the dot GitHub folder, find the workflows folder. And these are all things that are configured for workflows. So a lot of these are part of the CI. See, this one says CI for the commit message. This is CI for the commit message, which is showing up right here. So if we looked at, let's find one that does something simple. Let's try this code checks. Here we could see exactly what they did to write some automation using GitHub actions. And we're breezing through this because we're going to jump into it a little later. But if you needed to know how to do this, you could very quickly look up into their files. And not only that, you can take it a step further. What's that? Actually click into the actions tab and find an executed run and look at the log output of their run and really click into it to find out what happened in the pandas environment. See, that's that right there is awesome, y'all. That is awesome. You can literally dive right in to their commits to see what happened. The point of it being, you poke around on this a little bit and you're in an organization that's not using GitHub or maybe you're trying to get them to use GitHub. You're trying to figure out an action. Well, somebody may have already written it. Go check out pandas, see what they did. Grab the code. Good coders or lazy coders. Cool. So let's digress. Let's get back to work, Brooks. We've diverted quite enough. Yep, we've got to do this now. We need to start editing this file. So I'm going to go ahead and I'm going to click files changed from the pull requests. And now I'm going to do something really snazzy. So simmer down here. I'm going to go ahead and come over to view and I can edit it right from this pull request. So we're going to edit. I must be on a branch. How am I not on a branch? Okay, so we can edit it. And I'm going to say to contribute. Please visit this link. HTTPS colon slash nowhere.com. That's probably real. So nowhere.xyz, which is also probably real. I'm going to say I'm going to make a good commit message. Added a link to actual contribution site in the contributing.md. Uh-oh, you got to have limited characters. You can add it into this, this bigger description if you want. So we're just going to trim it down. We're going to commit it directly to the branch we've created, not to main, and we're not going to create a new branch because that's not our branch strategy. We're going to commit these changes and bam. Now, if we go back to the pull request, we see that, hey, recently I've done this. I've added this commit here. So if Brooks wanted to know what Matt just added, he could just click this right within the pull request. And just like before, he's going to see that this block was added. So here's the thing. I made a typo. So from Brooks's point of view, he could go in and check it and check it out. So what I can say is, I can say something like this, hey, Brooks, I added what I think is the proper line. Can you take a look? Okay, right? What's going to happen? He's going to get notified, right? He's going to go in there and he's going to click the files change tab and he's going to notice that there is a typo. And he has a couple options. If he just clicks this blue box, this blue plus sign, he can write a comment that says, hey, man, you got a typo here. You might want to fix it. And when he does that, it'll show up. And we'll give him a second to get there. Cool. Yeah. So now what's really sweet is that poll request just updated. And look, it put his response kind of in a thread of what we're talking about. So he's saying, whoa, like you messed up here. He's showing me the line where the problem was. And I could respond back to him and I could be like, are you sure? Like I think maybe you're a little bit crazy. Or I could, I think it'll work here. Yeah. There's this little icon right here that's like a plus minus on a page and it's a suggestion and it's really cool. Watch what happens. I can change that. And if I hit comment, now this little drop down box comes up to actually commit that live. And I can say, hey, is the above better if it is go ahead and commit those changes. If I comment that, now we're having a conversation about this one specific block of text that we're talking about. So Brooks just got notified. He's going to go in. He's just going to click that drop down and hit commit changes. Now, hopefully Brooks has been paying attention and he puts a good commit message. Right. And we always care about that. So we'll see how I do. We'll see how I do. We'll see. Whoops. Hang on. Doesn't sound good. No, it's not going good. It's not going all over here. It's going pretty bad. Yeah. But the thing is, is that, you know, at this point I'm looking at this, I can see all the conversations that are going on. I can still, even at this point, you know, pop back messages. Yep. And I get this view changes button. So I can see what Brooks changed. It also shows up here. You can see that we're having this whole thing. So he went with looking good. That's fine. This is a very organic interaction. So, hey, he says looks good. So I'm going to come up here and I'm going to say fix typo in our online four, right? Better commit message. I hit commit. This changes and our conversation goes away. But it doesn't. You'll notice it says show resolve. It just gets folded up. So we can always view what we talked about in the history, but it collapses it just to make it a little better. Since we've resolved what Brooks's comment was about, it just folds it up for us. So we can come back to files change. It folded it up up here and we have this good to go. All right. Enough of your nonsense. I'm approving this thing. No, no, no, no. I'm not proving. Turns out, hey, Brooks. Oh, turns out our manager, he who has no name, decided that you at some markdown specifically specifically should add out some real steps to contribute. Can you make that happen by Friday? Okay. 900 or whatever. And I'm going to comment on that. So what have we done? We just built kind of chain of custody of responsibility here. Right? Hey, like this came down from this person that they request you to do this thing. So now when Brooks doesn't do that thing, we have proof that Brooks dropped the ball, which is fine. People get busy. But when Brooks does this thing three days early, we have proof that Brooks isn't overachiever. So when it comes time for his performance review at the end of the year, he can look at all the poll requests he's worked on. He can look at his entire contribution graph. He can look at all the things he's done. And he has the direct history of his last year of work completely at his fingertips. He doesn't have to think about it as he writes that review. But if I remember right, Brooks is going. He's got a flight. He's going to go speak at a conference. Yeah, I got to go. I can't. I can't be here. I got to go get on a plane. And there's a problem though, dude. I am going to. I'm not paying for Wi-Fi on the plane. I ain't doing it. Why? I ain't doing it. Use your miles. Dude, the miles are for flying, you know, for getting in the front. Not for Wi-Fi. So why would I want to spend those? Don't I have a way of getting this stuff local? Oh, man, that's a good point. I'm glad you brought that up. I do think so. I'm pretty certain that we can grab all of this stuff right off of GitHub onto our local computer so that we can work on it offline. Is that something that would solve your problem? I think it would, but now how do I do this? And by the way, okay, let me turn off all. I am not. I am manager. I do not work at the command line. I want none of this Narni. Yeah. So there are two ways you can do this. The current scenario is that Brooks has direct access to this repository. He is a contributor, right? We know that. If you've been following along, you have Brooks as a contributor too, right? None of you added him. Okay. So if you've been following along, Brooks is a contributor, which means he has right access to this repo. This is very important. He has right access to this repo. Since he has right access to this repo, he can do what's cloning, what's called cloning, the repo down to his computer. Now, if he doesn't have Git installed, he can also just download a zip file of this repository and open it up. Okay. So I happen to have Git installed. So I'm going to copy this, this URL. I can just click that button there and copy it. And from my terminal or from VS code, I can use Git to download that. So just like that. So easy. I have now have a copy of this entire repo to include all of its branches down here on my computer. And if I want to change branches, um, now muscle memory will kick in and I don't need to know what the command is. Come on terminal. Thank you. What did we call the branch? It is add dash contrib dash MD. Right. So if I switch to that branch, here is the file that we're working on. So I'm offline now. This is local on my file system. Now this is a little bit beyond the scope, but the point is that we wanted to highlight that if you need a local copy, you're going to do what's called cloning because Brooks has direct right access to the repository. Now, if any one of you right now goes to this repository, you can see it. It's public. I don't think you're allowed to clone it because you're not writers. You shouldn't be allowed to clone it without right permissions. So how do you get a copy of it? And I can verify that really quick. Let's go back to our favorite repo ever pandas. I can download it, but I can't push to it. Right. So if I use clone, I can clone it, but I can't push to it because I don't have right access. So if I need to write changes to something that I don't have access to, that's when I fork it. Right. I have read permissions so I can download it. I don't have right permissions. So I can't push changes to it. If I fork it, though, as I showed the other day, pandas ends up in my name space and I can push all of my changes there. Now, the crazy thing is when I open a poll request, I can go from my name space to the panda's name space so I can still contribute. So it's really important to know when to clone and when to fork. Brooks has direct access to the repository and he has right access to the repository so he can clone it. You guys have read access to the repository, which means you can clone it, but you can't make a change. So if you would like to make a change, you need to fork it and make the change on your version of this and pull requests back to my name space. So this is how you're going to get your notes. So you know, you're going to fork this repo. That way you can make changes for yourself. I don't expect anybody here to make a contribution back to this repository, but if you fork it, you can change it and you never have to push a change back to this name space. You can keep all of your changes in yours. This is, we hear all the time of people extending open source software or modifying open source software to their own needs. They're forking the project and then building on it from there and you can totally keep that in your name space. So that's how you're going to get your notes is you're going to fork this repo and then you can change whatever you want to change in it and it'll only you will be able to see it unless you open a pull request back. But since Brooks has right access, he does not need to fork it. He just clones it down and he can then use Git or the GitHub command line tool or some other tool to push his changes directly back to this pull request. So great job, Brooks. I hope your trip was great. You guys did a good job updating this document. You want to pop on in and give us an approval so that we can finish up work for the week. Absolutely. And you'll notice that real quick, what I did was and I'm going to be, I'll be honest with you, I did it all from the command line. It took about two seconds to clone update pushback. Just look, he updated right here. Oh, I don't even know what he changed. Let's go look. That's simple. I'm helpful. I'm helpful. Boom. Right there. And we can, we can be silly. Yes, you are. That's right. I'm going to add that as a comment. And there we go. I am a helpful manager. We'll resolve that because we don't need that to actually be a conversation. It doesn't go away. It just folds up. That's all. Now notice everybody also what I did there too. I did this from the command line. And all I do is get clone the URL that Matt showed you. But my pushback went to that branch. I didn't push back on main. I stayed right where I needed to be because again, get checkout, then put in the name of the branch. Don't know the name of the branch. GitHub.com, open it up. What is that brand? Ah, that's what it's called. I'm a bit lucky. I use a weird terminal called warp. And warp is meant for DevOps. And so it actually would list for me the branches that are available and then show me the branch I'm sitting on. If you want to check out its web, it's warp.dev. I don't believe it's open yet. I was just, I got access to a beta, but it just shows you how easy it is to work with something like that and how quick you can do it. So boom, I pushed it in there. Yep. And if you're on a terminal and you're using git just itself and you don't have any other fancy features, you can use this command and it will it'll show you the branches you have and my terminals configured to highlight the one amount. But that's a little advanced. It's not entirely what we're after, but you can, you can absolutely do that. The cool thing is he didn't use the web. Now, if he was on the airplane without Wi-Fi, he can't push, he can't push until he gets internet back, but he can write changes. He can make his commits or whatever. Wait, say that again, dude. That was a big deal right there. So I updated my, I updated the file, right? Everybody hear that? I updated the file. I did a, and it's just a bad hat. I do git add dot just to make sure anything I've done is in there. It's really sloppy. I should be more specific. But then I do a git space commit space dash M space and then in double quotes, a good message that makes sense, like updated contributing with helpful information. Hit enter. Now at that point, hands off. I'm still in the air. Hands off. I can keep working. I can make another change and I can do another git add dot git commit dash M, put another message in. Then when all this is done, when I hit the ground, when I get wherever I'm going, I've got my internet back, git push enter. Everything goes up. Everything goes up. Yep. And obviously, you know, if you imagine that scenario on a big enough scale with a big enough team, you can say, well, what happens if we change the same line? Who wins? And it's called a merge conflict. And this isn't a git class. So that's a class for a different day. But you would have to manage what's called a merge conflict. And that's not unique to GitHub. That's just unique to version control. So once we get that approval, we'll get a merge going on. Cool. There it is. We got an approval. We know it's Brooks. Ha ha. It's on him now. Because you can put absolutely nothing in the commit message other than just, yeah, whatever. Yeah. It doesn't have the branch delete on merge. So again, we can put a good commit message and we should, but honestly, the default one is pretty, pretty good. We're merging the pull request. That's exactly what we're doing. So confirm it. We delete the branch. There we go. What? Do you remember what happens when we merge a pull request though? What happens when we merge a pull? Oh, I thought we linked our issue to it. Where did the issue go, Matt? It's closed. Hey, pull request closed that. So the only manual thing we have to do, which you can fix on your own using automation is we can now move this in. It's our Monday meeting. We brought our team in. We're doing our day, our weekly daily stand up, whatever it is. And we said, hey, Brooks and I, we knocked that out last week. We're done. Let's grab the next thing out of the backlog and move this gravy train forward. That's nice. Yo, that is, uh, that is nice. That is your basic get flow. It's simply create an issue. Issue first. Communicate about the work in that issue. When you're ready to start the work, create a branch. Branch. The project board is optional. Create a branch. Make one change to open the pull request right away and then work together to do the work in the pull request and merge that branch back into whatever branch you need to based on your strategy. Merge back in. Delete the branch. Rinse. Repeat indefinitely. And now if we come here, we can, I think that branch might show up. No, they changed that. It used to be so good. So we can now look at all the commits we've ever made and we can see who did them and what, what happened and, and all of that. Oh, there was a merge pull request here that's great. This is what happened. We can see those commit messages right here on the repo code tab and our branch is gone. Everything is fine. And we are very 100% good to go. Does that make sense to everybody? Let me just get a quick hello, hi or something in the chat. Let me know if that makes sense to everybody. If there was anything that didn't make sense. Now's the time to say something because that is the core of kicking butt with GitHub right there. Ah, Benjamin asked, Matthew, can we fork your repo and do a simple pull request just to play around maybe till tomorrow? Yeah, absolutely. Let me, let me make you a different repo so that this one doesn't have a bunch of pull requests because this one will just probably forever be used for this bootcamp. So that way it doesn't get like we don't think something's broken. So for all of you who want to participate in the playground OMS that we're about to make, let us know hit there in the chat that you want to be part of it. And then if you y'all, you'll need a GitHub account to do this, let us know and then Matt can add you in. No, I'm not even going to add them. You guys can fork and just go from your own name. What? Oh, Patrick says me, me, me. Crap. Oh, I messed up. Okay, cool. There we go. So you're going to let them, you want them to, you want them to clone or do you want them to fork on this one? If they clone it, they can't write back to it. So they can't open a pull request. They can't make any changes, anything like that. If I fork this, you can then do that. So the link is in chat. Feel free to use this repo. So this is what I suggest. Okay. Let's let's do this the right way. Go to this repo. Open an issue here in my namespace because this is how I would contribute to a public project. I would go to pandas. I would open an issue in pandas or I would find an issue in pandas that said contribution welcome. And I would document what I am going to do. And this is, this is helpful because I can say, Hey, I see this issue. I'll take it. I'll work on it. I got it. So that 50 people don't work on it. So go to this repo, create an issue. Tell me what you're going to do. Tell me what you're going to add. You can add a file. You can add a little bit about you, whatever it might be. And then from there, you're going to open a poll request in your own namespace or you're going to fork it. Sorry. You'll open an issue. You'll fork it. You'll open a poll request in your own namespace. And then you'll send that poll request back to my namespace and have it set to close the issue that you opened. You can figure that out. I know that sounds crazy. Y'all like it's a lot. And actually, hang on. Hang on, Matt. Hold on. I have to un-empty this or else they can't fork it. There you go. Yeah. Hang on, dude. I'm going to create... Yes. There's absolute reason to create a branch on your own namespace. And the reason for that is what if you mess up while you're making the change? If you were making that change to main in your namespace on the fork, you would then have to delete that and go fork again to undo the problems that you introduced. So still practice good branching strategy. I know it's super, super, super tempting to just be lazy about it, especially on projects that don't matter. But the moment that you build it into muscle memory, it doesn't even feel like it's extra work. Like for example, here's our GitHub for everyone. I'll do it here because I think I can scale this a little better. Okay. So here's our GitHub for everyone repo that's local to me. So this is like what my local workflow might look like. I'm going to check out main, right? So because I want to create a branch from main, so I'm going to do get check out. And since I'm going to create a branch, I have to use a special switch and I'm going to say look at how fast I am. Right? Bingo. So now I'm there. I can simply come into a file that exists, which the read me exists on this branch. I'm going to do this. And then I'm going to come into here. I'm going to save that. I'll come back to my terminal. And I can say get add read me. I'm going to specify what I want to add. I'm not going to add everything. And I'm going to say get commit. And this is where I'm going to put a good message. Added jumbled mess to read me. Oops. Wrong set of quotes. Oh, you'll never get out of it. Yeah, it has its moments. All right, we'll hit those quotes. And now I'm going to get push. And this is the point where I'm sending it back up, but nothing happened because I didn't do some magic linking. And this is like get information, which is why I didn't cover it. That is very common, y'all. When you do a get push and you see that message, even people who would experience with it, they just go ahead and do get push. They get the error. That way they get the right command because it'll spit it back to you. Copy, paste, go. Yep. And in just that amount of minutes, I now have that branch up here with the change ready for a poll request, which I could open and do. It's, it's not a, not a problem. Could you do one thing for us before we go to break? And if you want to wait until after, you know, just let me know. I've just created a public repo. If I send it over to you, can you show everyone kind of the process they're going to go through to fork and do all that sort of stuff? Yeah, absolutely. Okay. I'll send it up in the chat right now. So what that is, everybody, that's just a quick, all right. So this is a repo I created. This is what forking is going to look like for you. Notice how it says Brooks Seahorn repo for Matt. I don't see the settings tab. I probably am not a collaborator. Watch what happens. I'm going to clone it. This is why you have to fork. Let me close this. Let me come into here. I'm going to clone it. Everything seems like it's fine. Right. I just, I have the repo. It's right here. It says repo for Matt. I have the readme says repo for Matt. Everything is normal. Right. We're all good. So I'm going to make my change because I'm fancy and I'm going to pull a Brooks and I'm going to commit to main. And then I'm going to go through my steps. I'm going to do super bad stuff by adding a period. Yeah. I'm going to put a really bad commit message and I'm going to push it. Permission to push is denied because I'm not a collaborator. I don't have right access. So cloning didn't do me anything of value. So what I'm going to do is I'm just going to delete that. I'm going to come back over to the repo. I'm going to click on fork. Does everybody see that? You just go to the repo, hit the fork button. That's all you do to get going with this. From fork, I'm going to say where I want to fork it to. In this case, my personal account. And notice now it says my name repo for Matt, but it has this added piece of information that tells me who the parent repository is. This tells me what the parent is. And I can see how out of sync with Brooks's repository I am. So this is the one that I want to clone. So forking doesn't get you out of cloning. It just gets you into a different namespace so that you can write and have right access to things. Are they in that namespace right there in the browser, Matt? Or for example, instead of coming out into a visual studio, like if they just wanted to use the editor right there, they would be in the same situation. They're in your own accounts and namespace at this point. So you don't have to use the terminal at all. The only reason I am is just simply to show you that error message has gone away. That's a really good way to see it because you can't see it. I'm lying the same way. Oh, that's right. Okay. Right. So now it said I wrote it, but I wrote it to this because my get is authenticated to my namespace. So if I come back here, we refresh it. Here I am on main in my namespace. And now it says that I am ahead of Brooks. Like I have made a change. So if I come in here to pull requests and say, I see this go to pull request, new pull request. Yep. And now things change. I not only get a branch, I get a repository. So head means what's first. So I want to go from my namespace on the main branch because that's the only branch I have to Brooks's namespace with the main branch because that's the way I'm going to do it. Hit that dropdown real quick for base repository under my name. Does everybody see you can even push it back to himself if you wanted to. Yeah. So if you were going from a feature branch back to main here before you went all the way back, you could do that. You've got complete control right there y'all on what you and how you're going to work this. Exactly. And when you fork like you can get branches too. So like you if you could get like the pandas dev branch so that you wouldn't commit to main for them or whatever. But this is how you would keep it in your own namespace. If I just wanted to make a change for me, see now it's just strictly in my namespace. But if I want to change that and I want to send it back to Brooks like you guys are asking me, I need to specify Brooks's namespace. So I'm going to create this pull request. All of this is really bad. And now you'll see where it redirected me. It redirected me to Brooks's namespace. It showed me the pull request there. Since his repository is public, I can see the pull request. And when I look into the pull request, we'll see that it's coming from me over to him. So that that should show you how to go about it. Use a effective waffle. Feel free to fork it. Feel free to make some changes. Push those changes back. Open pull requests. App mentioned me, whatever. If I see them, I'll respond to them and I'll merge them in and we'll see what we can come up with. But this one is going to be your notes. So I would I would wait to go crazy on this one. Yeah. So absolutely there with that, with the the URL that we put up there, not the one, not the one that I did, the one before that, the effective waffle project. Jump in there, fork it off, make some updates. Get it back into yours and then push the request back over. Welcome back. I see there's a effective fork, a waffle fork. We're getting there. That's incredible. What are they doing? What are they doing? Let's see this. They're sticking forks in the waffles, man. Ork in the waffle. All right. So that's great. It is super easy. If you know what you're doing, that the only one you're doing parts the trick. Right. So I think we're going to get into a fun part, Brooks. What do you think I've been waiting for it, dude? Yeah. So I'm going to try to go slow. I'm going to try to go real slow, but don't go so slow. It's boring. There are a lot of moving parts and confusing pieces that are going to come up with actions. Okay. So what I need from you, if you want to become an actions guru, is to ask your actions questions. Let me know if I confuse you. Let me know if I went too fast. All right. Ready? Get up actions, automation ready? Go. Okay. Done. Yeah. Yeah. All right. Fingers on keyboards. Ready? Get ready with your questions. So the first, first things first. Okay. Get up actions exists in all of these repositories. Okay. It is a repository feature. It's not an account feature. It's a repository feature. It's up here on these little tabs. You can disable them if you go to the settings and you come down to actions. I think, yep, here you can say general and you can disable actions. All right. So if you're scared that you're going to get charged for billing in your private repos or whatever it might be, maybe you just don't want actions to exist or maybe you don't trust external community written actions. You can, you can force them to be local and all of this will hopefully become uncloudy. You can adjust these settings on a per repo basis or you can enforce them at an organization basis. Okay. Repo feature. So that means in a repo, we have code issues, pull requests, projects, wiki. Oh yeah, we skipped actions. It's right here. Click actions. Come with me on a journey. If you do not have any GitHub actions configured in a repository, you are greeted with this super helpful screen that says get started with GitHub actions. Simple workflow. Let's see. Let's click configure. Oh, that's scary. That's super duper scary. This is an entire file. This whole UI just got crazy. Let's hit back. That's too much. We're going to slow down. Whew. That was a lot. Actions is a feature that allows us to automate things. Now, developers, their ears perk up. DevOps engineers, your ears perk up. I can do my CI. I can do my CD. I can provision my infrastructure. I can do updates. I can roll back. I can. Non developers go, oh, shocks. I got to learn to write code. No, you don't really not really. Oh, I can't use this feature. I don't write code. No, not really. Let's take a look at some of the things we can do with actions. First and foremost, there's some things that can help us with deploying. If we happen to have a Node.js app, we can deploy it to Azure. We can deploy stuff to ECS. We can deploy stuff to GKE. We can do OpenShift. We can do this stuff. Security folks, don't get too excited, but we can do like code scanning and stuff. CI folks, developers, again, like we're going to test some stuff with Python and then publish a package. We're going to do Java stuff for some reason. So automation folks, non developers, guess what? This is not super helpful for community management. What if I just want to say thanks for your poll request? Here's a greeting. This one just simply greets users who are first-time contributors to a poll request. Stale. This one says, hey, you have an issue in your repository that's been open for more than the window of time that I think is acceptable. We're going to market is stale, and if you don't do anything with it, we're going to close it in a week. These are just tasks that help us do stuff. It's really cool. How do you find more? Well, we go back over to our favorite place, the GitHub Marketplace. The GitHub Marketplace, we can over here under Types, we can just click actions. And here you go. Here's a bunch. Verified actions are key, because actions are community-driven. There's verified maintainers and publishers, and there is you and me. And I'm not verified, but it doesn't mean I write bad actions. We can look at any of these. First interactions, download, build artifacts, set up stuff, get diff suggestions. It'll take the current get changes and apply them as GitHub code review suggestions. Never used it. Don't know what it does, but we could probably configure it up. All sorts of stuff. But there's a lot of pages. Code guru reviewer. That's a big one, y'all. It's just right there to be. Yeah, there's a lot of stuff. Absolutely. You can search. You can also look at categories. Learning. Interesting. What does that say? Let's see. Nothing. Some people might just have their learning projects here. What about localization? If you're, excuse me, if you're writing documents or something and you need to translate them into non English stuff, here's an action that'll help with that. Right. So it's not just for code. And it's not just for developers. It's for anything that you just don't want to do manually. And we're going to dive into the theory behind this and how it works today. And we'll try to set up one of these smaller, easier ones. And then we'll dive into a lot more tomorrow. So let me get my favorite sketchpad back. I know you guys are loving the sketchpad. It's like top quality software. Let's see. All right. Couple problems. Okay. We have actions, right? And we have actions. Same word. Different use case. Capital A means the feature. Little A means a unit of work. Okay. It means a task. So actions, capital A is this entire system that's the feature. Actions, lowercase a, that's kind of what we mean to, what we mean when we're talking about this. So it gets confusing because we might say use GitHub actions to do this task. And you're like, am I supposed to find an action that does this? Or am I supposed to use the feature? Or do I use the feature to find an action? Or who gets crazy? So you kind of got to use some context. What we like to do is call this specifically GitHub actions and this actions. That's how we kind of delimit that. I will screw that up. Just normally I'm going to say the word actions. If I confuse you, tell me to slow down. Second to that. Okay. We have workflows, which like Git flow, that was our workflow, right? Create an issue, create a branch, add it to a project board, do a pull request, do the work, have a glass of champagne, do a happy dance, go home, all crap, it's broken, right? That's our workflow. It's typically any IT shops workflow. Last time I checked, it's Saturday, come back to work. Workflows are your process for getting stuff done. Workflow files are your recipes for telling GitHub actions what actions to execute. Do you see how all of a sudden they need to hire somebody to work on names over there at GitHub? I will screw this up. I'm going to say edit your workflows. Do something with your workflows. Workflow this, workflow that. Got to pick out the context. It's going to be challenging. Sorry for that. I didn't name this stuff, but this is problem number one. Okay, workflow files live in .github slash workflows, just to make it more confusing. Okay, so all workflow files need to be in this folder or else they don't work. I could take a workflow file and I could put it anywhere in the repository and it will not execute unless I put it right here in this folder. Very important. Also a good thing. It means if you needed to share some stuff around, you could just have a repo of workflow files that didn't execute and then people could pick and choose the workflow files because right now, there's not a good way to share workflows, but there's a great way to share actions. It's maturing. Give it time. It's really cool, but there are some hurdles. Okay, so how does this work? Very simply, there's a trigger. Trigger warning. Get it? I know you don't get it. It's okay. There's a trigger. What is that trigger? Well, it could be a push. It could be a watch. It could be a pull request. Okay, the point is there are a lot of them. So if we went to events that trigger workflows and we looked at the GitHub documentation for this, every one of these things in this list can be used as a trigger. And this is where it gets interesting. Some of them, like repository dispatch, means you can create your own trigger. So you can expand this. We'll get back there. Just needed you to know that there's a trigger. So that's the point right there, Matt, where if I can decide where I want this thing to happen. It could be on a fork. It could be on a push. It could be on a pull request. Whatever it is I can pick out. This is where I want this thing to happen. It's not necessarily the where. It's the win. Yes, the win better. I forgot to add this slide for productions. So here you go. Here's a slide and sort of GitHub actions. We're about to do some automation main. Okay. All right. It's not necessarily the where. It's the win. So a trigger happens, but then what? Well, then a workflow begins to run. Right. A workflow begins to run, which is technically reading a workflow file. Okay. So a workflow file begins to execute. That workflow file builds a virtual machine in Azure. Do you need to configure that virtual machine? Negative ghostwriter. You don't have to do anything. You just have to say, do I want Linux? Do I want Windows? Or do I want Mac? That's it. And it builds it in Azure. Within that virtual machine, it takes the steps from the workflow file and executes them. Right. Greet user. Cool. Probably makes an API request and the virtual machine triggers the API. The API writes back to your repo. Test code. Okay. Virtual machine configures your node environment and runs your CICD. Downloads your Docker container and does it from within there, whatever. It does the steps. The steps can be one of two things. Step item number one is simply called a run step. I think it's runs. It might be run. I forget off the top of my head. We'll have to look at it. I think it's runs. It's a run step. A run step is a terminal. Right. So bash. Okay. So if my step is a run step, it is no different than me coming over to my terminal and going echo. Hello world. Right. Hello world. Run step. That's exactly what I just did is a run step. Right. So what are some common run steps? NPM install. Right. Let's get our dependencies installed. Common run step. Get commit. Common run step. Okay. What's important to understand is that these are not reusable. I can't share this run step with Brooks. It's just written into my file, which is okay. But it means every time I want to run echo. Hello world, I need to create a step and run echo. Hello world. Okay. The second thing that a step can do is run in action, which uses the keyword uses. It uses in action. Right. An action is still the same thing as a run step. It's a unit of work. An action can still be hello world, but an action is bigger than that. Okay. And this is so much. I hope I'm going slow enough. An action is self contained and it becomes shareable. All right. This is an action. An action is made up of a YAML file, some source code, and maybe a Docker file. Okay. Question marks. It also lives in its own repository. Whereas a run step, we're just calling a command on the virtual machine in Azure. Right. So if Windows doesn't have NPM installed on it, plot twist, it does for this scenario, then it doesn't work. So if I fire up a Mac instance and I tried to run, I don't know, PowerShell, it's not going to work. If I want to run PowerShell, I need a Windows instance. Okay. So conversely, if I fire up Linux and I try to run Microsoft Word, which would never work in the scenario, it's not going to do that. So it's limited to the tool set in the operating system where action is programmatically built. It's self contained. It lives in its own repo. It has everything it needs to execute in the source code. It has everything it needs in its configuration file to include allowing the users to supply inputs to the action to change its behavior. And if it's not JavaScript, if it's not JavaScript or TypeScript, same thing. If it's not JavaScript, it needs a Docker file. So GitHub Actions, the feature, speaks JavaScript. So if you're writing an action that is JavaScript, you do not need a Docker file. You can still include one. It's faster if you don't because when the action is executed, it will not need to build or pull an image. It can just execute it raw. If you're a DevOps and a container freak, you could argue it's probably more stable if you do because you're providing the environment for it. So there is a tradeoff. If you want to use a language other than JavaScript or TypeScript, you have no choice but to include a Docker file because GitHub Actions does not speak go. It does not speak Python. It does not speak whatever crappy rust language you're writing your GitHub actions in. Okay. So you have to have a Docker file. It also needs a repo and this makes it easy to share because when we use an action in a workflow file, we are going to reference it by repository name. And that is going to basically get clone the repository at runtime and execute the source code based on the configuration YAML, which might include a Docker file. Okay. Lots of crazy moving parts, people. Crazy. There are some caveats to this repo. If it's private, your action is worthless. You can't share it. If it's private, right, we need visibility, so it has to be public. There's also a best practice and I will show you what that looks like. If I come back to my name space, my repositories, and I search actions, okay, actions is a repo that I have built. And in it, I was working way back when two years ago doing some proof of concept stuff around how to teach actions. I built a repo full of different actions. So this is a mono repo. It contains an action that prints a dad joke to the terminal. It creates an action that packages Docker containers and uploads them to the GitHub package registry, not the Docker hub, right? So issue makers would create issues. If you did a thing like I could create an issue using an action into a repo. So these were things that I worked on, but this is not the way to do it. If I wanted to reference the issue maker, I would reference Matt Davis slash actions slash issue maker. The problem with this is releases. If I make an update to dad jokes and I tag that as a release, it also changes the release tag for all of the other actions right here in this repository. So if we go back to what we talked about with branch strategy and like features being small and deliberate, your repositories for actions need to also be small and deliberate. Let's go back and take a look at something like Amazon or Red Hat. You see Red Hat has Red Hat actions, Red Hat actions, Red Hat actions, Red Hat actions. They have at least four actions. So if we come over to their repo or their namespace rather, Red Hat actions is the namespace and all of their actions are in their own repo. So even Red Hat doesn't have a mono repo for their actions. This is what an action looks like. Here is, so this is unnecessary stuff. This is stuff for them. This is their dependencies, which I think you have to include your package lock. I forget, spend a minute. The action.yaml required, the readme not required, the changelog not required, getignore not required, the tsconfig not required, the eslint not required. Their source code, 100% required. Their tsconfig is in here just because they probably use actions to build. Their source code, which is required. And there's not a docker file because it follows the rule of being typescript. And since it's typescript, actions speaks typescript. So if we were to look down into their documentation, it shows us how to use this in a workflow. Okay. So let's take a simple small look. We have jobs, jobs execute. So this is the name of a job. They execute steps. Remember, we just talked about steps can be actions or they can be run commands. In this case, it is an action. Notice how it's referenced by like a URI. Pretend that github.com slash is before red hat. You have github.com slash red hat action slash oc login at a release tag. Could be at a branch, could be at a commit, however you want to do it works. And then it says with, these are variables. I'll show you where these come from. So same thing. So one step is an action. Step number two is an action because it uses another action. Step number three is another action in this job. Okay. So this one didn't mix them up. That's okay. You can mix run steps with actions. You can mix and match it all. I'll try to find you an example of that. But which one are we looking at? We are looking at chart verifier. Where was that in their example? Chart verifier was the last block. Yep. You'll see this with, well, how do I know what variables I can pass into this? Quite honestly, they supplied it in their documentation. But let's say I didn't supply the documentation. I can look at that action.yaml. The action.yaml tells me inputs, which are user supplied variables with these names. They tell me what they do, right? And there's three fields. A description, if it's required or not, and what the default value is. For every one of these, this is as big as it can get. It also sets some outputs, which we're not going to dive super into outputs. That's like highly advanced dev stuff. And this is GitHub for everybody. But the most important thing is it says what executes it. So it says that inside of the VM, we're going to use node 12 to run the file in the disk folder named index.js. That's it. So that means when the trigger starts this workflow file, if we use this demo right here, when it gets to this step, this Ubuntu machine, this Linux virtual machine that's running on Azure, will call the command node 12, and it will pass it this index.js file and execute it. That's all. I know it's a lot, but it's not more than that. That's the upside. It's as simple as that. So we can look at another example. Let's find something that is maybe localization. Where's that translator? There it is. Okay. Nope. Yeah, this is it. Translates the content. We have a job. We have it running on a Linux virtual machine. It's going to use this issue, or sorry, this action. And it has a couple parameters that you can pass it. That's it. If we went ahead and we looked at this, we would see that here's an action.yaml file. If we scroll down enough, it uses node 12 on that Linux machine to execute the index.js file. Very simple. And that's what happens. I'm trying to find a Docker one to be honest to show you, but that's okay. I bet you if we do a continuous integration one, let's do an Ansible link because we got some dev ops peeps in here. This is verified and maintained by Ansible. So Ansible created this action. I'll get to secrets in a second. I'll answer that question. Yep. Good question. This was created by Ansible. You'll see here we have one job called build running on Linux. The first step uses this action checkout, which is the same thing as running a Git checkout or a Git clone. It clones the repo into the virtual machine so that you can access the source code. Then it runs this linter. And there's a bunch of documentation. These are all comments. So don't let it scare you. Right. And that's that. That one's pretty simple. So that one still doesn't even use a run step. My point is you can mix run steps. So quite simply, if we came into that, let's see. Here they use a Docker file. That's what I was hoping to see. So we have an action.yaml. It tells us all the inputs we can have. They went overboard. You don't need to do all that. And then it says it runs using Docker. And it's going to build the image from the Docker file. So it runs a Docker build rather than a Docker pull and builds the Docker file. And then executes the Docker file. They also included an entry point script. You don't have to do that. You can do that. It depends on how your Docker file is set up. And for them, that is their source code. There is no other source code in here. They use this script as their source code. So there's source code. There's a Docker file. And there's an action.yaml file. A minimum is source code in an action.yaml file if it's JavaScript. Okay, let me get to this question. That's a lot. I do pass secrets as a variable to an action. It may do bad things with it, right? It's public, but I need to inspect the action source code. Absolutely. Do not blindly pass secrets into actions you know nothing about. That is one of the reasons and one of the main motivators behind GitHub creating this verified creator thing is they vet these actions ahead of time to ensure that nothing malicious is happening with those secrets. Okay. It's very scary in that case. The other thing is just like we talked about authentication with GitHub is don't use over permissive secrets, right? Make sure your secrets are sensible to be using inside of a workflow, but you're absolutely correct. Nothing stops Steve or Billy Bob or Mary and Jane or whoever from building an action that requests that you put in your AWS access key and its secret key and then they just deploy crypto miners to AWS. And I bring that up because that's a real scenario. Fun fact number 439. When GitHub actions was first released to the public, there was a major problem with crypto miners setting up workflows to spin up mining machines on Azure and mine crypto on GitHub's dime. And the truth of the matter is there's still no fix for it. What they implemented was limits in how long workflows can run. And depending on your tier, you get different longevity behind how long a workflow runs before it times out and stuff like that. But that's the only thing they could do to prevent that type of thing from happening. So it does have its downfalls. And because of that, you need to be cautious. So let's set up, we got 15 minutes. Let's try to set up a really quick workflow. Let's do one real quick. So I'm going to come into configure. And I know this is going to be scary. I am going to remove this trigger. And I am going to include this one called workflow dispatch. This is a manual trigger. It creates a button for me that I can click that says run my workflow. I'm going to rename it to say hi to the boot camp. Okay. And the jobs it's going to run. I'm just going to clean this up a little bit because it's a little messy with all the comments. The job is going to be greet. It's going to run on a bun to and it's going to have. Ah, here we go. Look uses and then run. See they mixed and matched. You'll see run is simply an echo. So we're going to do this. And we'll take this one. Oh, we'll take this one out. Yep. And we'll take this one out. And I am going to break the rule. Okay. Oh, I'm going to name it. Oh yeah. Boot camp.yaml. I'm going to commit this directly to main. Please don't shoot me. Okay. We're here. All right. Notice how I put it in dot get hub slash workflows. So now it's here. So if I come over to the actions tab, it's changed on me. It looks different now. It's not the same. I have all my workflows. They're all populated right here. So I can find the one that I just named. Excuse me. And now I see all the times it has ever executed. And it hasn't yet in this run workflow button exists because that's the trigger I told it to have. I don't have to use that. I could use the trigger of every time a push happens. I can use the trigger of every Monday at 4pm. I can do all sorts of stuff to trigger these. In this case, we're just going to run it. So we're going to run the workflow. It requested the run. We got to wait a second while our environment gets built. It's running right now. This is all real time. Yellow dot means it's going. It's cued right now. If we click into this, I don't think we're going to be fast enough to catch it. No, you can't get there. It's already done. We can click into that. We can see the jobs that ran. If I click a job, I can see the steps that ran. For that job, there are two steps that will always run. The first one is set up a job. And the last one is completed job. And you do not have to configure these. They will always run. This is our actual step. And it says, hello world. That's it. It ran echo. Hello world. Pretty boring, not great. But we just triggered that automation. And if we look at this again, that's all it was supposed to do. Let's use a secret. Let's show why secrets are dangerous. What do you think? Yeah, let's do it. Let's do it. So we are going to remove hello world. And we are going to use some syntax here. And we're going to say secrets dot person. And secret stop person is nothing right now. Okay. It doesn't exist. And get on the nose with that means, right? When I do that dollar, curly, curly, it knows something's up, right? Yes. That's actions, workflow, syntax for expressions. So it's actually, there's a bunch of different contexts. And without getting too technical on it, there's a bunch of contexts that GitHub actions exist in. There's the GitHub context, which has metadata about the repository, like what branch triggered it. What was the event that triggered it? What commit message triggered it? What is the Shah for this thing and the Shah for that thing? Who triggered it? The actor. So it's metadata about GitHub. There's also a context called secrets, which is the secrets of a repository, which I've not showed you yet. So I need to call that context. And then I need to call that property in that context. And this just evaluates that and turns it into a string. Okay. So if I go into settings, a matter of fact, before we do that, let's run it first. See, I have a successful run. I'm going to run it again. I'm betting it blows up. I'm betting it's not going to blow up. And this is something that you have to be careful of. Let's try to watch it. Let's see if we can get in there quick enough. See real time. So if you had really long jobs, you could watch where the job was along the way. Wait, it, oh shoot, it's green. What? Everything's fine. You know why? Because it worked. It just didn't do what we wanted it to. Yep. Echo ran successfully, but it didn't print what we needed it to print. That's because we didn't have a secret for it to print. And I also think I need some quotes. There's the other piece behind that. Oh, no, it just didn't print anything, right? Exactly. We didn't give it anything to print. Basically, it did exactly what we told it to do. Go get this thing called secrets person and print it. So when it looks like this person, it's not there. There was nothing. So it printed exactly what we told it to. So in that respect, y'all, when you're messing around with secrets, if you mess this part up, like if it's on an echo and you keep going, what's going on? It's just, it's not going to blow up on you. It's going to say it's not there. What's not going to say it's not there. It's just going to say, yeah. And the reason is simply because the echo command returned an exit code of zero, right? So it returned and said I was successful. GitHub actions doesn't know if it did. You wanted it to do those that echo didn't break. So let's fix it. We go into settings. We scroll down to secrets. We click on actions and now we can add a new repository secret. We're going to call it person and I'm going to give it a value of GitHub boot camp. So here's the thing. Just like your personal access token. This is the only time we will ever see this. When I click add secret for your security folks, it will encrypt this before it sends it back to GitHub. The encryption happens before it gets transmitted across the wire. Okay. And it's going to go away and then we're never going to see it again. We're never going to be able to, we can add, I think we can edit it, but we can't ever see this value. This is the only time we'll ever see the value and it got encrypted and it's gone now. Is that, does the repo is mad? I hate to say this man because everybody, please excuse me because I'm about to throw him a question. He may not be able to answer. Do you know if this thing has any compliance standards that it meets like GDPR or anything like that that we could talk about as far as storing secrets? I have no idea, but knowing who some of the clients are, I'm going to say it has to. Okay. Yep. That's what I figured. That's what I figured. So I just wanted to let you know how much I'm allowed to elaborate on that. Oh, that's fine, dude. No, if they've got letters of attestation out there, they'll do it. So anyway, what I wanted to say on that was this, if you're using this for like a production project, let's say you're doing like credit card processing. So you've got to follow the PCI DSS rule set and regulations. You go check the GitHub information about what they're clear to use. Okay. Same thing place like AWS Azure GCP. They have all those letters of attestation showing you what they are, what sort of workloads they can handle. Check this as well. And just to scope that back into perspective a little bit too, remember GitHub deploys GitHub from GitHub. That means all the stuff that GitHub manages, like actions, secrets, processing, payments, all this, they use repo secrets to deploy GitHub. So like GitHub dog foods their own stuff. So if I hit update, I can update it, but I can never see that value again. It's never going to show up again. Okay. But now inside of the runner or inside of actions, I could trigger another runner. And I'm sure there's going to be a follow-up question of, well, how does GitHub actions know the secret then? Right. And it's the context. The context is able to pass that over to GitHub actions. It passes it encrypted. And then once it gets to the actions runner, the actual VM is called the runner. Once it gets there, it decrypts it. And here in the logs, it masks it. So you'll never see it, right? We echoed the secret. You'll never see it. So doing it like that, not super helpful because echo worked and it echoed the mask value of that secret. You never, ever see it. But it's something to be aware of that. If this was JavaScript, for example, and I read in a secret environment variable or something, and then I told JavaScript to print it, I could get away with that, right? The way the runner is configured, it's not going to do that. That doesn't mean developers can't screw up and show this stuff. So if I really wanted to close this out, one last thing, if I really wanted to present to you guys, hello bootcamp, I could configure an environment variable in here, and I could do it at any level, but for right now, I'll just put it here, and I'm going to call this person, and that's going to be GitHub bootcamp. And then down here, I could call env.person. Oops, not save, wrong one. Commit. Commit to mainline. Yeah, that's right. I know, I know. We're reckless today. So happy to see trunk-based. No, it's only in the aspect of time. Well, I mean, trunk could be your dev development. That's a point in contention between Matt and I, because there's metrics out there right now that say some of the best DevOps organizations are using something called trunk-based development. That'd be good homework for y'all. Look up trunk-based development and see what it is. Yeah, and their dev branch might be their trunk, right? Yeah. Like who knows what trunk is. Yeah. So, boom, we come in here. Uh-oh, sorry, wrong button. And there we go, get a bootcamp, right? So we've seen how we can pass some environment variables and configure them quickly. We've seen secrets quickly. Tomorrow, we're going to take this to the next step, right? We're going to, I'll tell you what we're going to do. I'll pull it up. Just let's build some excitement. Let's get you going. What you going to do, Matt? I'm going to spill the beans. Some workflows we're going to take a look at tomorrow is automatically checking the links in your documentation to make sure they're still valid. Like think about how much time is wasted maintaining documentation. We can automate that. We are going to put a small application in this repo and set up a CI pipeline for it where we're going to run tests. Then we're going to create a Docker image from that application all automatically. I'll show you how to deploy that to ECS, but we're not going to tie that connection in. And then I'm going to give you a little homework or actually this is going to be like part of a workshop thing where we're going to use actions to dynamically update our profile read needs, which is going to be pretty cool too. So we got a couple of cool things. And then the last one is going to be scheduling a weekly sync for your team. Instead of you coming in here every Monday and opening an issue, we're going to set up GitHub actions on Monday before work starts open an issue for your daily or weekly standup. So we're going to show automation as it applies to everybody as much as we can because there is no limit. So that's kind of all tomorrow is going to be is just pure action, awesomeness. And that's it. Have you all got any questions before we break for the day? Y'all still here? Yeah, it looks like there's one right here. Oh, no, I already answered that one. Yep. You already answered Benjamin. Matter of fact, on that last thing, y'all, that's how I do automation for infrastructure builds with AWS. The way that I write to the, if you may not know anything about AWS, in order to be able to write in there, you have to have something, if you're going to do it programmatically, it's something called an access key and a secret access key. And they're just strings of text. So what you do is that, like if you're using Terraform, you use actions like this to write. There's the Terraform module right there, as a matter of fact, you would store those secret key and secret, pardon me, access key and secret access key inside the secrets right there and then just call it dynamically. Nobody's going to see what it is. Nobody can see what it is, but it's going to allow you to quickly throw out infrastructure into your environment. Yep. Here's an example, which we'll cover a little more in-depth tomorrow, but that hits on that. They set up some environment variables and nothing stops you from coming into this and saying, not that, don't do that. That's garbage. Wow. secrets.aws region, right? Like you could set up a secret called that, pass that secret as an environment variable and then call that environment variable somewhere else. They have it right here. So there's a ton of realistic reasons and things to store in the secret or in the GitHub secrets, and you can mix and match. However, it might be, the problem with doing it like this though is pumping it into an environment variable is if you're printing stuff to the terminal, you might leak it, right? So it's better to call it directly to ensure that it stays masked. And also on top of that, if you do something like that, let's say like with the configuration of what region you're going to use inside AWS because you just can't echo it back out, you're kind of in a pickle. You're almost down to the point of let's just create a goofy bucket and figure out where it goes. Yeah, you're going to get some logging though. So whatever the AWS errors are, you're going to see it here. So it should be pretty clear where you screwed up. You'll get it in the errors. This shows you much more than just echo. Like here's an example. Here's this setup. It gives us information about the operating system. It reads this secret that's always present to figure out the permissions that this virtual machine has. Same with like completing the job. Okay, bad example. But if we were to come back to 20 bucks, if you can guess where I'm going to go, pandas. If we came back to pandas and we looked at their actions, look, they got some running right now. This is kind of fun. Let's see. Look, boom. This is where they're currently at on their checks. And you can see they actually have a couple errors. Right. So these are errors that are showing up. If they come into this benchmark, let's see. Like we can see the individual steps. We can see the output. Oh, oh, see, we're good. So it like, let's say the AWS CLI returns a JSON object that gives you good information. You're going to be able to see that here in the logs. So you're going to be able to figure it out, hopefully from that. So yeah, same like checkout is going to be, it initializes to get repository. It really runs, get a knit. And then like, these are the actual get commands that you would see in the terminal. So there's a lot of ways to figure out where you made the mistake, but that's advanced actions. And this is GitHub for everyone. So any last minute questions before we wrap for the day? Nope. All right. I will leave you with one last thing. If you want to look at a cool actions marketplace thing for my DevOps people. Oh, yeah, we'll do that. So I knew a guy, my mentor as a matter of fact, was going to get for an interview at Packet, which is a bare metal cloud provider. And I was talking to him about actions and I spent some time interacting with Packets API and building up workflows that would provision infrastructure using their API in GitHub actions workflows. So if you just search for Packet on the marketplace, just to kind of get an idea on what some of the things you could do are, you'll come to some of my repositories that show a custom built. See here, secrets, packet API key, it's there. I would need that repo secret in my repo, but you can come in and take a look at all the different things you could do and fire this all up and play with it. So you can just get a better infrastructure idea, I guess, if you look at something like this as well. So, pretty simple. Good morning. Good morning. Good morning, everyone. And welcome to day three of the INE GitHub for everyone boot camp. Glad y'all can make it. Glad you're here. Before we get started, there was actually something Matt, Adam, and I were talking about just before we got started or got online that we were talking about that we just wanted to talk about briefly. First of all, biggest thing, thank you all. Thank you so much for showing up for being part of this boot camp. This is the first time we run this particular boot camp. We've sort of been exploring what we could do with it, doing some things that are a bit unusual and really doing our best to hold back our personality. So I hope you don't mind, we got a little strange in places, but just trying to make things better. Second of all, don't think for a second that has not occurred to us, that if we could have done this boot camp in person someplace, all of us in a room, it would have been hysterical. So I think more than that is just really showed us how much we appreciate y'all showing up and how much fun and how to have you interacting with us. And third of all, this is a big favor from Matt, Adam and I. About our second break, I'll send you out a link, or Adam will send out a link in the chat, where you can go and let us know how we did. You can rate the class, there's some fields in the form where you can do some free text, give us some ideas, maybe something you liked, maybe something you didn't like, and we will go through those. So anything that you can give us on that, please, we will be looking at those, we will seriously look at any of your considerations or recommendations as ways of making this boot camp even better. So with that said, again, good morning, everyone. I'm glad you're here today. Hey, Matt, what are we doing today? It's Friday, Brooks. We're not doing anything. What are you up to? Yes, even better. How about a big cup of shut up then? I like this. Today, we are going to take a look at actions. We're going to go a whole lot deeper into the action side of things. We're going to set up a couple of different workflows and we're going to play around with some pipelines as it goes to applying these to a GitHub project. So this is like the A to B, A to Z type approach then. To a degree, for us in the limited environment that we do have, it's going to be the A to C approach. There's still a whole lot more to come after this. There's some stopping points for us, largely in the sense of like, we're not deploying to a cloud provider. We're not pushing things in places that we might usually, if it's a production project, we're just solidifying some concepts that you can then expand upon to get to Z. You'll have everything you need to know to go from A to Z. We're just going to stop at C, because again, this is GitHub for everyone and not GitHub for DevOps engineers or developers or cloud practitioners or whatever. So there's a fine balance that we must find. And then flip side of that, it's Friday and we all know the rule, right? Like no deploying stuff on a Friday. Come on, man. That goes right in there with make sure to back everything up. You should also restore your backups on Friday and just don't have a weekend. That's kind of what we're after. So we're not going to risk anything. Advice from pop-up, y'all. Backups are for punners. Don't do it. All right, so that's where we're going to go. So you guys probably have the Waffles repository. You stuck a fork in the Waffles repository. That is the repository that I'm really hoping you follow along in, okay? Brooks and I, we're going to work in the GitHub for everyone repo because we need to get your notes set up. If you were to fork this today, you're like, man, that's a liar and I'm not. I just did what Brooks told me. So the truth of the matter is, we don't have anything in there for you right now and we need to put stuff in there so you have notes. So we're going to be working here. You can work in Waffles and then we'll let you fork this one and you'll be good to go. It looks like we got a comment here. Patrick's got a good point. Yeah, yep. I think that that is probably something that is going to be worked on. I know we've talked about it within our team a little bit on being more targeted. So that's something you can keep an eye on on the INE platform for. I'm not sure if there's a newsletter or something that can get sent out around that type of thing, but INE Live is a thing where big announcements typically come out. So if you tune into INE Live, you might pick up one of those announcements that a targeted class exists. So yeah, the good news is GitHub actions for as complicated as it is to figure out what to call stuff. It's actually really simple to pick up. Like once you build a couple of small pipeline things or small automation pieces, you kind of understand how it all fits together and it's got a low learning curve. So getting to those more advanced scenarios is quite simple once you get the basics into it. The problem with GitHub actions, I'll say this and it hurts my heart to say it because I love GitHub actions, but I'll say it is it's young. It's like this iteration of actions is like two, maybe three years old at this point. There was a, so this what we're working with is called Actions V2 Insider Info. It's called Actions V2. Actions V1 existed for a while and it was a lot different. This V2 of actions has only been around for like three years and it is changing as fast as the GitHub website, if not faster. It's one of the most developed features at GitHub and I feel like every time I go to get back involved with actions, I have to relearn something because they've added a new feature. For example, like composite steps wasn't something that existed when I was becoming an expert on it and now that exists. The ability to share workflows didn't exist and now you can set up like template workflows within organizations to make them a little bit more shareable, even though they're not as shareable as they should be. So I would expect next year probably for that to change, right? So Actions is still really, really young and it's going to change a lot. So if it's something you're interested in, the downfall is you got to stay plugged in or else it'll move past you way faster than you're ready for. That being said, if you're feeling the burden of having to learn a new pipeline tool, I'll give you another pro tip insider info thing here. Hey, here we go, folks. If you come from the Azure Pipelines world there's a really big similarity without saying things too directly here. There's a giant similarity between Azure Pipelines and GitHub Actions. So if you got some Pipelines experience, Actions should be something that comes second nature. It's almost going to feel like it's Azure Pipeline. I feel really close to Azure Pipeline. So if you're stepping in what I'm putting down and you got that experience, you should pick this up quickly. Also, I'll give you all some other insider information. Like Matt mentioned to us on day one, there's other products out there that exist that do kind of a GitHub-ish type thing. What I'm very familiar with is the one inside AWS called Code Commit. I'll be absolutely honest with you, going out to so many companies and talking about AWS. I typically see GitHub. That's going to be one of their main pipelines. That's how they do stuff. Unless they're really into the whole, they're going to use something like Travis or some of the other systems. They're going to use Jenkins, where they've just really got an investment in it. You're typically going to see this right here and nothing that's specific to a particular provider. I'm so glad you said that, Brooks. That triggered something in my head. I don't know how released this thing is yet, but in the docs for Actions, you'll find a bunch of guides of going from Travis or from Jenkins or from Circle into Actions that'll help you convert existing things if you find that this is better for you. I know a lot of organizations are trying to bail on Jenkins just because it's extra overhead to deal with, but there is a team most likely still at GitHub that was working on a tool to automate the migration of those Jenkins-Travis Circle pipelines into Actions workflows. I think they were targeting pretty much enterprise customers. It was a really cool tool. I got to hang out with them a little bit, do a little bit of dev work with them. It was a lot of fun, and that tool was becoming really robust when I departed from GitHub. I wouldn't be surprised if in the near future, there's some sort of public release of something like that to where you could easily just point to your Jenkins server and get GitHub workflows out of it as a conversion process. That'd be a big win for some teams, man. I mean, there were some teams I worked with back in the DoD. They would do it today because that thing has become such, just like it's become its own problem. It was supposed to help, but it's become its own problem. Yeah, it's like managing a whole new system, man. Jenkins is crazy, but nonetheless, and if you're another insider info before we jump into it, and then we'll jump into it, I promise. If you're wondering if GitHub actions is mature enough, even though I just said it's really young, if you're wondering about its maturity level, consider this. Microsoft owns the rights to Minecraft. If you don't know what Minecraft is, it's this Uber popular video game. Hundreds of millions of users, I'm sure. It is a very complex build system that they have going on in the back because Minecraft deploys on every major video game console. It deploys on mobile. It deploys on PC, and all of that testing in build step stuff is all on GitHub actions. Microsoft has completely moved Minecraft over to actions. If they're banking on that, that's a pretty good indicator that it can handle the load. I think when we were talking to that team, they said something along the lines of it's like 120 virtual machines at any given time to build Minecraft. It's absolutely crazy. So it will scale to what you need it to do, even though it is still a little bit young. Dude, that's ridiculous. 120 to build that thing? Yeah, yeah. And that was the first major project that was the alpha test, essentially, for the tool to convert from Jenkins into actions. Wow, wow. Yeah. So if you're wondering, can my workload handle it? Ask yourself, is your project as big as Minecraft? If the answer is no, the answer is probably yes. Dude, it's so sad that a game that my grandkids play requires more heft than some enterprise applications, but it really does. It really honestly does. Yep, it's incredible. A couple other things that are built with GitHub Actions. I'm pretty sure the GitHub CLI that we pointed out, I'm pretty sure that's built and deployed via Actions. The GitHub mobile app is built and deployed via GitHub Actions. So that builds across Android and iOS, right? So that's anyway, the point is it has the flexibility. It is young, though. So if you're not plugged in and you don't keep up with it, it can burn you kind of easily, I guess. So stay plugged in. That's the answer. So we're going to go ahead and get started. We're going to get off that soapbox. We're going to get started. The first thing we're going to do is we're going to do a little bit of reiteration here and drive these points home that we've been trying to make. We're also going to move really, really fast. So if you have questions, make sure you ask those questions along the way because we're going to move really, really, really fast and then we're going to do something sort of cool. So first things first, we need to start some work. What's the first thing we need to do if we're going to start discussing work? Okay, okay. I'm not even going to answer this one, y'all. Normally it's Matt and I going. So I'm going to look into the chat now. What's the first thing we do? Anybody? Gosh, this is when I wish as we were in a room. And all right. First thing we're going to go start work. So it's work. So what's the first thing you do? Do you start adding? Raising issue. Perfect. Cool. Let's do that. Make Benjamin. Love it. We're going to create a new issue. I always said that too. We're going to raise an issue on you. This issue is going to be configure a GitHub pages app. Okay. So first thing we're going to do is let's make sure we understand pages. We will deploy a simple page. Okay. Cool. All right. Another piece of work that we're going to do. We're going to open another issue, right? Because we're just going to stage all of our work for the day right now. We are going to add a non-static web app. Build an app that uses Express.js to add some numbers. Cannot deploy to pages. Now, there's a reason why I'm opening all of these in issues, right? You get to fork the repo. You can also always come back to this repo because you're probably not going to get the issues that come along with it. But if you ever come back to the parent repo here, even after we close these, you can dig through history and see the things that we did in this course, right? So second thing is we're going to configure a CI CD pipeline for our server-based web app. Mm-hmm. That sounds serious. Set up testing because Matt can't code. Set up auto building Docker image. And then host on GCR, which is the GitHub container registry. So my DevOps folks, GitHub has a container registry. You'll see it if you ever see if we're over here and you see packages, you can have Docker images and or like NPM packages. Matt, let me jump in and ask you a question. And by the way, y'all, this is honestly goodness. This is a question that I'm asking around the top of my head. Matt and I didn't discuss it beforehand. So I have no idea where this conversation, but let's keep it real tight here. Just take 30 seconds if you would, Matt. When people start putting issues in and the issue they write stinks, like it, it was awful. Is this still the right place to have the conversations about, hey, the one that we did about add a non-static web app, we need to change what's in the text of that. Yeah, I can come. So you could say, hey, like, I don't understand what you mean, right? That's a fair thing to say. Can you elaborate more? Hey, I think there's a template for issues in this project. If you want to add a feature, can you close this issue, open a new one using that template? These are all acceptable conversations. So these are all conversations and they're not only conversations about what the subject is or the issue is, but it's also a conversation about maybe this issue needs to be redefined or touched up or tightened up a little bit more. So yeah, that was the thing that was curious about y'all was as we raise issues, persons who maybe aren't familiar with technology, they'll tend to say things that are just a little off base for what we really need to do. And then that's when, you know, step back into the issue and try to get some clarification on what you're talking about. Yep. And let's say that happened in this one. Let's say Brooks was like, I don't understand what you're saying. I can just come in here and I can edit this directly. So sometimes I don't even have to close them. I can edit this and say this is just an example for using GitHub Actions. Okay. Right. And I can update that. So it's totally okay to have that conversation. Cool. Hey, Benjamin asked a question. Why should we use GCR, GitHub Container Registry, instead of Docker Hub? Couple reasons. And I think we're going to reform the question. I'm not saying you should use GCR instead of Docker Hub. I'm just pointing out that it exists. So we'll start there. Second to that, why not use both? Like maybe you need some redundancy. Third to that, Docker Hub is, I think it's really limited for private image repositories. If I remember right, I think you get like three of them. Yeah. It's about three. Exactly. Yeah. Whereas GitHub, I can have as many private images as I want. It's one image per repository. Another reason that I think GitHub GCR is good is that my code for the image lives right next to the image. I'll show you. That's a good point. And so this is one of the major things I like about GitHub. So same thing for GitHub Actions. Why would I use Actions over Travis? Or why would I use Actions over Jenkins? Well, it's all in the same spot as the code. So we've shifted everything left again, right? So we're eliminating the number of tools we need to go out and get. So here's packages. These packages are associated with repos. So here's a repo that has this package associated with it. And these are the different versions that got rolled for it. So these are just different ones. So I can just click that and say, okay, well, what's in this package? All of this is in this package. And here it is right here. And if I click into that, I can get the Docker pull for it or whatever. So the other thing would be, I showed you yesterday, secrets management with GitHub Actions, right? So to push a Docker image through the Docker Hub with Actions is 100% possible. You don't have to use the GitHub package registry. You can still use Docker Hub. But what you need to configure if you're going to do that, I'm sorry, I got an eyelash in my eye. It's killing me. If you're going to do that, you need to configure repository secrets with your Docker authentication information, right? Because you have to log into Docker before you do the push. If you're using the GitHub container registry, so maybe you don't want to configure that secret, it's totally fine to configure that secret. Like the secrets are going to be kept okay. But maybe for some reason you have a policy that says you can't. In that case, I don't need to configure external authentication mechanisms to upload something to packages of the GitHub container registry. Actions has a very special authentication account that exists. It just exists. You can't do anything about it. It's always there. And if you use that, one of the permissions it has is the ability to create packages. So you would never need to put personal access tokens in there, right? You could always use this special token called a GitHub token. And you might be like, well, I don't like the fact that this GitHub token exists. Like that's scary. Like what if somebody compromises the GitHub token? The cool thing about the GitHub token is it's ephemeral. It exists. It gets created at the time a workflow run kicks off. It exists for the life of that workflow run. And then it gets destroyed and it never exists again. So it's a token that can't be leaked. It'll never cause you problems in the long run. So should you use GCR over Docker Hub? Absolutely not. Should you use them in tandem? Probably. It's always good to have redundancy. Does that mean we can't push to ECR? Like no, we could put that on Amazon's container registry. We could put that on Google's container registry. I just, since it was a GitHub for everyone, keeping everything on GitHub, that was kind of the goal is to show you GitHub and not to show you the Docker Hub. But I'm definitely not saying use this instead of that. Just that here is another option. And I personally really just like having it all in the same spot. Like I just log into my GitHub account. I can come over to packages. I can say, oh, like I need this. And I can click that and it should give me my pull. Right. I get all the auto tagging. I get all the metadata I can dig into. I think like what chains, if I click these, whatever, there's a bunch of stuff that comes along with it. I can see the manifest. Docker Hub's a little nicer because I can like, in it to some degree, because I can quickly see like the Docker file for a tag, but like arguably, like I can quickly see the Docker file here too. And it's honestly not that big of a deal. Right. So like I can see everything that goes into this specific image because it's all in one spot. So it's how often do you want to bounce between tools? It's up to you. I think it also depends too, when you say I've been on your target environment too, because it's kind of cool that you can sit in GitHub. And then you can go, okay, we're going to go to AWS. We want to go to GCP. We want to go to Azure so that, you know, you can really say, hey, we are a multi cloud situation because if we find that for some reason, we don't want to host this over there anymore. All of our stuff sits on GitHub. So we can always just fire it right back out versus being locked into it. Not that there's anything wrong with it. It's just it does seem to breed into the culture, the idea of we're not going to get locked into using just one framework. I don't like the idea of saying we're going to get locked into a vendor because most of the vendors will sort of put into your mind a certain tool chain, their tool chain. Whereas if you own the tool chain, you can say this is where we want to go today. Yeah, exactly, exactly. Okay, back to our issues. Great question though, like genuinely great question. It just really boils down to personal opinion rather than targeted technical answer. And it's not an apples to oranges thing, unfortunately. We got we're going to do set up a scheduled issue to help with team meetings. Hey, that's cool. Automates a daily or we'll say weekly stand up issue. Okay, so I think that's probably that's probably what we have prior to the cool exercise. Okay, so now we have our work, we started our work. Okay, so if we were going to go ahead and begin doing one of these tasks, what do we do now? Let's see if anybody gets that in chat. What do we do now? So we've raised our issues, we've got them in there. Pretend we've collaborated and we have agreed. I'm going to pick one of these issues to work on. What do I need to do? It probably rhymes with plan a tree. The worst part is like 12 of you stuck around for 12 hours of my ridiculous nature. And that's impressive. Bad humor. All right, I'm not seeing anything come through. So we're going to move on anyway. We're going to create a branch, right? That's the next step. Create a branch so that we can start the work. So I'm going to come back to my code tab. I'm going to make sure I'm on main. And I'm going to create a branch. And I think the first thing we're going to do is we're going to schedule that sync. So not capital, schedule team sync. That's going to be the name of this branch. It's very targeted with what I'm trying to do. I want to create that from main. And now I'm here, schedule team sync. Let me tie this back to yesterday if I can, Matt, to make sure that I understand this correctly. So that issue, is that what we would consider to be a feature? And what we've just done is create a feature branch. Yeah. We could definitely call it that. So let's do that. Let's come into, we're going to schedule our team sync. We're going to add a label. We're going to call that label. Doesn't exist. So we'll create it just like that. We'll give it blue. That's cool. So this is going to be a feature, right? And we're not going to add it to a project board or any other fancy shmancy stuff, but to help draw that association, absolutely. So this is going to be a new feature for our project. Maybe not. We might not use the word feature. So like, because feature to me in my head applies to an application, right? Like it's a new, a new thing. So let's say, oh, you know, maybe we don't like feature. We had that discussion in our team meeting. Let's call it an enhancement. Gotcha. This is an enhancement to our project. It doesn't try to, we can kind of treat it the same way though, right? We just need to absolutely treat it the same way. Yeah. Yep. Yep. So now we have a branch that if we make mistakes on, that's okay. We'll just delete it. It's not a problem. And whatever was deployed on main plot twist, nothing. It's not going to break anything. So we have our branch. This is going to be a really nifty workflow file. Let me get it all copied over here and then I will talk about it. While he's copying that over, y'all, please don't, please don't, please don't miss the point here. That is, you know, obviously I'm sitting here. We're all sitting together. I can see what Matt's doing here on my screen just as well. If I was, if I was disconnected, if I was just sitting here, I can still see the same thing. I can look in GitHub. I see what the issues he's creating. I can see the branch he's created, all that's right there. It's like the most seamless communication. And it really boils down to pure communication, not all the extra stuff. We've created four issues. We have a branch. Just pure. What are we doing? Yeah. And look, your team manager come by and said, what are you working on? Right. Project manager comes by. She says, what are you working on? Like, go check the issues clown. Like, I don't have to tell you this. Like we don't have to take an extra 30 minute meeting just for us to update you. You can take a five minute cruise over to the repo to see what's going on. And eventually you will train them to do the right thing. Yeah. Get a clicker, you know. So I have what I needed copy to my clipboard. Does anybody remember where I need to place a workflow file by chance? This is something I always forget. But workflow files have to be somewhere really specific or else I can't use them. This is a good one, y'all. Can you answer that one? Where do you put a workflow file inside your repo? Come on, somebody, guess. I don't care. Some directory solid choice. Let's see what happens when we do some directory. So we're going to create a new file on our branch. Okay. That's the important part. The hinder. Put it in the dot. Okay. We'll call it weekly. There you go, y'all. Nice. Think. Yep. Dot YAML. I'm going to paste this in and I'll talk about it in a second. I just want to get it. I just want to get it in there. Cool. So if I come to actions, hmm, something's wrong. I don't see it. I see the one we did yesterday, but I don't see the one I just added. Shocks. I think I'm going to get fired, Brooks. So I don't know where I'm putting files. So here's the thing. That doesn't work. It's not in that workflows folder, which is why it didn't show up. It has to be in dot GitHub slash workflows or you cannot use them. So everybody got that dot GitHub workflows. But this makes it shareable. So like you could kind of shareable. You could stage a bunch of these in a repository and say, this is our workflows repository. Go grab the one you need as you need it and it will never execute. So we're going to move this moving files in the UI is a little bit tricky. Yeah, it is. So I'm going to show it to you because it's definitely a major gotcha. You click into the file so that you can read it and you hit the edit button, which makes no sense, but that's what we're going to do. And then you can edit the path and then I can commit it. So let me go ahead and talk a little bit about what's happening before I commit this and we'll walk through what this workflow file is. I'm making it a little bigger for you. Yep. That looks good, man. To do this. The UI just went horrible. Okay. So this is a third party action. Okay. We're going to use a community developed action. You can find this action and get a marketplace. Is that a bad thing? No. Is it scary? Maybe. Right. It depends on what your constraints are. Is it going to take you a long time to go read what's in this action to figure it out? No. Ask a developer to do it. It'll take them 20 minutes. How do I know where this action is? Well, right here under the uses tab on line 20, right here, this is the namespace and this is the repo name. So if I just copy that and I go to github.com slash that here is the repo where that, that action lives. So I can look into it. I could read up on it. I can see how to use it. Whatever it may be, right? Here's all the information about how to use it. Here's examples. So if you're ever looking at a workflow and you're like, I need to know how things work, that's how you can find that out. Okay. So let's talk about this from the top to the bottom. The name just names this workflow. We could name it whatever we wanted. If we don't name it, the name is the name of the file. So the name becomes the file name. If we don't name it, I like to name it. I think it's easier to find the on declaration is the trigger. Okay. And we showed you the trigger of a workflow dispatch yesterday. Events that trigger workflows. I also showed you this massive document of all these triggers over here on the right hand side. Yesterday, we used a workflow dispatch, which to manually trigger a workflow, use this event. I am going to set this one up as a watch event. A watch event happens whenever somebody like adds a star or clicks the watch button on a repo. I'm going to use this event simply because we're not going to wait until next Monday for an issue to be opened. I'm going to try to show you a couple of different events today. Typically, you would run this one on a schedule like I have here and it uses the standard Cron syntax. So if you just go to like a Cron converter, convert Monday at 9 a.m. into Cron, and you can place it right in here and use a schedule as a trigger. Jobs never changes. It's just a declaration of the jobs that need to be done. Jobs that need to exist. A job is a collection of steps. You can have more than one job, which we will a little bit later. This job is called create issue. It has a friendly name. This is just for the UI. You can remove that and it will use this as the name. This is just for the UI to make it easier. For each job, and this is important to know about actions, each job is ephemeral. So each job will create a new virtual machine, which means that jobs do not do very well at talking to one another. So pretend I had a job that was save this file to the hard drive and then I had job number two that was read this file from a hard drive. Job number two will never, ever find that file because it got destroyed when job one finished up. Is there a way to pass data from one job to another? Yes. We're not going to get into it here, but it is possible. Jobs can set outputs and other jobs can read those outputs. Is the short answer. Jobs also run in parallel, meaning job one and job two run at the same time. This can be a problem if job two is dependent on job one. GitHub actions allows you to create that dependency. You can say job two depends on job one. So these are things that you can work around that we're not going to dive much deeper into than what we just did. Okay. But that's where we're at. So we have some, we specify the virtual machine operating system we want this to run on. All this action is going to do is make an API call to GitHub. So I don't care if this is on a Windows machine, a Linux machine, or a Mac, it's an HTTP request. It can happen from a mobile phone for all we care. So Ubuntu is the cheapest and fastest option, which this is still free because the repo is public, but either way, we can limit the permissions that this machine has to the API or this rather this job has to the API. In this case, I think that's a little outside of the scope. So we'll just delete it and we'll let it have the default permissions and it'll be okay. I hope we'll see. If not, I have it over here. I didn't test this. So I could be wrong. And it should be because it uses that token. So quick recap, we got a name, we got a trigger, we got some jobs. We got one job that's going to start a virtual machine on Azure that runs Ubuntu. That job has steps. Steps can have a name. They don't have to have a name. Again, this is just UI. In this case, it uses timeout pause, hold up, wait a minute. Uses, remember yesterday uses meant that it uses in action so that self-contained source code, action.yaml, maybe dockerfile, it's not calling a terminal command. It's just an action. So in this case, we're going to specify this action. And I already showed you that this is just a repository, but I didn't talk about this part. So in order to call on an action, to say I would like to use an action, you need to specify where it lives and a reference to it. In this case, that reference is a specific commit. Remember every commit gets a shot. We can look at that over here. If we were to go to commits, I'll zoom out just a little. And we picked this one right here. This one has a commit shot. It's right here. So I can specify a specific shot, which is helpful because if the developer of that action makes a change, it doesn't affect me because I'm pulling it from this state alone. And always this. Another thing I can specify when using actions is a release tag. So in this case for pandas, if I pretend this was an action, I could say at v1.4.1 and you'll see this with some of the checkout actions later. We say at v2 and you're like, wait a minute, v2 is not a big long hash and you're right. So I can specify a release tag, I can specify a branch and I can specify a commit shot. So I could say at main that gets scary though, right? Because main can change. Right. Oh, it's highly recommended that you use either a release tag because that is never going to change or a commit shot. Now, a release tag is just an alias for a commit shot just for whatever that's worth. So it just becomes a little more readable. I don't think there was a tag associated with this shot. I just went with what they recommended on their own read me. So we're going to pull from this one. Yeah. So really in this put, this is that place, Matt, where we're talking about, you know, if they're out there creating important workflows that have got to work right. This allows them to lock in a version. So if what Matt's talking about y'all is the idea of the developer putting what's called a breaking change. Okay. Suddenly they're going to be able to do that. Suddenly they put a breaking change in and then you don't know why Monday morning, why the thing just didn't work. So what you do is you lock it to a version. So if they do introduce breaking changes and things like that, you'll be in a good situation. Exactly. Cool. So we're going to say, Hey, I want to use that action, man. Go out to that GitHub repo, find that commit and grab that code and pull it into our handy dandy fancy Ubuntu machine. Okay. This action allows me, the user to specify some, some variables, some parameters, and it happens to be in the form of assignees, labels and a title. So we don't have Mona Lisa. Oh, Mona Lisa. GitHub fun fact. Ready? This, this cat, her name is Mona. Oh, wow. I will get my Mona when we come back. I actually have a Mona. It's really cool. Her name is Mona Lisa. So if you ever wondered if GitHub was gender neutral, it's not. It's a, it's a email named Mona Lisa. So it's very cool. Whole history behind Mona. I'll find my Mona on break and I'll bring her back. So we don't have her in our repo. So this is, this is what can trip us up. We don't have a username Mona Lisa. We don't have a username Octo cat plot twist. This is not a cat. It's an Octo cat in another GitHub fun fact. I guess that's just goofy. Look, it's actually got tentacles. So it's a cat head on an octopus body and that's Mona. So it's an Octo cat. So if you ever see that, it's actually just a reference to the GitHub mascot. And then Hubot, we don't have either. Hubot is like a, just something you can configure, kind of like depend a bot. He's really annoying and tells you to merge your pull request. But we do have Brooks Seahorn. That's me. Okay. And we do have me and this action expects this to be a comma separated list. That's not true for every action. That is just what this very specific action requests that we pass to this value. Secondly, labels, we don't have any of these labels, which might cause this to break. So we're just going to say bug because I know that label exists. And we're going to give it a title and we're going to call it weekly, weekly team sync. And in here, they let us pass some markdown. So we're just going to leave it because that's fine. We will delete this link though, because I don't want that to break. And pinned means is it going to be pinned? That's false and closed previous. That's false, which would close last week's when this one opened. Okay. And lastly, we need permissions to interact with the GitHub API. Well, here is that super secret GitHub token. Remember yesterday when we managed secrets, we had the secrets context. We had to go into a repo and add a secret. Well, that's where this GitHub token comes from, but you don't have to configure it. So it's your repository always has one secret. You just can't see it and it's the GitHub token. And that's what the permissions up here were that we deleted. Those were the permissions that we're going to be assigned to the GitHub token. So we could argue that right now our GitHub token is over scoped. That's okay. The GitHub token is ephemeral. That doesn't worry me as we go forward. So I am passing that in as an environment variable to the virtual machine that this action then references. Is that always going to be the case? No. This is the difficult thing with actions is the creator of this action decided that's how they wanted to read this variable. It could have very easily been passed in as a parameter. Did they do it the wrong way? No. Did they do it the right way? No. That's totally up to how they chose to develop the action, which is why it's really important to go to the repo and read through their read me because they will show you how they're using these things. All right. So now we've moved it. We've talked about what's in it. I'm going to commit these changes. Let's see if we can see it. Let's go to actions. Still not showing up. Okay. So we've got it in the right place. The file looks good. Right. Everything looks good. So what are we missing? Actions is a little fickle. That's what we're missing. There's another secret and that's certain events only apply if they're on a default branch. So since this workflow is on our branch, it's never going to show up until it gets merged into main. So, okay. So we've got a feature sitting out there or feature or a, what was the word we used? We got an enhancement. We have an enhancement that's living on a branch. We did our workflow. We created our GitHub. We got our workflow file. We put our YML in there. We've done all this. This is on a branch. It doesn't matter. We've got to get back to main. Yeah. How do we do that, Brooks? Magic. It's got to be magic. FM, freaking magic. Could you show us? Oh, I think it's that green button. Exactly. GitHub is already saying, hey, you have some things that aren't the same. Your two commits ahead of main. You want to go ahead and start collaborating on that work now? And the answer is yes. So we're going to create a pull request. And in here, we're going to say merge team sync workflow into main. So that it runs. This PR does that, that, that, that, that, that, that, that, that, that, that. Right. Explanation, something, something good. Right. We're going to create that pull request. I think we're going to run into a problem. Yeah. Merging is blocked. Right. You remember why we set up branch protections. We said we need a review if we want to merge. So we're going to go ahead and we're going to request a review. Once we get that review, it's going to come through and we'll be able to merge. So we've requested a review from Brooks. He's going to go in and improve and then we'll be able to merge this soccer in on my side. I literally just did a refresh on my screen. I'm sitting right now under my, uh, in my inbox, which is just in the top right. It's that little bell up there. I saw a blue dot. I clicked it. Boom. I click it. I can drop right in. See what's going on. I can comment on it. LG IMO. I can do a comment on it if I want to. You see the comment there? Yep. Did you click the approve button? That's funny. I don't have an approved button and y'all, this is not me making stuff up here. For some reason I don't have an approved button. Yeah. It's, it's so hard to see and I'm glad you're running into that problem because this is something that I've missed a million times, which is the only reason I know where it's at. You got to go to the files, change tab, then you get a review button and then you can hit approve. Does everybody see that back it up, Matt, back it up. Let them see it. Show me, go take it back up. So you see there, this is what I saw basically all. I did not see like, if I scroll down, there's nothing like the approve button and that's the thing is going to burn you. You're going to be in a situation. They're going to say, go ahead and approve it. And then you're going to be going, where is that button? And you're not going to want to say anything because you feel like you should know where it is. In this case, that's where it is. Look at the menu. You have a number one there. Obviously something's up. Go click on it. Yeah. So the, the mindset behind this is if we gave you an approve button here, how many people would just click approve to get that notification to go away? Or how many people would just click approve just so they can move on? This forces you to actually see the change, whether or not you read through it is up to you, but at least you see the change. And now you can click review. So I'm going to go ahead and, I'll go ahead and move it out. That's kind of the, the idea behind it. Cool. Quick approval. As you can see, the Brooks clearly didn't read through that and just approved it anyway. So it's not like it prevents it from happening, but it's just really important to know that it's really hard to find this. And that's the worst thing about a poll request. And again, listen to what Matt told us about that. The point was, is that I could just do, you know, LG IMO and send it. And by the way, that's what happens a lot. All the time. There's a lot of software developers out there. Yo, they're going to front like they, you know, know everything about everything. When they go to read the code, they don't have a clue what's going on. They'll kind of spend an LG IMO and it'll send it on down the line. What GitHub is making us do is at least go look at it, at least look and see what change is. And so that's actually a really smart way of kind of forcing the right behavior. So whoever thought of that, it's good on you, GitHub. Cool. We got our approval. Thanks for that Brooks. We're going to merge in. Confirm merge. Do we need our branch anymore? I don't think so. I think we never know gone forever. Not coming back. There has to be, I'm going to get hung up on this because I'm, there used to be a way to restore branches. So like, I don't know. Wait, why would I do that? Whoa, back up. Why would I restore a branch? I could think of a couple of reasons. One, I accidentally deleted it. Two, maybe I clicked close the pull request button and it got auto deleted. And I need to reopen all of that. Is LG IMO a sub brand of the Korean electronics company? Looks good in my opinion. You might also see LG TM, which is looks good to me. Yeah. Yeah. Or as I like to say, let's get this money. But yeah, LG TM, LG IMO looks good in my opinion. Looks good to me. So now we're at main cool GitHub. It's in the workflows folder. So let's go back to our actions tab. Now it showed up. There it is. How about that? We'll take a look at it. Notice how the one yesterday has a button to run it. The one today does not. Different trigger, right? Yep. Watch event. So let's go ahead and I am going to change this. I don't think unwatching triggers it. So we'll refresh it just to see and then I'll rewatch it. And that should trigger. Okay. They may move this to just stars. So I'll star again, changes. So it looks like watch events now only apply to stars. It used to be, you didn't have these choices with watch. You just could watch or unwatch. So I think that prevents it from understanding the trigger. But the trigger was I starred this repository. That's it. Watch, I can un-star it and I can start again. And we should get another run. I don't know if that's going to cause conflict because we just created two of these, right? So every time somebody stars it, it's going to run. Now this is horrible. If you had a super popular project and you were triggering weekly team syncs, every time somebody starred your repo, that's not a good trigger, which is why a schedule works better for this. However, to demo it for you, I changed it to a star. There are plenty of things you might want to do when somebody stars the repo. Like say hi, for example. So if we come over to our issues, check this out. We got these two issues that were just added. Brooks and Matt are both assigned to them. And if we click into them, they have this body and they were created by GitHub Actions. So that's so freaking cool and powerful. If you have a weekly standup or a weekly team sync where you're kind of talking about the same stuff over and over or the format is the same over and over. Somebody on the team is going in there and building a document every week so that you guys can do that. You should do them a favor and not let them do that to themselves. Matt, that is such gold advice right there because y'all think about scrum standups, our daily scrum standups where we're going to keep it. Well, we should do really be doing less than five minutes. Let's say it's supposed to be less than 15 minutes. Everybody stands up. What did you do yesterday? What are you doing today? What problems are stopping you from getting your job done? One, two, three. Boom. This thing's ready to go every morning. The team's got it. You just type it in, type it in, type it in. Done. Yep. And it's super flexible, right? So like, let's show you how flexible it is. All of a sudden, we decide that the team standup is no longer, you know what we should have done? We should have linked this issue so that it closed because now I have to go in and close it. That's okay. We'll close it. And what would it take to link it? Yep. We'll do it this time. So let's say all of a sudden, our team decided this is no longer the agenda. We want to change it. Well, how easy is it to change this automation? We're going to hit new issue, update the weekly sync issue body. Did everybody get that? He didn't just jump in to changing the thing. We started an issue. This is so important because again, not only does it let you track what you're doing, but it's also a way of communicating out and up. What's the team up to? What are we working on? Exactly. So I have my issue. I'm going to come back to this one and I'm just going to close these two out. Can I close the multiple ones? I thought you, dude, I thought you could. Can you not? So many things change. This is the only, like I also only ever really use GitHub from like a terminal. Sorry. Honestly, honestly going to say, we're not goofing here to set you up for another learning like seriously, like as you weak as you use GitHub, sometimes from moment to moment, just like using AWS up, there was a change. It changes. Okay. So we have an issue. We're going to go ahead and we're going to create a branch to update sync issue. We're going to create that from main, same workflow, right? Now we're going to come into there, grab that workflow, grab the weekly sync, hit the edit button, and let's just remove these two items. And let's say we don't want this. Great. We'll commit that. We'll put a good commit message. Yep. More if you need it. We're going to commit that to our branch. We're going to hit commit. Done. Come back to the code tab. Open the pull request. And this is where we can link it to the issue. Yep. So update, weekly, sync, issue, body, super detailed reason to make a change. Over here, we then grab linked issues. So it says, huh, you can use the closing keyword. So let's say closing or I think it's closes. It's closes. Yeah. Number. And now I can come up here. Does everybody see that? That is cool. That is cool. Just that keyword throws it right up there. So you're like, oh, what was the number? Don't sweat it. Type closes on a new line. Boom, drop down. Yep. Anytime you hit that, that number key, you can reference anything. So we have issues. We have pull requests. Yep. Whatever it might be, closes will link these. Watch. So I'm going to hit create pull request. And here it is linked right here. It's linked to this issue, which is super cool. We're going to do a quick review from Brooks. Yep. I just got the pop up over here. So that took maybe five, six seconds to make it his way over. We can see who's responsible. We can blame him when it gets broken. Review me. It's been reviewed. Give me a second, man. Graham, you know what? Speaking of, this is a cool time to actually talk about this. Here's a diff, right? This is a change now. We can see what I changed really quickly. This got removed in favor of a blank line. And this got removed in favor of nothing. So that's what he got to see. So when y'all get hit with somebody over your shoulder saying, okay, what did they change? There's your spot. That's where you go to and say, this is what they moved. This is what they put in. And you can say it with, you know, it's, for those of you who maybe are new to your career, there is nothing finer than to be in a meeting or to be asked a question. You go, bam, with the information, nothing beats that. Yep. Okay. So what's cool is, oh, here's the revert button. They have, oh, wow. Okay. It's so changed. Oh, it's so different. So we merge this and you'll see this issue over here has turned purple, which means it's closed. So I can, I'm going to delete this branch. I'm going to come back into our issues. And we'll see that that issue auto closed for me. So just by typing closes and an issue number, I automated the cleanup of this repository. That is not an actions thing. That is just a regular thing. You can do it on any file. I now have the update. So we'll come to actions. Notice how like this didn't run because I didn't click this button. So like when I starred this, it has a different trigger. So it's like smart enough to not run the same thing over and over. I'll start this again. We should get a new run very quickly. There it is. Shouldn't take more than a second here. This number will change. If we really want to know like we can click into it, it's done already. This is where those friendly names come into play is here in this UI. And there we go. We got a weekly team sync. It was assigned to Brooks and I. If we click into it, it now has a different body. So it was that easy to edit our workflow to give our team a new agenda. And then it's still automated 100%. Pretty cool. That can go for so many things, man. So many things can be automated with that way. Just get the thing done. If you're doing this, if you agree with me a matter on this or not, but it's almost like, if there's this thing you're doing constantly over and over and over again, and you can see it inside this interface, you could probably automate it. Always automate it. That's my thing. So I know I just broke a lot of rules and I committed this domain, but what I wanted to do, oh, actually I don't even want to do that. I want to make sure you guys have this schedule in case you take and fork this repo, but I want to remove that star thing because I'm going to use it on other workflows. So I needed to hurt the trigger on this so that it won't work for us. So I'm just going to verify that that happened. So now there's no trigger. If I come into actions, it probably, yeah, it probably throws an error. Yeah, it's going to say if I click into that, it should give me, right? It can't be shown next run. There's no jobs. It has no clue what it's doing because there's no trigger. So that's okay. That's what we want. So it brings us to our first break. When we get back, we're going to dive into setting up probably the CICD. We'll do the pages thing last. I want to get to the CICD part and we'll show you something that's more for developers because this was definitely more for any team member that might use GitHub. So exactly. All right. So let's take 10 minutes, y'all. We are back. I was about to say, I was literally about to do, and then I was going to say all I got from AWS was a stupid t-shirt. All we got from I&E was these backdrops. Well, hey, man. These backdrops are pretty sweet, man. We're looking good. All right. So that's not true, by the way. No, it's not. It's not. This is the rig. We both clearly are wearing I&E shirts. Anyway. And also the rig. All this stuff that y'all can't say. Yeah. Anyway, yeah. That's a cool little thing. I think, honestly, side tangent for those of you that care or maybe have kids and want a cute plushie. I think GitHub operates a store. Because that's where I got this. I think it's open to the public. So I think there's a GitHub swag store somewhere. So if you want, like, stickers and plushies and silly stuff, you could probably go buy one. Just saying. Oh, man. They sure do. It's the githubshop.com. The GitHub shop. I think so. Yeah. Oh, it's just scary. You are a brave man. Oh, see? Why would you do that? Why would you do that? Look at that. I know. That's a that's a scary search. You didn't know where that was going to go. I had no clue. Cookie cutters. Yeah. So here's an entire store if you want to GitHub stuff. Okay. Whatever. I got a bunch of the coffee cups. Oh, man. $10 for 50 stickers. That's not bad. Yeah. The stickers are really good quality stickers. Just for the record. Anyway, back to it. Let's jump into our next workflow. I kind of lied to you. My bad. Blame Brooks. It's his fault. I was like, thanks for the URL, Matt. Matt B, thanks. I'm going to go ahead and I'm going to close this issue just because keeping our issues tidy. So I know where to go in today. There's one more thing that I want to do before we jump into the DevOps developer side of thing. And that is set up auto link checking. Look through our docs to make sure links work. This is a really cool thing that you can do if you're managing documentation or whatever. This is this could get a label as an enhancement. You don't have to use labels, but you can. Yep. Yep. So for that, we're going to need a branch add link checker. And notice another thing about my branch names, like not only are they deliberate, but they kind of say like what their purpose is, like update this thing or add this thing or create this thing. Same with commit messages. It shouldn't be like I am going to do this thing or pull request titles. It's I did this thing. So not updating readme.md. It's update because that's what you are trying to do. You are trying to update it. You're not in the process of updating it as weird as it is. It's kind of like a internal best practice kind of thing. A lot of projects are really strict about that. So we're going to go ahead and create our new file. It needs to be in that special spot. Get her workflows. And we're going to call this a link checker. Dot YAML. Let me just copy the workflow. No pace, please. Okay. So this is going to check markdown links. And I'll zoom in so we can read this a little better. We gave it a friendly name. It should be very familiar at this point. This one's interesting. Right. We're going to use a new trigger. This is on push. Now we haven't been using the terminal. So push might seem weird to you. But every time we click this commit new file button, that is a push event. If you're from a terminal and you type in get push, quite literally, that is a push event and that will trigger this. So what's cool about this is we say on push, we want you to run this job, which is only one. It's going to run on an Ubuntu machine. It's going to have two steps. Here's a step. And here's the step. And what's interesting about this is this is out of date. So this uses this actions at checkout. And this is a special action. Anytime you see this actions, anything, that is a GitHub maintained action. Okay. Master is not a branch name that we use anymore. Right. That used to be main, but master has turned into main. And this is just showing that you could reference a branch name. I happen to know that actions checkout is currently version two. So we're going to check that to V2. But I know that. How do you, let's find out. How would we do that, man? That's a great question. We're going to go to github.com slash paste in actions checkout. Look, it's just a repo. It's not magic. It's just a repo. And I'm going to scroll down here and I'm going to look for the releases. Hey, and I can see, I can use all the way up to version 2.4.0. Version two is going to reference one shot. And if I scroll down in here, I can read the docs on how to set this thing up. And they tell me everything I might want to know for options. They give me some scenarios, whatever it might be. And here you go. Simple as that. Okay. That's how I find that. So we're going to go V2. Then we're going to use this repository, which same thing. This is a community action, whoever this person is created this action. And the only way I know to use version one is because I went to this repository and I looked at the releases to see where things were. The only way I know what options I can path right here or pass right here is because I went to this repository and I looked at the documentation and I knew how to configure it. So what this is going to do is it's going to spin up a VM. It's going to run a git clone. So just like you guys cloned or saw me clone a repo yesterday, that's what checkout does. So all of the code in this repository is now going to end up in this virtual machine. That didn't happen for our issues one because we didn't do anything with the code. We interacted with GitHub. We didn't need to look at any of the files in the repository. So they never got moved into that virtual machine. But in this case, we want to look through files to see if the links in them still work. So we need them and this is how we get them. So this is going to basically clone them into this machine. And now we can do stuff with this action against those files. And in this case, we've set a couple options for visibility. We've said any file inside of the path docs slash markdown files that is a markdown file. Any file inside of docs slash markdown files will be checked by this action to see if the links are valid. Every time a push in the repository happens. And that's at the root of that repository, right, Matt? So right there at the root relative to the root, there's a docs directory and we're going to look inside there for markdown files. Technically, it's going to look like this. Oh, yeah, I'm obviously looking for the markdown files. But we're going to traverse that to a depth of two. Looking for our markdown files to process. Gotcha. And in this case, we don't have any and that's okay. But any time a push happens. Now, this is like, oh man, do we really want to check our markdown links when we make a push to a JavaScript file? Maybe, maybe not. So I wrote in here a little note that schedule makes more sense. If you just like scheduling your weekly standup issue, maybe you schedule a weekly maintenance workflow that checks your markdown files every week. This is just to show you that I can force a workflow to run on a push. That's all. And then I will delete the trigger at the end of the day. Actually, yeah, that's fine. We'll do that. We also don't have any markdown files. So I don't expect a miracle to happen. Yeah. You know, and y'all to really, I'm going to kind of punch you here with the idea of what Matt is teaching us. There are a lot of corporations that just recently went through some major, major, major work to look at their documentation. And what they were trying to find was offensive terms and inclusive language. Different companies had different names for it. It was a big deal. I know that at AWS, I was a big proponent for it because there was a lot of stuff. And, you know, it's not anybody doing anything evil, anything wrong. They just don't know. They don't know that's an offensive term. They didn't know there was an opportunity to include some inclusive language. The thing that Matt and what a lot of them actually did was they just created basically text parsers in Python. This text parsed through all the text. The thing that Matt just showed us here, that is an awesome way as it comes in the door to make sure those checks are made instead of waiting until you're downstream to go, okay, we need to check this. So really open your mind up to some possibilities there. As this stuff has been created, you can check it right there automatically to make sure that you're in a good space. Not to mention, it's just points for you. It's just points for you saying, no, that whole thing has been automated. We've got that. Excellent point. We got a question in chat. You can't check a private repo with this thing, right? As it cannot clone it. Wrong. I understand where your confusion is though. That's a good repo that contains the workflow files. So for this one, GitHub for everybody has the workflow files. If this were private, it still works. The actions checkout action will still work because the checkout repo is public. So it's the repo of the action. It's visibility that matters. If you had an action that was in a private repo, you could not pull that into other repos. I could set my current repository private and use all the public stuff I want. So public or private things can consume public things. Public things cannot consume private things. I hope that clears it up a little bit for you. I totally understand where that confusion would come in. Now, there are other things that you can build local actions to. You can write all that source code directly into a private repo if you never wanted it to reach out. So on this take, let's say I have a repo that isn't allowed to consume anything public. Well, I can write all the source code for the actions in that repo and call them from the repo. But I will always be able to get actions checkout because it's public into whatever repo I have, even if it's private. It's like the vampire theory, right? Vampires can't enter your house unless you invite them in. Same thing. Okay, so crazy. Check this out. It ran. I didn't do anything. And it's not on the main branch, right? So that's another thing. We still have a branch. So push events apply to all branches, right? And we can see that here. It's on the add link checker branch. Our other one down here, our weekly sync, is running every time a push happens or attempting to run every time a push happens because it doesn't have a trigger. So just ignore that. It's not actually breaking. It just doesn't have a trigger. So it's freaking out. This one though is just not working because of whatever, let's find out. So it says this job failed. Let's take a look. And here is a bunch of logs on why. So there's runs inside a docker, four packages. Can't find a config JSON. That's okay. Can't find the directory docs markdown files. So this breaks. So this might be something that makes sense to add in this pull request. If we are going to add this workflow and this is a hard dependency for that workflow, let's go ahead and create that now. So we will come over to our first. Let's open a pull request, right? Because we've got a little bit of work done. Good title, good message. We got a little bit of work done. So let's just go ahead and do this. We will link it to this issue so that auto closes. And when we're ready, we'll request a review. And you'll see, look, it has, since we have something with a push event, now we're starting to get checks that show up in this screen. So only things that are relevant are going to show up here. Notice how we don't see the hello world ones or the weekly sync ones. And there's not really a way to control all of that easily for this purpose. There's other fine grained things you can add to the trigger that control it, but we're not going to dive super deep into it. I'll show you a small example, but not super, super deep. So this is currently failing. That's great. We can click details. It takes us back over to where we just were and we can see why. So let's go ahead and add that. We need docs. What is the folder docs underscore mark down or mark down underscore files. And you've got your approval on the change. Okay. Perfect. So create a new file. It's going to live in the docs. Markdown underscore files. And we can't create an empty folder on GitHub. So I'm going to have to call this demo MD and like actually create a file. And let's just put a link in for the sake of watching this thing run. And we're going to say HTTPS colon slash google.com. We know Google's up, right? All right. We'll commit that to our branch. We're still not committed to main, but it's running. So let's try to watch it because this one builds Docker. So we can kind of see that. We can catch it, right? So this is the setup job that just is building the Docker image that is present in that actions repository. Now it's checking the links. We see it. We're getting all of this extra output because we said like be verbose. I did that on purpose. But look, all links are good. Nice. So we know that that's cool. And it's green check. So let's go in here and break that. Let's see what it looks like when it fails. Oh, and now look, the pull request will be able to merge, right? Every all checks have passed. So like from a CI point of view, you could say, hey, like now we're kind of running continuous integration on content, not on code. So we could see that everything is there. I'm going to go ahead and I'm just going to merge this. Now, and then I'll break it. Let's delete the branch. It auto closed our issue like we wanted it to. Pretty cool. I'm going to break some rules as I break this. We're going to make a commit to main just for demo speed purposes. I hope this is not a URL. I don't think this is a real website. And if that hits, that's going to be great. So let's see. That was a push event, right? I clicked the commit button. Push event fires. It's updating. Let's see. Let's see. Let's see. This is the weekly sync one that's always going to fail because it doesn't have a trigger. If we click on it, it might throw an error for us. It doesn't. So we'll go back to check markdown links. We're updating. We can come over here. And I can see this map sort of on the back side of a push event where like, did everything work? Is the URL up and running? Are we getting back a 200 okay response from the site? Yeah. That's the thing is you could configure multiple triggers. So you could say, hey, on every push that is not to the main branch, go ahead and parse all the links. Also on a schedule, parse all the links. Also when, I don't know, an update to that folder happens, parse all the links, whatever. Like you can set up all kinds of triggers for that. Now, look here, one dead link found. We got all this information about the links in that. So that's cool. So we know how to fix it. Now this doesn't, it's not tied to a pull request. It's not going to stop anything from merging. Or whatever it might be, but consider the next step to this. This is, this is one step. We just had an issue creation thing, right? We, on a schedule, we create a new issue. Well, what if we created a new issue if this failed? Like if this step fails, then we create an issue saying you need to check these links. That's a helpful thing. So like, let's see what Winkly Sync looks like. I think it might be easy to edit. Let's see. Yeah, this thing just creates issues, right? So we could actually, we could do that. We could steal this whole section and tack it as another step onto the link checker thing and say if failure. So meaning if the previous steps failed, then run this one. And it could create an issue and say, hey, man, like you need to go check that workflow run. You have some invalid links. And that would just automate that maintenance for you. It's kind of cool homework for you. If you want to try to tie it in and play with this once you get these notes. All right. Super cool. Let's take a look at our issues. Let's jump in and let's add our GitHub pages out. I think this is going to be quick and easy. So we'll start with that one. So the first thing I need is a branch, right? So I'm going to come over here and grab me a branch. You see how that flow happens, y'all? It's just the automatic way we start working. We have a new, we start with issues. We go in there. We create a branch. That's good. Or you can call it your feature branch for your coding. It's just this natural rhythm you start doing when we use GitHub. Yep, exactly. So add pages app. I am going to scrap this branch and I'm going to do this because of how GitHub pages works. First, I'm going to come over. How dare you 404 on me of all people? I'm going to come over to our settings. I'm going to come down to pages and I'm actually going to enable it. And I don't want to enable it off of main. I'm going to create one called GH pages. And it says no results are found. So I probably need to create that branch first. That has changed. You used to create it for you. So I'm going to create a branch called GH. That's a cool feature. I wish that was still there. Yeah, it used to create it for you. So I'm going to create a branch called GH pages. This is the only time I'm not going to have a deliberate name for my brands, right? Although that is kind of deliberate. It is the GitHub pages branch. So see, look, just by creating that branch, it automatically enabled GitHub pages on this repo. It didn't even think twice about it. So I could select a folder. I'm just going to leave it in the root and that's fine. So let's go back over to our branch. It automatically did that. So was it, wait, hang on, everybody. Hang on just a second. So we created a branch called GitHub dash pages and GitHub internally just picked it up and deployed it to pages. So y'all, that's that's a gotcha. Watch for that. That's some insider information. You're going to create a branch. You create a GH, a GH dash pages branch. Something else is going to fire. That's almost like a reserved word type thing. So careful. Very much so. So we have it set to serve our page from the root. So I'm going to create a new file. This will be super quick. I won't bore you too much with code. And honestly, it's not about the code. This is just a reiteration kind of day. We're going to call this index HTML. And we're going to paste in some HTML. Always about the code. We're going to commit that to GH pages. Guess what else just happened? That workflow to check our links just just fired off because it's not a push event. That is so cool. It's on a push event. That's simple people. That's simple. So we're going to add another file to GH pages. This is going to be main.js. The reason why I'm including the world's smallest JavaScript file is just to show you that pages is capable of interacting with client side JavaScript. Yeah. As a matter of fact, while that was running, as I go look at workflows, if I'm manager, if I'm just responsible for what's going on or what is going on, I can see right there what called it. Like I just see now create main.js. I can see it running. I can see pages build and deploy is running. I can see exactly what's going on. Yep. There we go. Lots of status about what's going on. It is taking place. So the purpose of adding a CSS file, an index file, and a JS file is when we showed you pages before, we kind of just showed you the markdown side of it. The truth of the matter is I could write real code if I wanted to and that's going to get deployed out to pages for us. So now if I come over here, again, it's not server side. That JavaScript just adds an event listener. If you know anything about web dev, that's all in the browser. So it's not server side and that's the limitation is it can only do client side rendering. That makes me wonder about how much fun it would be to use Rust for WebAssembly. So here you go. I had to clear the cache, right? I had to do that hard reload. Once I did the hard reload, here we go. Hello. This is the HTML that's in there. If we hit this, we get an alert, right? So like JavaScript works. All of this is client side rendering. So maybe you can't find a cool docs library that you want to do. So you write real JS or real HTML or whatever. Okay. Cool. Page is done. Look at that. Just found a great example out there on the web. You know what's great now? That's kind of done. We don't have to merge this branch. As a matter of fact, we don't want to merge this branch. How come? Why would we not want to just go ahead and merge that in, Matt? Because that is where GitHub pages is deploying the code from. So what becomes really cool about this is notice how main doesn't have an index file. It doesn't have a CSS file. It doesn't have a JavaScript file. And as I create another branch, like, let's just check this one off really quick. Okay. We'll say you're closed. And then we'll pick one to create a branch on. Let's do add a non-static web app. So I'm going to create a branch for main. Add non-static app. Now this branch has none of that fluff from GitHub pages. So all of the GitHub pages code is isolated to the GitHub pages branch. So to be honest with you, what we probably should have done first is set up GitHub pages so that we didn't have these markdown files or the dot GitHub folder over here. And we could have just had a very clean page deployed. It doesn't hurt anything that we didn't do that. But now when we make a change to our non-static app and we merge it into main, it's not going to show up on that GitHub pages branch. So we can continue doing private things or whatever we need to do in our repo while pages remains publicly deployed and independently managed for our project. Hold up, Matt. So this actually, this actually is not, y'all, I'm not making this up quite truthful here. So quite literally what we've got here is we almost have like a separation of concerns that we use in programming, like modularization. So we have this project. It's super cool. It could be code. It could be documentation, whatever. I like it. I don't want to mess with it. I want the GH pages to give it a nice front end for whatever reason. And instead of that mucking around with main, I can have this branch, which is like a first, what we call in programming a first class citizen in this ecosystem that says, this is for sending out JavaScript enabled. This branch, again, another first class citizen, this is our static. This is what we also sent out where we don't want. So is that kind of where we're going? Because this is some very inside stuff right here. Yeah. That's that's pretty accurate to how you could treat it. You just can't do fancy stuff like make back in calls, right? So yeah, yeah. It might be really good for like a project blog or some documentation or a portfolio or, I don't know, whatever you come up with creatively, but there is a separation of concerns. And now the question comes in, well, why wouldn't I just deploy a website? Well, let's pretend that I didn't already have my own domain. I don't have to buy a domain. GitHub supplies one for me, right? So if I'm a student or I don't care about what the URL is, which there's plenty of things I wouldn't care about the URL for, I don't have to buy a domain. I don't have to configure a web server. So no engine X here, no express here, no, no patchy, no whatever. I don't have to configure a web server. I don't have to configure any of the networking that I might need to allow access on specific ports. All of that's done for me. DNS off the table. Yeah, it's it's completely handled by GitHub. I focus on nothing but the code. It's kind of cool. And now whatever that page is, I'm assuming fits with the project. So it's, again, all in one place. So here I have a page deployed. Now I have the source code over here. I have the Docker image. I have all the automation and the CI CD pipelines. And I don't really have to go many places. I have the entire project management all shifted left right where the code is. So instead of, there's a document in Google that we use to describe this. But over on the network drive, we've got a Word document to describe something. The actual source code is seating in Team Server someplace. We've got JIRA for keeping up with what's going on. This is all one place, y'all. This is not a little thing that we just said. It's for a lot of people, that is a bane of our existence that we have all many separate disparate systems that don't talk to one another. Whereas with this, it's all in one place. Exactly. So what I'm going to do right now is I'm going to show you what the web application we're going to add is. Again, this isn't about the code. I don't really care about what's going on in the code. Did this, this is the wrong repo. Stand by just kidding, I lie. I got to get the right repo with the code in it. I don't have it. Give me two seconds. Let me pull this up. Basically, I want to show you this app running really quick so that you understand what we're going to do and you'll understand why it doesn't work. Or else this is not as fun. Like there's no point in CI if you can't see what we're doing. So it already exists. Where? I didn't know. It's everything so zoomed in. It's hard. Okay. So let me pop out. Oh, leave me alone. It's two and three. And this is our, what is this called? Demo app, I think. Yeah. Demo app. And is this an express app? I think it is. Yes. Is there not? Sorry, dependencies, right? So like, yeah, y'all hang tight. Hang tight. We're getting it. Yeah. So I got to install the dependencies and I'm glad you're seeing this because guess what? We're going to need to do with actions. We're going to need to install dependencies. And I just use the terminal command to install dependencies. And that's exactly what we're going to do with actions as well. Okay. Cool. So let's come to my super cool web app. It's super sweet. I know you're jealous. Okay. Nice. I know. I know. Let's go ahead. We're going to pick a number. We're going to say two. We're going to say four. We're going to hit add and two and four is 24. Right. And that's good stuff. Super sweet. Nice. Super crazy. Okay. That's what this currently does. That's it. So that's the code that I'm going to currently add to this. That's what this currently does. So that's where we're at. And some of you are like, yo, that's not right. And you're absolutely correct. So I got to add a couple of files. It's going to take a second. So feel free to ask questions if you have them as I do this. Well, the problem is we were just not going to be able to see this because it's server side, it's rendered from a server, right? And GitHub pages can only do static stuff. So we can't, there's no good way for you to see it outside of me showing it to you like that. That's okay. So we're going to commit this. This is just the JavaScript. We are going to add a file. Add that. Add another one. There's not that many, I promise. Oh, that's a few lines of code there, huh? A little bit. So many that I had to zoom out to find the button. Okay, let's see. That's that. We'll create a new file. Of course, what is in here? This is our culprit, right? It's not going to work after we quote and quote fix it either. So if you're expecting it to work after that, you're going to be sorely mistaken. That's okay. All right, last file. I feel like as I'm getting older, I can't type as well. It's a bummer. I don't even know how Rooks does anything. Man, I swear. Okay, so this is our web app. Cool. I'm going to go ahead and I'm going to continue to get flow for this. We're going to open a poll request. This is a non-static web app. Good title. Do something better than that. Good message. And I'm going to say, okay, cool. Create this. We're going to pretend that Brooks is going to review that and we are going to link this to what is it called? Static. There we go. I just got it over on my side. So our markdown check is failing because that Google link is not a real one, right? We hammered in that crazy link. That's okay. The good news is we can admin merge this if we really, really need to. So I don't think we will. Okay. You've got an approval from me. Perfect. So notice how it's saying I can merge, but the button is not green. That's because of this, right? So yeah, I can do it, but it's not like a green light to do it. The whole box is yellow. It's like, you should think about this. Double check what's failing. Thank you. I double checked. We're fine. We're going to delete the branch. All right, cool. So that web app that I just showed you, this super broken thing. It's really good. It's a good app. Also allows us to do stuff like this. Right? That's super fun. That's some super fun checking on your data type, man. Nice work. Yeah, there's some problems, right? Yep. Yep. If you know anything about programming and or math, you'll realize that you can't add letters together. And even the numbers in this application are coming in as letters. Okay. The actual code that's doing that, I think it's in here. This form is passing it in as text, right? That's just that it comes in as text. See type text. So that number is a text field. It's not a number field. That's okay. We might want to fix this though. We could very easily fix this if we use something like continuous integration, right? Like we wouldn't ever want this change to make it into our code base because it's broken, but Brooks just approved it. Well, what if we had a check that would have run our tests for us? And the good news is, is we have tests. I wrote some tests. So if we do NPM test, I hope that's right. Right? We can see like, hey, like these things are failing completely, right? And we could have GitHub actions run this test and tell us that. So let's go ahead and set up that. And that's called continuous integration. We're not going to go deeper than that on what it is. So like let's, so this is going to be interesting. So this is technically two workflows for us. The CI part and the CD part, but it was one issue. So what I might do in this case is create a new one that says config CI for the app. I realized that number, I don't know what number it is. What number was that? Baby, come back. Number seven. Number seven contains two work items. So this issue addresses the first one. Right. And I'm going to submit that. And what's cool is I can always click number seven and go see what number seven originally was. Okay. Okay. So sweet. This is definitely broken stuff. This fixes a bug, right? So we'll come into our code. We've got our issue. Let's create a branch add CI for app. And in this case, we want that MPM test to happen all the time, like automatically. I always want my code to be tested when something changes to this code base for whatever reason. So we're going to add a file. I said we're going to add a file. Do it. That is going to be .github slash workflows. And we're going to name this web app CI.yaml. Okay. And this is where actions gets a little bit fancier. First, we give it a name. Nothing new. We've defined two triggers. Okay. Two triggers. When there's a push to main, when there's a push to a branch named main, I could also say a branch named dev or a branch named testing, whatever. You can specify more than one. Whenever a push happens to main, this is going to run. So this is good for I've worked on the pull request. I've now merged it into main. I just want to run my tests one more time to make sure that the entire code base, now that that merge happened, just double checks out. Just in case there was any weird drift between the two. And it also runs whenever a pull request is created from the main branch. So whenever we create a pull request from main, we're going to run this workflow. Is this the most optimal way? Nope. Is it a good way to show you that two triggers can exist and we can start filter them out? Yep. And that's the only reason it's here. Okay. So you would want to think this through a little bit more pointed for your use case. This is a really good example. So when one of these two things happens, guess what? We got a job called build runs on Ubuntu. And what is this hoopla? Well, go ahead. Oh, no, I was going to say just what is that? Teen you up, man. What on earth are we doing with the no version? Yeah. So programming languages change, right? There are different versions of Node.js, which is a Node.js app. This allows me to test it against the different versions of Node.js. So the other thing I might be able to do is test it on Windows, test it on Mac, test it on Linux, right? I can test it with this language, that language, whatever it might be. It allows me to run these various tests. And I happen to know that this one is probably going to fail. Node 10 did some silly things that I think Express breaks on Node 10 now. So we'll see how that reflects. And I could be wrong. But since we are going to run the code, we're going to do stuff to the files. We need to run checkout. And then we can specify this matrix node version. So that's going to say, hey, for the current thing in the matrix, grab the version. So it's going to say the name of this step is use Node.js 10, use Node.js 12. So we're going to get a series of steps all in a loop. So that's going to iterate automatically without us creating like a for loop or a while or anything like that. If we say node version in brackets, it's going to treat that like a loop. And then all we got to do is matrix node version, or it could be it could be matrix dot something with Rust where I'm checking versions of libraries that I'm bringing into Rust, whatever it is, I get that automatic iteration. And we could call this whatever we wanted. Okay. But it's just already written. So then we're going to grab another GitHub maintained action that just does some node stuff. And it just ensures that it's using the right version of node to run the following commands, which happened to be NPM commands, just like I just ran in the terminal, right. And they have these as like individual run steps. This will install our dependencies just super quick. If we have a build step in our script, this will run. And then this will run NPM test, which is what I just ran down here to get this output. Yeah. Now, the reason that that just are just a quick question to make sure we're all clear. I noticed that the name down there are actually the runs. I've got three different runs. The first run doesn't have a dash next to it. So is that because of the name? Yeah. This just denotes an object in the list. This is YAML syntax, which we could really dive into on a whole day if we felt like it. Name is optional. I can add a name here. Name, build if there is a build step. Right. It gives us a bit of documentation then about what this thing is doing. And all name does is it shows up in the UI. So I'll leave this one without a name and you'll be able to see the difference in the name or in the UI. So let's go ahead and commit this to our ad CI. We're really zoomed in here. So just to give you a reason I want to point that out was that piece right there y'all. So that if, you know, if you're developing an application, if it's just, you know, again, it could just be a documentation repo. If there is somebody other than you say like the DevOps team or the help desk or whoever it is, who keeps an eye out for this stuff by using that name tag, you can make it easier for them to figure out what just broke. Okay, so we haven't opened our poll requests yet and we haven't pushed to main. So therefore this hasn't even showed up, right? So we probably actually need to get that to main. So let's see what happens. We're going to try. That might be one of those weird ones that has to be on main, but we're going to find out. We're going to pretend that there's a good body to this. Okay, we'll request our review right now just to get it out of the way. We'll link our issue. This closes, closes number, config CI. Cool. Now let's check. Here we go. Here we go. Poll request is what happened. Okay, let's see if I can show you. So a poll request just happened, right? So that's why this is triggered. So we can go into it and you'll see, look, the jobs, even though we had one job block is now running on 10, it's running on 12, broke on 14, it broke on, or might break on 15. I don't know why it broke on 14. Pretty sure that's what I use. Right, works on my machine not yours. No, I use 16, okay. So we'll see where else it breaks, if anywhere. We can, they all broke. Fantastic plot twist. They should all break right now. So there's that. We're going to prove, by the way, are you cool with that? Yeah, yeah, that's fine. We can just get out of the way, right? So we can come in here and we can see why it broke. There's no build step. This is CI, no such file or directory. Um, package.json, did I misspell that? Let's take a look. By the way, y'all, as I approved that, as soon as it popped me back, I see that my, uh, I approved something that broke dramatically. So now I feel like a big Ogoober. As you should. Let me go see if I misspelled that. That's possible. No, that's correct. We here, let's check the branch. It's there. Love me. What is broken? I don't know. Again, we're not going to spend forever troubleshooting. If something goes wrong, um, I would try to get this quickly because the next part's cool. If so, if not, it, uh, we're kind of dead in the water, which sucks. Path. It should be right there. Do you want to take a break, dude, while you debug? Yeah, I think that's actually a good call. We're at that time anyway. Okay. All right. Everybody welcome back from break. I hope everybody had a chance to, uh, jump in there and do the evaluation. Adam got it posted up for us. So again, what do you get a chance to jump in there? Let us know what you think. Meanwhile, back in Vegas. I'm done done. The chips fell in the right direction and the problem was simple. Uh, it's so it was a pathing issue. So GitHub actions assumes by default that we're in the root of the repo, but I got all fancy and nested all of this in this folder. So I needed to go update that and you'll see it's still failing, but this is the failure it's supposed to have. So it's still failing now. Uh, but it's no longer saying that it can't find what it found. Right. The tests are now failing. So this might be a problem when we get to putting this into a Docker image. So I might move these files, um, out to the root of the repo, but before I do, let me show you how I fixed it because this is a neat feature that is new to actions. If I switch to the proper branch and we look at the CI, all I did is in the job, I set up some defaults and the default was anytime there's a run step, which is our NPM problems here. What was failing is it couldn't get our dependencies because it didn't know where to find the file. So every time there's a run step, the working directory is now set to be the proper directory and it's able to run our tests as we expect. Makes sense. So that is, that was the initial catch. As a result, I think I'm going to move these back into the root of the repo. I don't think that'll cause a problem, but it might. We're going to try to do it without moving it first. And if we have to move it, I'll move it and it is what it is. So we're currently failing though, and we can see that in the pull request. So let's go look where we would actually see this because we're doing work. We're like, oh no. Some checks. All checks. Yikes. This is failing. So like let's click into the details. We'll find out why. That's the markdown links. Of course, I picked the one that we don't need. The one that is allowed to fail right now. So we'll come into here and we'll find out why. And the test failed. And the reason is it can't find any tests. How about that? So let's go ahead and just pop in here and we'll add the tests really quick. They're simple. So if we come, let me pull them from my thingy. Where are you? Where are you? Okay. So we're going to switch to our branch. Add a file. That file is going to be in web app or sorry, demo app slash web app. And then it's going to be underscore tests underscore. And this is just a, what just the testing library expects. This is going to be different for your project. I'm sure nonetheless. So we're going to add our tests. Super, super valid testing here. And we're going to run the commit and that's a push event. It's taken place, not on main. So that's not what's going to run it. You'll notice the poll request ran it because there's this synchronized event that happens every time you update a poll request. So since we haven't set the poll request, there's a lot of like sub things that take place. So if we came over to the events that trigger workflows and we look at poll request, anytime a poll request gets assigned to somebody, it's going to run unassigned or labeled or opened or edited or synchronized, which is what happened. We just pushed an update. So we can limit those runs, just like we limited what branches trigger this workflow. What branches trigger this workflow? We can say only run on a poll request comment or only run if a poll request is assigned. So you can further filter down what triggers these things slightly outside of the scope. But let's see why we're failing now. We'll click into 12 and look our tests ran. So now we're failing because we have bad code. We're not failing because actions is broken. This is flat out saying you have one test and it failed. And there's the difference right there. We actually see the suites, the test suites are failing. Okay, cool. Yep. So let's come in here and let's collaborate in our poll request. We'll say this is the workflow. I don't really need to see that one. So we'll collapse that. And this is the test, which that's not the problem. Either. So we're going to need to go if we could cheat and just edit the test, right? Let's go back over to our proper branch. And let's grab the culprit, which is this add numbers function. And we are going to uncomment this set of lines out. And I think at this point we can comment these out and we should be good, right? So we just, we, we saw that we had failure. We went in, we fixed the code again, not a course on, on programming, which is why I just kind of blew through it like that. But we saw that we had failure. So we're going to go in, we're going to fix it since we ran a synchronized. All of this is going to run again. And I think we're still going to fail on 10. I hope we still fail on 10 because I'd like to demonstrate like the matrix because it does different stuff. So of course it doesn't fail on 10. Right. So now everything is there. It ran cool. We ran the tests. We can still click into it. We see we passed. So now I think it's safe to say that we could merge this into whatever our trunk is or whatever our dev branch is, right? This is a part where we'd probably have a feature branch merging into a dev branch, getting ready to be merged into a release branch before it finally makes its way back to trunk. In this case, it's safe to say that we can merge this without problems, right? Like our code works. I think, I think that's fair, but probably doesn't work well. Probably doesn't work well. So we'll show you, I guess, what changed. So let me come in here and I will just grab that file and I'll uncomment it. So you can see it working. Just maybe some people that's helpful for you. And let me start the server. So this is the change that took place. If we come to this and we try to add D to three, it says, hey, that's not valid anymore. And like, you're not allowed to do that. Okay. It's not, it's not still not a good app, right? And now it's saying everything's invalid. So that's broken too, right? Because it's still treating these as text and like I coerced it into numbers, which it can't, like it's just struggling. So again, bad code, code's not the point. The point was simply that we were able to set up CI to where our test pass, when we make these changes, they fail when they don't make these changes. And we did this all right inside of GitHub. We didn't have to do anything extra. No Jenkins, no, no nothing. We just were able to do it right alongside our code. But now the idea though here is Matt, just in case I understand it, what we're really seeing here is we're seeing the development process. So make a change, we test it. We make a change, we test it. We're iterating towards the right answer. Yep. And this is not just for developers too, even though we're doing it with code, like imagine that being your documentation, right? We make a change, we verify the links. We check the style guide, right? We make sure that a style guide was properly applied to our documentation. We alert the right people. Maybe at the end of it, we turn it into a PDF and go store it on a Google Drive somewhere. We can automate 100% of these steps along the way without the need to write code, right? Like these development tasks kind of exist. So I've been doing a lot of talking. So what I want to do is I want to send you guys on a little task. I want you to have a little fun. I want to go back to our profile readings. Because now that we see that actions can do stuff, I want to apply that to our profile readings. So if you remember how to get there, it's github.com slash your username slash, well, your username. Is everybody got that? So you're going to do github slash username slash your username, not maths, do your username. Remember, this is just a repo, right? Special repo that has its name the same as yours. So what we're going to do is we're actually going to do something fancy schmancy. I want you guys to do a quick Google search, super quick Google search for RSS feeds. I'll show you. You can find any RSS feed you want. Maybe you already know of an RSS feed. Let me shut down this really quick just so we're not using resources. So you can use any RSS feed you want. You can find one. What is one? Wow. You search RSS feed and you don't get anything good. Do slash.man Top RSS feeds. Here you go. Here's the most popular ones. Here's the top 100 for news. Pick one doesn't matter. Pick one that matters to you. Okay. And what you're going to do is I want you to copy the RSS link. We're going to need that link for the feed. Okay. I'll see that. Normally these things begin with RSS and the URL. That's typically what you'll see. Looks like Huffington's got a little bit something different. It doesn't matter. Typically right there next to that orange follow RSS. That's the link you're looking for. That's what you're going to want to copy. So wherever you're at, whichever one you're picking, grab that value. Yep. Grab RSS. Any link, you can find one that you like. You can grab a quick one for now. It doesn't, doesn't matter. You maybe you're going to change it later. Okay. But grab an RSS link. I'm going to use CNNs. Don't don't come after me with pitchforks. That's just again, it's a link that I'm going to use. So what are we issues? Who created issues? I probably created issues. What just happened? Yeah, I created issues. Awesome. So let's go through the flow. Right. We're going to create an issue to automate our profile readme RSS feed. And once again, y'all, we didn't just go do a thing. We went to issues first. We are going to use GitHub actions to dynamically update our profile readme with things we care about using RSS. Okay. Sweet. Done. That's my issue. I hope you're there. I hope you got where we're at. We're right here. Let's go ahead and create our branch. Add RSS feed. Action. Boom. Nice and simple. Now we're going to add a file. This is going to be super slick dot GitHub slash workflows slash update readme RSS.yaml. Okay. And I'm going to, you'll be able to fork this over, but it'd be super quick for you guys to actually just type it and just wouldn't take you long. I can, I think the formatting is going to get messed up if I paste it in chat. Um, let's see. Hold on. What I will do is I will come to GitHub for everyone. I will create an issue. And I'm going to say this is your RSS feed code and I'm going to come in here. I'm going to say this is YAML. I'm going to paste that and I'm going to say that. So if you go to the GitHub for everyone repo, you can copy the code from this issue. You just click this little thing up here. Okay. We'll cover it real quick. We're going to update the repos readme. Nothing special. It's going to happen on a workflow dispatch, which means when we click the button, it's going to update. Again, this is one that probably benefits from being on a schedule, right? If you want to update your, maybe let's take a step back. Like maybe you want to add your projects dynamically to that readme. Every time you work on something new, you want to update it so people know what you're working on. The, you have to decide what that trigger is. If that schedule is once a week, fine. If that schedule is every time you push to a specific repo or whatever, that's fine. You might have to tweak the trigger. RSS feeds kind of make sense to do like, hey, like every day or every hour, go ahead and update this. Fine. In this case, we're going to use a manual trigger, but just know that this is something that benefits from being on a schedule. I just want to show you something that you can do. That's all. We have a job job has a declaration. We didn't give it a name. Didn't give it a name. So it's just going to say update in the, in the actions thing runs on a bun to notice how it doesn't check out the code because it doesn't need the code. This is, uh, we're going to reach out to that RSS feed, that link you just copied, and we're going to make a GitHub API request. Honestly, I think Jason does check the code out just a little differently. Jason is a developer at GitHub. He's built a lot of like crazy GitHub things. So you can definitely look into his account, follow him. If you're interested in stuff, he's actually responsible for a learning platform that I'm going to turn you on to here in a minute. And we paste in that URL and we're going to take this commented stuff and we're going to need to copy this, right? It's, it's commented out now, but we're going to need to copy it because we need to configure a section in our read me where we want this to go. So there's two different steps here. Configure the workflow and then edit the read me. So once you have that committed to your branch, you're going to come on that same branch. You're going to grab the read me and you're going to edit it and wherever you want it to be, you paste in what you copied and undo the hash marks. And that's it. You can just leave that there like that. And that is where the RSS feed is going to populate. So we can commit those changes. We see nothing yet. Next step, pull request. Good title. Good body. Oh, is a good body. Create pull request and merge that back to me. You're on your own, your own repo. You're the only collaborator. Go ahead and merge that in. I'm getting nothing over here because that's just go loops back to you. So now we're in actions. We click this thing, hit run workflow. And as we run that, our profile read me will now dynamically be updated every time this gets triggered to pull the latest top five things from the RSS feed and update our profile read me. So this is just again, a non developer thing that you can do to make your read me a little more personal. Look at that. I didn't do anything but run actions. So get up for everybody. This is something you can do. Maybe you write a blog post and you want to update your blog posts. Maybe you have projects. Maybe, I don't know, there's a million things you can do. The latest hacker knows. Yeah. The latest you got to Ycom and you know, you pull the news RSS feed, you could pop that in there and make it look like you're doing stuff and you're not yet. Everybody's getting the latest hacker news right there. Exactly. Which is why the other day I asked if the links were manually put in because I said this looks an awful lot like something I'm going to ask you to do. And it does. But this was all dynamically pulled. And if we give it a couple minutes and we run it again, we're going to give five new things that show up there. And you can go to that actions read our repo from Jason. And you can see the different ways to configure it. You could probably have 10 things show up if you wanted to. Exactly. Lola, that is a very cool trick you just showed us. Very cool. Yeah. I'm glad you liked it. Super cool. I'm trying to keep this is for everyone is possible. And I feel like we just took a really deep dive into overly technical stuff. So this is a good way to reel it back in. So work on your own profile read me's. Think about how you can apply actions to them. And honestly, if you look up like awesome profile read me's, you're going to find a lot of them use actions to do cool stuff. And that's an interesting way to get ideas. So all right, we have one more piece. Just one more. We have one more issue. All right. Let's see what it is. Okay. And then we're going to talk about a little bit of stuff, but that's it. So then we could create an issue off of this and the aspect of time. We're not going to create another issue to break this up, but you'll see it was mentioned in a different one. So let's go ahead and create a branch for setting up our CD. So once again, yeah, other than the fact that we did that, there's your workflow again, y'all issue branch. It just becomes natural to work this way. Yep. And some of you, some of you might want to argue that this isn't CD. And I will hear your arguments and I will side with you, but this is the beginning of CD. Okay. So just we're not going all the way through. I'm going to need you to just work with me and pretend a little bit. All right. Can we do that? Can we do that? All right. Thank you. All right. So what we're going to do now is we have this code. Yay. It's really ugly over here for some reason, probably because it's JavaScript. So we have this really ugly code and we're going to put this into, we want to dockerize this. So we want to create a container out of this. So that's what we're going to do. And we're going to pipeline that. So we're going to do our tests first. And once our tests are good to go, then we're going to build that docker image and we're going to store it in GitHub packages. And then we can pull it and run it from a docker container and all that fanciness caveat. Pathing problems might exist here. This is another one of those things that it kind of expects it to be in the root repo. I will try to fix it quickly on the fly. But I kind of expect this to break. Even though the workflow is accurate, it's totally going to be a path problem, guaranteed. So we're going to add a file to our workflows. Copy this. And we're going to say create and pub docker image.yaml. Now we're getting big. Huh? Okay, I got to zoom out a little bit. So this is one that you could probably find in the starter workflows. Like when you when you come over to a repo and you hit actions, you hit new workflow and you you look through here, there's probably one. Let's say docker. We hit enter. Yeah, publish a docker container. Right. So you it's probably one that was over here. I can't remember where I found it. Yeah, but I think it is. The point is I use official docker actions. So this is what makes me think that I just grabbed the one from the starter workflow. Scroll please is we have this like disclaimer that this uses actions that are not certified by GitHub. I don't think that's true. I think we're using actions that are certified by GitHub. So we'll see. We gave it a name. Check it out though. New trigger on tags. We haven't even talked about tags. Tags are a way for us to say this is a release. This is a stable release that we are going to send out. Okay. Which kind of helpful when we're talking about doctor images, right? Like we don't really want to go through the hassle of building them all the time. So for our use case, we're going to say, hey, like once all of our tests are good and we decide that we're ready to go, we will tag a release and that's going to get us a docker image that we can then deploy to wherever we want. Okay. Not exactly the ideal pipeline here. Just pretend. Come on. All right. So here we set some environment variables. What's cool about this is these variables now become available to every single job. And in this case, we only have one job. But if we had three, four or five, they could all access these global environment variables. These get set as environment variables in each machine that gets spun up. Okay. We're setting one just to point to the GitHub container registry rather than the docker hub. Okay. And then we're just going to name the image the same thing that the repository is named. So we're going to end up creating an image called GitHub for everyone. Right. Kind of a bad name, but it'll work. Whoever named it should be fired. So our job is going to be a build and push image. That's the declaration. It's also going to be the name because we didn't declare a name. It's going to run on Ubuntu and we're going to give it some scoped permissions. Now what we're actually giving permissions to is this GitHub token on line 32. Okay. We're going to say you're allowed to read the consents of this repo and you're allowed to write an image back to packages. Everything else you need to simmer down and sit down. Okay. No touching. Right. So those are the permissions that the GitHub token is going to have since we need to deal with the code. We're going to check out the repository. We're then going to do some setup steps like logging into docker in order for us to publish to a registry. We got to log in. So we're going to log in with the GitHub container registry. We're going to use our username as our docker username and we're going to use that sweet little GitHub token as our password. So I'm not configuring nor storing nor risking my actual docker docker hub credentials at all to do this. This is all self-contained inside of GitHub. GitHub.actor is the GitHub context which is metadata about the repo. The actor is the person that triggered the workflow. So if Brooks triggers it, it's going to be Brooks. If I trigger it, it's going to be me and it's going to change every time and that's okay because we're using the GitHub token as our password. So docker is just going to let us log in like that and that's what the GitHub container registry expects from us. So we get away with some little secrecy here. The next thing we're going to do is we're going to use docker's metadata action and you'll notice here's a release tag. Here's a SHA. Here's another commit SHA. We're going to use their metadata action to format what we want the tags to look like. What's really cool is this has output. You can't see it but we end up using it down here. You see it says steps, meta outputs, tags right here, steps, meta outputs, labels. Well, meta is the ID for this step. So we're saying steps up here on 23.meta.outputs, which we can't see, this action sets them though and then we're using them. We can find that out by going to this actions repo and looking at that action.yaml or the documentation. We can find out what outputs it sets. That is also where I got this crazy pattern of information is from that actions documentation. They have a couple different formats for the docker tag. This is the one I chose to configure. Lastly, we're going to use docker's build and push action to look at the current context and do its thing or build from the current context. This is why I think this is going to break. I genuinely think that it's going to expect all of this in the root of the repo. And it's not going to find it there. If it breaks, I will move everything to the root of the repo and we'll see what happens. And I can't set that working directory because all of these are uses steps. At least I don't think. What I could do is try, I'm okay with trying. Let's see, it was defaults and we'll say uses and we'll say working directory. And that is demo app slash web app. We can try that. The other thing is, yeah, okay, let's try that and we'll see if it works. Yep, give it a swing, man. I don't know that I can do that. So step one is done. We've got that set up and configured. It's not going to run because we haven't tagged a release. However, our other stuff is going to run because we're doing stuff that matches those triggers. Like when we open this pull request, guess what our CI is going to run. All of that's going to happen. We're burning a bunch of actions when it's right now. It's cool because it's free public repo. All right, so let's get the pull request open. We're going to pretend there's a good title. We're going to pretend there's a good body. We're not going to request a reviewer yet because we want to get a couple more things set up first. I guess I'll link it to our only open issue and let's get back to work because we're not ready yet. So let's come back to that branch and we need to add the docker file. All right, like we got all the docker stuff set up for the workflow for actions, but now we want to add that docker file to our code. So I'm going to come in here and let me just grab my docker file. Boom, really simple. Okay, we're going to grab node. We're going to set the working directory inside the container. We're going to copy all of this stuff over and we're just going to run npm start. It's not going to be fancy. It's not an overly complex docker file. And okay, I don't have it. I'm going to add a, well, I'll skip it. I was going to add a docker ignore file, but there's only one thing in it. So it's not a big deal since we're not really caring about trimming this container down or this image down to be super, super small. All right, so the damage has been done. And I think, I think this will work, but break. Okay, so I'm going to go ahead and merge this if I can get our request my approval now because we're going to pretend that all of our checks were good and sweet approvals in. And this one doesn't run until we tag or release. So would I want to wait that long? Probably not. Okay, I would probably build that container right now once the CI finished. I would say, hey, this job depends on this job. Give me that artifact now. But just to keep these a little separate and it gives me an opportunity to show you tags. Right, so you got to work with me here. We're breaking some conventions so I can show you stuff. All right, let's just double check that it's in there. Cool, Docker file exists. Great. Let's create a new release. It's simple. Choose a tag. What do we want our release to be called? We're going to call it V1. That's it. We're basic. Okay, we're going to say V1. The target I can set to a branch, right? I can set it to a couple other things a little differently like if I was using get from the command line. But in this case, we're going to set it to a branch. We're going to set it to main. We're going to call this our initial release. And we could write up some documentation. Here goes docs about our release. Maybe a change log exists here. Just say it wink. So maybe a change log exists here. This is where you might want to specify what's changed between your releases. You can set this as a pre-release. That's fine. But we're just going to live real close to sun. We're going to publish that release. Why? Oh, I didn't tag it. Sorry. Sorry, I didn't hit create a new tag. Yep, you got to do that. Create a new tag on publish. Hold on. I need to have control over the tag, which is the problem. Okay, I hit enter. I didn't click that. There we go. Now the tag has changed. So sorry. The reason we need control over the tag is because in our workflow, we said trigger when a tag gets created that matches a specific pattern. And that pattern was V anything else. So if I tagged this breadcrumbs, it wouldn't trigger our workflow, which is why I need to do that. Right. So I'm not just attached to the tag that much. There's a reason. There's a reason. Cool. That's it. We published a release. It zipped up some stuff for us. Some things I've done in the past is use like pandoc to take markdown files. And when I tag a release, it converts them into PowerPoints and then attaches the PowerPoint to the release so that clients or customers or other teams can download the presentation if they didn't want it in markdown. Right. So you can tie in workflows to edit releases and stuff. But now that that's there, look, we should have actions. Where are you? And that was a commit to main commit. Let's see. What doesn't it like? So it's failure and valid type for on interesting. So it's saying that our trigger is invalid. So it could have just a bad space somewhere on tags. Oh, wait, I saw it. Go back to it, dude. Did you? Yep. You've got a double. You got to. Oh, no, it's you're OK. You got V star. OK, you're OK. Coming to me sideways. Whatever, whatever. It's probably a release, not tags. I don't see a tags in here. So that's fine. So pretend that that works. And in this case, we're going to do a workflow dispatch in the event of time. And just so that we don't have to retag a release. Yep. And I hope that doesn't hurt the actual tagging of the workflow. We'll find out. So pushes happen. That's not what we want. We come up here, create and publish a Docker image. Let's run this workflow. Should we do? This is the worst part. You got to watch paint dry. As you're watching the paint dry, feel free to update your your profile readings. And it failed. And my guess is invalid workflow. Why unexpected value uses? Yeah. So it's saying that this isn't valid. What's awesome about this is you're seeing some actions troubleshooting. Remember that default section? I'm almost guaranteed I'm not allowed to use uses in the default section. So if I just click right there in the error, it opens up the workflow file for me to write to it. And it annotates what's broken. And that's exactly what I thought. I can't use this defaults thing. So there's going to be a bigger problem. And that's this probably won't be able to find what we needed to. Yeah. But the point being right there is just how smooth and easy that was to get to the source of the problem. Because oftentimes we're doing we're talking about pipelines and trying to figure stuff out y'all. I mean, just to sit there and stare at it and y'all I have done it so many times through my career. You know, you're sitting there at 3am in the morning staring at something like why isn't this thing running? And you just don't simply have the output from your from your development environment to figure out what it is. That right there's a big deal. The fact that it took us right to the problem. Yep. So we're going to let it run. And we're going to see it fail. I'm guessing because right. They can't find the files, right? They can't like a tag is needed to push to a registry. So maybe it's not a file problem. Maybe it's it didn't. Well, it didn't even get to building this. So, okay. So we can come back and find that. Right. And you're just going to drill this whole thing down until you get to the bottom of that, which this is a no Docker image version has been generated. No Docker tag has been generated. Check the tags input, which is interesting. So we're getting we're getting some verbosity on the feedback so that we know what to look for. Again, we're not going to spend a whole ton of time here. It didn't like the tags couldn't find tags, probably because it's supposed to come out of a version. Which I don't know if that got tinkered with because of the tags. So now I'm going to go through crazy troubleshooting here. Yeah, no, don't need to. But it shows you how we can find it really quickly. Yep. So you'll have this if you fork the repo so you can edit just that little piece to that that's in the web app. You could if you do it all from this, you'll see that it builds just fine. And it would upload it to the registry. That's kind of the point of what Matt just showed you right there. Like if we were working on this together and all of y'all could do this, you can fork that repo, you can hack away on it, figure out exactly what's going wrong. Then what do you do? Pull request. Yeah, open a pull request. If you want to solve it, pull request. Let us know. Hey, let us know. Hey, I found it. I know what it is that we can review it and go, you know what, dead on, add it back to ours. The NARS is updated. Yep. That's a really good point. And if you want to contribute back to this repo, that's fine too. You don't have to, but you're going to get like contribution graph stuff and it's good GitHub practice. And if you contribute back to our repo, we're probably not going to tell you that you screwed up. We're probably going to help you. So yeah, there's a difference. So I'm going to add in one last thing. We're going to close this issue. We're going to pretend that this, oh, we already closed the other one. We're going to close. I'll leave this open. Some of y'all are going to need that code. We're going to add one last thing and I'm going to do it without an issue. As soon as the code tab loads, I think I can, I think I can. No. GitHub has its moments. I'm going to add one last thing. I'm going to break the rules while I do it. And I'm going to stage workflows. I'm going to stage some workflows for you. Actually, I'm going to do this differently, I think. Yeah. So if you're, if y'all are going to fork the repo, wait a second. Don't do it yet. Yeah. I'm going to do this differently. Hold up a minute. I am going to add a file, but instead of creating a new one, I'm going to upload one. Hey, I figured this might be fun. Actually, I do need to create the folder first. Okay. Let's see if I can create that folder. Y'all, I don't know where he's going. I don't know what we're doing here. No, it didn't let it happen yet. Oh, it created it as a file. Oh, no. My goal is to show you can't just create empty folders. You got to create like a, like a, like a touch to file. Yeah. Yep. Readme.md staged workflows. Here are some examples for you. We'll commit that. Oh, me. Oh my, the demo gods said not today. They did not. This is why everybody knows are the worst. All right. One more time here. Staged workflows slash no, no, no. Readme. Staged workflows. By the way, there has to be a space. What's that thing for you? Yeah. Give it a space. Yep. Give it the space. Here are examples for you. Wink. Wink, wink. Okay. Cool. Great. So I'm in the stage workflows thing. I'm going to click on add file. I'm going to say upload files, which is cool because now I can drag and drop files and I don't have to do all that crazy like copying, pasting of the, the get flow, everything. So if I come to home, they come into INE, I should have all of my source code files right here. So it's like this out. I can just copy all of these. These are all YAML files and I can drag them right here. And that just did the upload on all of those files for me, which I can then stage workflows, right? That's a commit message. I hit commit and it's going to go ahead and it's going to add all of these. So that's just another small way that you could, if you're not a command line person, you know, text editors, you come into stage workflows and here you go. They're all right here. So I want to talk about a couple of these and then we'll get you guys out of here because it's Friday. So we looked at our check markdown links. Boom. It's here. We looked at our create and publish a Docker image. Boom. It's here. The next step could be taking that Docker image and deploying it to ECS, right? Spending up a container running Docker. This one actually goes through an entire build and tag process again, right? But nothing stops you from plugging this into Amazon. Nothing stops you from plugging this into Google or Azure or whatever. Here's an example workflow because some of you guys said you were a little a DevOps-y. So I would leave that example workflow in there for you, right? Which is why I said, I know it's not quite CD, but you put these pieces together. You got yourselves quite the CI CD pipeline. Okay. All right. Thanks, Matt. You're welcome. We've talked about the scheduled weekly sync and we did the update read me. Here it is. If you need to copy it because of that issue. And we did the CI portion where we ran some NPM tests. Okay. Let me see if there's anything in this file that's worth shitty chat chat. Now, first and foremost, whenever a push happens to the branch of release, this one triggers, that makes sense, right? We want to release code to Amazon when we make a push to the release branch. We just automated deployment. What up? We'd set some environment variables. Remember, setting GitHub secrets right here might not be the best play, but there's other places to set them down here. All of these secrets are stored inside of the repository secrets. And then the environment variables are read in. This is a specific commit. This is a release tag. I'm not seeing anything that's jumping out as... If you want to run more than one command in a run step, you can use some YAML syntax to run multiple commands. Okay. That's, yeah, I think that's about it. So what I really want to do, push that in. All of that's pushed. All of that's ready to go. If you want it, fork it. Yep. And you have all the notes to include all the code that exists, which you saw how bad it was running at your own risk. It's all there, but that should give you all the examples you might need. You got the project board. This is also a public repo. You can always come back to this and reference all the closed issues, what we talked about and what we did. And I just want to point out, we put on this whole three-day boot camp, and it didn't cost a single penny in GitHub fees. And we did a lot of stuff. Yeah, we did. And so going back to what's the catch, the catch is this is a public repo, and GitHub can now use it to train something called co-pilot, which I guess I'll leave you with because it's cool. Check this thing out. Co-pilot, my VS Code peeps, is a, I'm trying to zoom out just a tad. Okay. Co-pilot is an extension for VS Code that I do not have installed on this VS Code. Of course. So we'll install it really quick. I'll be careful with the one he's doing here, y'all. If you want to make sure, make sure that it's from GitHub, because people love to name their stuff after other things, and so you'll download some bad stuff. Yep. And then you get this cool little guy down here, and I don't want to disable co-pilot. We're going to leave you on. Co-pilot activation failed. Why? Well, let me register. Boo, hold on. I'm going to share a different screen with you. Let me grab my personal workspace, where I know these things exist. So you'll never write code again the same way. If you don't know what co-pilot is, is basically what this boils down to. Yep. And I just share VS Code specifically. Cool. All right. Oh, now all my Zoom windows are messed up. Hopefully we can see VS Code. I just lost the chat, so hopefully that's true. We got VS Code. Yep, we can see it. We can see it. I'll try to zoom in here for you. Awesome. Oh, that's too much. We'll close all of this out. Don't save. Don't care. All right. So I have co-pilot running over here. You can see it down here. It says, hey, would you like to disable co-pilot? Never. I can close the terminal. We don't need that. So if I were to come into whatever this is and say, I'm going to write, we'll just say JavaScript really quick, a JavaScript file. And co-pilot supports much more than JavaScript. I can do something like this. I can create a comment with co-pilot. Trying to make this a little bigger for you. And I can say import, express, and create a web server. And if I hit enter, it writes all this code for me. And it's sometimes correct. Use, there we go. It even knows the comments that I want. Listen for requests. And it'll write a lot of code. So there. Server is listening there. I've not written any code on my own. So I can just come down here. And there we go. It even had an idea. So this is what the catch is. GitHub is parsing all these public repositories to train this thing. So we can say create a route to handle the requests. Right, Matt B. Exactly. Yeah, but the thing about Matt A is that it is a little bit spooky. This is one of those things where if the product is free, you're paying for it somehow. You are paying for it somehow. Right. So pretty cool. Well, now security folks, fun fact, number 400. I'm sure this number has changed. Cool. Stop sharing. We don't need to anymore. I'm sure this number has changed. However, at one point in time when co-pilot was really new, it was responsible for 40, like the code that it would put up. 40% of the GitHub co-pilot suggested code was vulnerable. You still need a developer. You still have to have somebody that knows what they're doing to look through everything to make sure that the code is good. You're not going to automate yourself out of a job. Simply co-pilot parses public repositories. Let's think of who creates those public repositories. Tons of students, right? Tons of people learning to code, right? So half of co-pilot suggestions or almost half of their suggestions are written by people with little to no experience. And they were like 40% of the suggested code was vulnerable. So it's important to set up the pipelines around something like co-pilot. Co-pilot's not limited to JavaScript. If you're a DevOps person and you need like Kubernetes manifest suggestions, co-pilot will write your manifest. Co-pilot will write your Docker files. Co-pilot will write go for you. Co-pilot doesn't touch Rust. Actually, it might, I don't know, if you... I haven't even looked, dude, to see if it would do it. I would be really reticent to try that because Rust can be so tricky. As far as, you know, like ownership and stuff like that goes, it may take a minute for them to get something like that to work. At the same time though, Matt, couldn't we just as easily? Because I saw that we did have access. For those of you who don't know what a code guru is, is an automated system in AWS that will look at certain code, not all languages, but certain code languages and scan those. We can make that part of an automated process on the back end, couldn't we? Most likely, yep. There's probably an action for it. If there's not an action for it, as long as there's an AWS API for it, you could write an action for it. There we go. GitHub offers something called security folks. She might like this. It's called CodeQL. They acquired a company called Semmel a little over a year or two ago, and they brought in a different type of code scanning. It's not static code analysis from the point of view of like the typical, like static analysis that you might do. It's a pattern, like it observes the coding patterns that your developers have implemented and tries to detect vulnerable patterns in their code. And that is a direct feature, especially for enterprise GitHub that you can, and you can configure it on your repos. It's called CodeQL, and it fires off through GitHub Actions. And you can set all of these really interesting rules. There's a giant bug bounty program for it to write your own custom code queries to see what's pertinent to you. And CodeQL has found it's responsible for finding a ton of vulnerabilities and helping update all the CVEs that we see depend about you to say, hey, this is vulnerable or that's vulnerable. So CodeQL, you can tie that right in. That's a really cool thing. It's not a standard static analysis tool. You would still need to run static analysis if you wanted to be super covered, but it is possible. You have any parting thoughts for us, Matt, before I throw in... Actually, I'll start with... Oh, yeah. Look, I'm so GitHub, my cup has Mona on it. Oh, man, what a goober. Y'all, honestly, when it comes to... There's at I&E, we're really focusing, you know, not on what the industry wants you to learn. We're focusing on what the employers want, okay? Which means that we do things as like, Nellie will be talking to some of the biggest companies around there that hire IT staff, but this is also my personal experience. Being in the rooms with Fortune, probably every one of the Fortune top 100 companies, walking around and this is something I kind of did to myself. I would look at their laptops. Like if I was just in the back of the room talking with some folks, I was doing a lecture on something like that. I would look at the tools they were using. And typically these are the things I would see. Visual Studio Code, obviously there's coders in the room. I would see stuff like Terraform. I'd see Slack and I would see GitHub. This is a big demand skill. This is what folks are looking for. So anytime and again, thank you all so much for showing up. Huge deal for y'all, to us, for y'all to show up and be a part of this and see this delivery of this GitHub for everyone. But for you personally, I'm really, really, really going to encourage you. Keep working with the skill. Make this your daily thing, even if you're continuing to learn. Set up a repo for your notes. For a particular subject that you're studying and start putting notes in there. And go through the whole process. Issues, branches, do the whole thing. So when that day comes, when you're either at that job interview or congratulations already have the job, when they say to you, clone the repo, fork the repo, open up a pull request, your reaction simply is, I got this. Yeah, one of the ways that I really got involved when I was new with adopting GitHub, was I have like profile files, right? Like my dot files on my, my max and my Linux, right? Like both of those machines have like my Bash RC or my whatever config, ZSH config, right? For my terminal. And every time you reinstall those operating systems or those tools, like, you got to go through the pain of like reconfiguring them. And all it is is just text in a dot file, right? So consider creating a repo that's, that's for machine configuration where you just simply store all of your dot files. And then you can quickly set up your terminal if you ever need to reinstall your terminal app or whatever it might be. That's, that's how I got started is I did that stuff. And then I started storing like scripts and small stuff to help with my daily work inside of GitHub. And then that, that stemmed into now I'm doing applications, Terraform files, Docker, you name it, it's all there. But definitely start small, right? Pick something that matters to you in that moment you need it. It's all going to like turn on. You're going to be like, oh, thank God I had that in GitHub. Exactly. It's like one of our, one of the labs that I'm working on right now for our AWS track is you are completely out of luck. You don't have access to anything. And you've got to rebuild an environment. What are you going to do? Well, more or more to it, but at the end of the day, it's GitHub. It's pulling from the repo that's got your infrastructure as code in there, pulling it in there and throwing it back out. And again, having those GitHub skills, y'all, it's not going to be a nice to have in times to come. It's going to be a requirement. You're going to be expected. Like they're not even going to ask you, do you understand GitHub? There's going to say, hey, you need to fork that repo and figure out what's going on. That's going to be the whole conversation. Yep. So thank you all for your time. We're happy to hang out for a couple of minutes and answer any questions you might have. I'm just seeing a bunch of excited and thank yous coming in. Yeah. Thank you all. Thank you all so much. You're way too kind to us, especially Brooks. You shouldn't be that kind of Brooks. Yeah. Well, it's actually Matt that, you know, you have to be kind to him. That's all we have. I mean, bootcamp is wrapped. So enjoy your weekend and we'll hang out. And again, if you guys would, if you guys want to fill out the survey, we'd really appreciate that because that way we can actually say, hey, we actually did this thing. So leave us alone. That's true. Yeah. They kind of like to know that we do work. Actually, you know, as we're closing up here a little bit, hey, Adam, we're done, dude. If you want to close things down, we're just going to keep running our mouths. I kind of half lied to everybody when Matt said, when I said I didn't get anything from AWS. It's one of the funniest things for those of you who don't know the mascot of Amazon is a little character called Pecky. He's supposed to be peculiar. And when we first got that, we found that it was actually a USB drive and nobody at all used it. We all thought it was a security trick. You're like, if you plug that in, you're getting a call. Don't do it. Yeah, right? Don't do it. I, uh, when I was... Thanks, Patrick. I got really into social engineering early in my career. Like, because again, instructor, people, like the personality side of it. So I have cufflinks that are USBs, like they're USB cufflinks. So I had like whatever nefarious stuff I would want on those USB cufflinks, and I would just try to social engineer in my place to plug into places to plug in those USBs. Wow. Thanks, Matt B. Thanks, Lola. Hey, by the way, real quick about Lola, that's, uh, Carolyn, as you see there, she's the one that's got it rough. She's sitting in Tokyo. Oh, yeah, you're way crazy. She is very late, y'all, interacting with us. So thank you so much, Lola. That's awesome. She's probably laughing right now at me. Mm-hmm, yeah. 5.15 a.m., yep. On a weekend, come on. Yes, on a weekend. Two, two, two, well, cool. All right, so I think we're done, man. So if you guys don't have anything else, again, thank you. This was really cool of y'all to show up, participate, be a part of this. Wish you the best of luck. It was so fun. Absolute best of luck. Yeah. And you would need just fun. Yeah. And again, imagine if we'd been in a room, there would have been yelling and throwing. Things would have been thrown. Lots of throwing. There would have been throwing. So with that said, on behalf of myself, Matt, the awesome producer, Adam, everybody at AIONE, thank you all so much. And with that, Matt, click the magic button.