Insider tips to supercharge your GitHub workflow | DEM501

Key Takeaways

April's not on. I have There we go. There we go. Good afternoon. How is everyone? How are Yeah, good day. All right. They're metering out their energy. Going to be three days, four days. We got a few days to go. So, today we're going to talk about supercharging your GitHub workflow. We are not talking about GitHub co-pilot. We're going to talk about all usable things. And the most important thing about this, the most important thing what we're going to talk about, these are all things that you can use today. You can take away with, you can implement in your systems. Nothing's in preview. Everything is available to use and is practical. So I am April Yoho. I'm a senior developer advocate for GitHub. I'm based out of the UK and I'm here next to my amazing colleague, Christopher. I'm Christopher Harrison. I am also a senior developer advocate uh based out of uh right here in sunny Seattle. uh primarily focused on uh developer experience. So what are we going to talk about today? Well, first of all, more than just CI/CD. We're going to go demo heavy, but we've got a few slides for you all and a bit of references so you something to take away. Uh we're not going to talk too fast, I promise. But we want to talk about going faster. We talk about DevOps. We talk about speeding up our development cycles. Look at things to help us go a little bit faster, but we need to do that securely. So not just speed, but also security. So, the first thing we're going to talk about is more than just CI/CD. Does anyone here use actions for more than just CI/CD? A couple folks. The reason why I love actions is because you can do so much more than CI/CD. Um, I have tried to justified my existence in the tech industry by keeping myself doing me like these little tasks every day, right? But if you go on holiday or you're out sick, who does those? So, let's talk about some ways we can do that. So, instead of looking at a cool little slide, let's go into our little demo. While she's bringing that up, I want to highlight probably my favorite uh instance of using uh actions for non CI/CD tasks is somebody on the actions team. What she actually does, she has a manual action that runs and it goes out and it gathers all the different PRs and everything else that she's done for the week and generates a report and then she uses that both to like uh keep everything up to date but also come like reflection time, review time, then all she has to do is go back through everything that she's gathered through the rest of the year and then writing all of that out is just a real quick snap. So kind of a neat little use case there. So the not just the sorry exactly. So, uh, the first thing we're going to talk about is issue automation at GitHub. Everything we do is on GitHub. We build GitHub using GitHub. Our our marketing teams use it, our sales teams. And you think, but they're not technical. Absolutely. We track everything with issues. So whether you're an enterprise or maybe you're working on community projects, open source projects. When someone opens up an issue, what do you do with it? So very easily here, we can auto assign issues. We do this within our team. So if a request comes in, it auto assigns to Christopher. Or maybe I want True story. Uh the other thing I can do is maybe close invalid issues. Um you know issue cleanup, you know, we get a lot of stuff. So being able to automate your issues is really important. And another really good use case we see within a lot of community projects and other things is adding labels. But even in our development cycles, you know, we can add a label to a pull request or first-time contributors. Hey, welcome to the repository. Can we clean up stale PRs, stale issues? because cleanup is hard and it takes up a lot of our time. So we have a few workflows here that go through this. Now all the things I'm showing you is in VS Code. Um but actually you can the the repo these sit in I'll share with you all and you can see it externally as well and you can take a take a look at these workflows that we have going. Um and the other really cool thing is adding size of labels. So when we talk about DevOps estimation of tasks, how do we do that? Another cool thing we can do is generate documentation. How many of you love writing documentation? no one. So with that, as soon as we maybe uh put it submit a pull request um or any kind of push or commit, we generate a readme. So all we're doing here is generating a readme to every single folder structure within our repository. Why? Because it's hard. Now, we can also use our friend GitHub Copilot. However, we're not talking about C-pilot today. We're talking about actions. So with that, we can generate these documenta these documents and do other things with that. So I'm going to hand over to Christopher to talk about the next few things. Yeah. So, one of the biggest challenges that you wind up running into when you are uh running an action is the fact that you might have multiple tasks that aren't necessarily related to one another or at the very least can run in parallel. And so, when you go in and you uh set up your list of jobs and you create your jobs, by default these run in parallel. And that was a conscious decision by the actions team. So while yes, you absolutely can have them run in serial where I've got one at the top and then that uh is required to run for the next one to run the next one to run. I can set my depends on to set up the chain there. By default, all of these are going to run in parallel. So that way if I have those multiple tasks, I don't need one to complete to run the other. then I can go ahead and just leave them by default. And so if I head on over to my actions here and I'm going to do a little bit of a live demo, I've got my action that I've created here. I'll open up the YAML file in just a moment and I'm going to run this workflow. And what I want you to notice once I hit refresh to actually bring it up, there we go. is I get my little yellow dot here to tell me that that is running. And if I scroll down, come on, scroll down. There we go. You'll notice that both of those are now spinning. What that's telling me is the fact that both of those are running in parallel. Now, while that's doing that thing in the background, let me go ahead and open up my code in a new tab. Boop. And then sound effects help, by the way. That joke was just for my own entertainment. So was that one. Uh uh if I uh bring up the action file, what you're going to notice inside of here is I've got those two jobs defined. That I've got one that's going to run the tests on my back end. Just running some basic Python tests. And if I scroll on down, don't worry about the details quite yet. You're going to notice that I've got my build front end. And on there, I'm running the MPM build. So nothing really earthshattering here, but the fact that those can now run in parallel is going to help make my life easier. So in this particular case, you'll notice 25 seconds, 22 seconds. If I had to run those in uh in serial, that's going to be 47 seconds. Again, kind of a very simple uh job here, but obviously if we scale that out, you can start to see where all of that is going. So it basically ran about twothirds of the time because or half the time because it was able to run in parallel. But the other very big thing in here that I want you to notice is the fact that I am adding in caching that when we think about our mpm uh and our um pip uh requirements all of those can absolutely be cached. If I'm keeping everything to the same version I'm not bumping versions at the moment. I can go ahead and cache them. And basically what you're going to notice is I'm going to set up a path for the cache. And then right here, if it turns out that yes, we've got the dependencies, we'll go ahead and install them. If we don't, or sorry, if we don't have the dependencies, we'll install them. But if we do, if we've already got them in cache, then we're just going to bypass that step. And that's exactly what I've specified right here. So, if I go back over here to my uh workflow, there we go. And let's rerun this here. Hit rerun. And again, hit refresh to bring that up. And then we'll give this just a moment. Here we go. Moving your mouse makes it go faster. What we're going to notice is that this is going to run well faster because of the fact that it is pulling from cache. And once this is done, I should be able to actually open this up. Yeah, we can actually see right here. You'll notice that it skipped that install dependencies because of the fact that it was able to pull that from cache. And if I go back, that's hilarious that this is now going to take longer than the first time because why not? Live demo. I'm curious what Yeah, it didn't install the I don't know why that ran longer. But you will notice it did not install the dependencies. So, it did use the cache. It wasn't the dependencies that caused it to run faster. It was just simply the magic of doing a live demo. But there is how we can utilize that uh that parallelism and that caching to help improve performance. Boy, that test is just going to take forever. I'm going to leave that there. That's because you're running tests and maybe you have long running functional tests instead of short running unit tests. Who knows? Anyways, that's that's another problem. But we want to do all this securely. Uh we've released a feature in the last year where we can attest our builds. We've called it GitHub attestations. Say that a few times fast. So why do we want this? Um we want to know what we build is what we're going to deliver. So we need to prove that it happened. We need to prove that it happened correctly and it we need to prove that it happened correctly by the process and people who were supposed to make it happen in the first place. So we have announced addistations uh we have a couple different flavors of it. Um we have kind of a a private and a public version of it. Uh if you're running from a public repository you test with a public sig store. If you do it from a private repository, you it tests it with a GitHub sig store. It signs the the add astation. And again, if you're in a public repository, it puts it into a public transparency log. If you're in a private repository, it's in a private addestation store. So with this, we can achieve providence. We could have a a bill of materials. We need an esbomb. We could also have a storage record, a deployment record, but also we have Salsa level three compliance, which we've now achieved. So what's a use case of this? Let's look at a real life use case of what we want to achieve with this. So I've already ran a GitHub actions workflow just for the sake of time today. Uh I'd be happy to run this but I can look in I have this workflow that's been running. I ran it just a few minutes ago and when I go to run that oop sorry let me go back to my actions. So, I've done quite a few workflow runs. I'm going to go ahead and click on the last one that went and I'm pushing a container to GitHub container registry. Now, this now supports thirdparty container registry. So, Azure container registry. Uh you can push this to AWS, other places, wherever, uh Docker, etc. Um, very simply, I push this to GitHub container registry. When I build it, we can see that it creates an add astation. It shows that the add astation is created. It gives me a Docker build summary and it gives full traceability of everything. It also has the output. So if I go ahead and click on the output, I can look at the Shaw code. I can download it. I can dis I can get rid of it. Um or I can click on it and it will take me to the actual artifact that it's produced. We can store those artifacts, reference it and get a full sbomb and I can download it. I can then reference it and verify it. And if I click on the add astations link, it will take me to the page. So when we get an add a station link again I can download it from here. I can see the commit history the build history the summary everything. I can see which workflow file executed against it. It also shows me how I can verify it and it gives me all the informations of the certificates that I need and also the shaw code to trace it with. So we have that full endto-end traceability with our workflow that we ran and we can run that against any workflow. So to do that, I'm just going to go ahead and pull up the workflow file. So we've made it pretty easy to ingest into our existing workflows. So when we've set our job up, uh we need to give it permissions. So lines 14 through 17 here, we give it package write permissions, uh package write permissions, read content permissions, add a station's write, and ID token. So very simply, I'm going to log into my container registry. I'm building my Docker image and then I'm generating the artifact at a station. I can then pull it. I can expose it. I can also run the command line to verify it afterwards. So we've got an endto-end capability to know exactly what we built is what we intended to build. So with all that, we've put all these uh references up for you all to take away with um some other GitHub actions use cases, how to run concurrency, and our full documentation on the artifact addestation because unfortunately we've only had 15 minutes to talk about all the cool things actions can do. Um and if any of you all want access to the repository, uh we have these workflow files you can generate and take away with you, but the documentation will be the best thing to kind of get going as well. And I think that is right on time. Well done. So, thank you all for coming and uh if you have any questions, we'll be at the booth. We have tons of GitH GitHub experts here for you and I hope you all have a great build. Thank [Music]