Automation Basics with Github Actions

0:01Hi, Sean here and welcome to this skill where we're going to start this course off by taking a look at the basics of creating simple automations with github actions. Now, I will admit that I was a little bit conflicted with how I should begin this course because on one hand, I felt like I should probably start by telling you what actions are in the first place and what they're used for. But on the other hand, that's kind of a boring way to start a course. And so what I'm going to do instead is I'm going to walk you through a simple example where we're going to create and run our very first action.

0:37And this will basically just give us a talking point here to get into all of that other more theoretical stuff. OK, so as you can see here and actually just made an update to it there before I hit record for at least the first few videos of this course, I'm going to be using this quote of the day repo that I created. It's just very simple code. It's a simple Python program that generates the Python related quote of the day. And so if you want to follow along with me here, please feel free to fork this repo.

1:09It's private at the moment. I thought that that was probably a good idea to keep it private just in case I do something silly like accidentally publish an API key that probably shouldn't happen. But you never know when you're recording courses like this. Something always seems to go wrong like that. So I have a private right now, but I will make it public. So by the time you're watching this, you'll be able to find and fork this repo and you should be able to follow along with everything that I'm going to show you here without incident. All right.

1:39So, oh, and by the way, if you want to, you can also open a code space on this repo, right? Basically, this is just a hosted version of Visual Studio code that automatically opens up with all of the code at a particular point. And, you know, you can use this in order to see what this program actually does. So once you've installed the necessary dependencies, you can run the code just by saying Python 3. And then the file here is quotes.py. There we go. And sure enough, we see that that gives us a nice Python related quote.

2:13So very simple project. Basically, we just need something to run our actions against. So if you have another project that you'd prefer to use instead, maybe a personal project that you're currently working on, feel free to use that repo instead. Just know that some things might work a little bit differently. All right. So about that walkthrough, what we're going to be doing here is adding our first action to this repo. And there's a couple characteristics of this action that we're going to keep in mind. And I'll make sure to point those out to you when we run into something that is related to these characteristics.

2:49So the first thing is that we wanted to be able to let me try saying that again. We want to be able to trigger these actions manually. Now, this actually won't be the case for the vast majority of useful actions that you create. Why? Because one of the main purposes of actions is to automate things in GitHub. So, you know, if you have an action that, for example, runs your tests automatically when a PR is opened, which is a very common and very powerful use case for actions, as we'll see a little bit later in the course, you'd want that one to be triggered automatically.

3:24But for the time being, we're going to have our action triggered manually, which will make it much easier to run and demonstrate. Right. And the second thing here is we have to choose what we actually want this action to do, right? What do we want this action to perform in GitHub? Now, there's a lot of possibilities here. But for this very simple use case, what we're going to be doing is we're going to have the action print out a simple summary, right? A report on this repo. So we're just going to say print simple repo report, right?

3:59It's just going to print out things like what files the repo contains, the recent commits, things like that. All right. So this is a very simple use case. But, you know, you could maybe see this being useful in the real world somewhere, right? Cool. So that's what we're going to be doing. Just a simple action that's going to be triggered manually and print a repo report when we run it. So let's take a look at how we're going to put this action together. So the first thing to know is that the way that we add actions to GitHub repos is by adding files to the repos themselves.

4:38Now, this is different from a lot of the other things in GitHub where, you know, you actually have to create a construct. Right. So if we wanted to create a new repo, for example, we'd actually have to go back to our profile, go to repositories, and then click new and go through the process of filling out this form and creating the repository. That's not how actions are managed in GitHub, at least not in the majority of cases anyway. So let's go back to that repo. All right. We're going to open quote of the day back up. And if you haven't already, you're going to want to open up a code space or clone this locally so that you can actually make changes to it.

5:12Right. I'm going to be using code spaces for this course just because it's a little bit easier. And what we're going to do is we're going to start off by creating a new folder inside of this repo and we'll call that folder dot GitHub. Now, you may have seen this folder used in many different GitHub related use cases. The first one that comes to mind is if you want to provide custom instructions and you're using GitHub Copilot, you can do that inside this folder as well by creating an instructions file. But that's not what we're focusing on here in this course.

5:45What we're going to do next is we're going to create a new folder inside that folder and this one's going to be called workflows. Now, there's a piece of terminology that I'll need to clarify there a little bit later on, which is the difference between a workflow and an action. This is a pretty subtle distinction. So for the time being, I'm just going to call them actions. So we're going to create a new file and this is the file that's actually going to define the action that we want to create.

6:15All right. So here's what we're going to do. We're going to call this action repo report. And what kind of file is this going to be? It's actually going to be a YAML file. All right. So you might wonder why we're using a YAML file in here instead of writing our actions as Python or JavaScript files. Well, as we'll see, it is actually possible to write actions that use Python and JavaScript code, right? Or that run another script that uses Python or JavaScript. But more to the point, this is just, you know, a nice, easy to use syntax for defining our actions.

6:50But anyway, here's what we're going to do. You may have noticed that I gave you a code snippet either up above or down below this video. The first line is name repository report. I'm just going to paste that here. All right. And you can feel free to do the same, just copy and paste that code that I gave you. And by the way, if I run into any errors related to this code, I'll change the code that you're going to be copying and pasting. So if I typed any of this out incorrectly, which I very well may have, I'll make sure to make those changes in the code sample that I gave you.

7:23But anyway, what you see here is the definition of our first action. So let's just walk through this piece by piece. The first thing here we see is the name. Basically, this is what will show up in GitHub as we'll see a little bit later. So remember repository report as the name of this action that we're creating. The next lines here are on workflow dispatch. This basically tells GitHub when the workflow should be run. So there's a lot of other options that we can include here besides workflow dispatch.

7:53But workflow dispatch basically just tells GitHub we want to be able to trigger this thing manually. And that's the only time this action should run. All right. And then the rest of this stuff here, I'm not going to go into too much detail on that yet. But down here at the bottom, we see that basically what this action is doing is it's just running a bunch of shell commands, right? So it's just echoing certain strings, right? Info about the repo. And it's putting this into... Rephrase. And it's putting it into this environment variable called GitHub step summary.

8:27Now again, we'll go into this in a little bit more detail later on in the course. But the basic idea here is that anything that gets put into the GitHub step summary environment variable in an action will automatically show up as just text based output in the GitHub interface. So everything that we pipe into there, we'll eventually see when we run this action. All right. So anyway, that's our action. So the last thing that we have to do here is we actually have to push this action up into the main branch.

9:00And while I typically don't recommend pushing things directly to main for these demos, it's just going to make things a lot easier. We will take a look at pull requests a little later on in the course when we see how actions can help us with that. But for now, let's just stage these changes. And then for the commit message, we'll just say something like added our first action, right? Well, let's not start putting exclamation points on commit messages because then where do you stop? Anyway, let's click commit here. And then we're going to push our changes up to GitHub. We'll say OK.

9:31And now if we go back to our repo here and hit refresh, what we'll see is that sure enough that GitHub workflows folder shows up there. And if we go to this actions tab, you may have noticed this thing before and even taken a look at it. What you'll see here is that sure enough, there's this repository report thing over here on the left hand side. All right. So let's click on that. And what you'll see here is that it says this workflow has a workflow dispatch event trigger.

10:04And as I mentioned earlier, when we were creating that file, this just gives us the ability to run this action manually. So if we go over to the right hand side here where it says run workflow, we're going to click this. We're going to select that. We want to run the workflow from the main branch and we're going to say run workflow. So what we'll see here is that it'll kick us over to this other screen where it will show our workflow or action. I've been calling it. I'll describe the difference in those two terms shortly. Sure enough, we'll see our action run and we can easily see the output of it down here at the bottom.

10:40All right. So this is exactly what that GitHub step summary thing that we were putting text into back here in our YAML file does. Right. Just shows up at the very bottom of the report when we run an action. All right. So we see that that gives us the number of files, the number of lines of code and the latest commit, right? Basically, that was the one that we just created there. So anyway, that's how to create and run your first action. So now that we have this as a talking point in the next few videos of this skill, we're going to be taking a look at some of the most important details of creating and running actions in GitHub.

0:00All right. Well, now that we've seen how to create and run our very first action, it's time for us to take a look at a few additional details here. Now, the first thing that I want to talk about is the difference in terminology between a workflow and an action. And as a matter of fact, to complicate things even further, this is a slightly different thing, this type of action from what are commonly known as GitHub actions. All right. So let me just sort of step through those terms here. I'm going to actually start with GitHub actions because that is in fact what, um, for example, the GH 200 certification is about is GitHub actions. So GitHub actions refers to the overall GitHub product and platform, right? So that's why this actions tab is up here at the top. And while I've been saying that we've been creating a custom action here with our repository report, really, it would have been more correct to say that we're creating a workflow. I basically was saying that just so that I didn't have to introduce those multiple terms and have this be the first conversation in the course, which would be, you know, again, kind of, kind of boring. But so this thing is actually

1:17a workflow that we created. And then inside this workflow, if we open this thing up and take a look at the workflow file, which you can do from, uh, you know, the, the results screen in GitHub, if you take a look down here in the steps section, you'll see that it says uses actions slash checkout at the seven, right? Now this here is that other term action as distinct from GitHub actions, the platform, because basically this is a reusable thing that we can have our automated workflows do in GitHub, right? So specifically what this action does is it checks out the code from the branch that we're running this workflow on, right? This is important because as we'll see a little bit later, uh, when you run a workflow like this and you want to actually perform operations on the code, like what we're doing down here, the workflow itself starts off in an empty container. And so you have to actually manually check out that code in order to have access to it. Again, that's something we'll talk about in much more detail later for the time being, all you have to know is that this is an action and the interesting part about this and why I felt,

2:36you know, pretty comfortable calling this thing that we created an action as well is the fact that as we'll see later in the course, GitHub actually allows us to create our own custom actions from workflows that we've created. So if we wanted to create an action around, uh, generating a report like what we've done here, we could do that. And then you could call that by saying actions slash, uh, we'd probably call this something like repo report or something like that. Again, that's something that we'll take a look at much more detail later on.

3:08Just wanted to clarify that terminology for you. So once again, GitHub actions is the platform from now on, I'm going to call these things that we created here, workflows, and then workflows have individual actions inside of them that do things like check out code, or there's other actions for installing, uh, runtimes. Like if we wanted to test a node JS app, there's a specific action that will install node JS, which we'll need in order to run the tests for it. Okay.

3:38Anyway, now that we've cleared that up, the next thing that I wanted to do in this video is talk about the basic structure of these workflows, right? So in other words, if you want to automate some sort of process by creating a file, like what we just created there, how can you do that? Right? What are the basic, what are the individual pieces that you have to put together there? Well, the entire mental model of workflows and GitHub actions is as follows. It starts off with an event. I'll describe each of these in more detail shortly. The event leads to something called a job. That job is executed by something called a runner. That runner performs the steps that we've specified in the workflow. And unfortunately I'm running out of, uh, running out of space here, so I'm just going to have to go down there instead of to the right. And finally, running those steps produces some sort of output, right? These are the main pieces in any automated workflow that we put together in GitHub actions. All right, so let's go back and talk about each one of these things in more detail. We'll start off with the event here. The event is, uh, you can call it the trigger, I suppose. In fact, that's what I called it in the previous video,

4:56that starts the workflow in the first place, right? Or let me put it a different way. This is the thing that happens in GitHub, right? Maybe a new pull request being created, a new issue being created, a pull request being merged, perhaps that we want to serve as the starting point for the workflow that we've created, right? So currently we have this as, and here I'm just going to write this above it. Currently we have this as workflow dispatch, right? Basically meaning that we can run this thing manually, but there are many other events that we can put in here instead. So for example, if we wanted this workflow to run whenever someone pushed code to a given branch or to a given repo, we could use the push event. If we wanted this to, um, respond to pull request events, we could use pull request in there instead of workflow dispatch. So again, there's a lot of different options that are available to us. The point being that this is the starting point of every workflow. Every workflow must have an event that triggers it. All right, moving on to the next piece here, the job. So when we set up a workflow and we say that we want it to happen when a particular event occurs, it can be very tempting to think that immediately when that thing happens,

6:16right? When we click that run workflow button or when we push code, or when we open a pull request, it can be very tempting. As I was saying to think that GitHub is immediately going to execute whatever code we've put inside that workflow. Now that's not the case. And this will become much more important later on in the course. When we talk about doing things like, um, creating and managing self-hosted runners, but basically before the workflow is executed, GitHub creates something called a job that basically represents a single execution of that workflow, right? So to give you a, an example of this that should hopefully help clarify this, let's think about the workflow that we just created there, which is triggered manually because of this workflow dispatch setting. If we were to trigger it three times in a row, what GitHub would do is it would actually create three jobs, one, two, three here behind the scenes to run that, right? So this is a what repo report, repo report, repo report. Those would all be, um, different instances of the same workflow. I feel like that explanation might not have been the best. So let me resort to a perhaps less classy metaphor here. Let's say that three

7:37people walk into a fast food restaurant like McDonald's and they all order a hamburger, right? This person says, I want a hamburger. This person says I want a hamburger. This person says I want a hamburger. I just write H there because I don't feel like writing out the entire word hamburger. Well, that restaurant of course, or the person working there wearing one of those little visors that they always seem to wear at fast food restaurants, that person's going to have to make three distinct hamburgers even though those three customers just ordered the same thing, right? And the same thing goes for jobs. If the same workflow gets triggered three times, GitHub is going to have to make sure that it runs it three times. So that's, jobs are basically just the way that it keeps track of that. All right. Hopefully that makes sense there.

8:24Again, this will make a lot more sense when we actually get into creating self-hosted runners and you'll see that we can actually choose where those jobs are run. That can make a big difference in your understanding there. But anyway, moving on to the third step here, the runner itself, this is the machine or the environment that actually takes these jobs and runs them. All right. Now again, this is for the time being, and in the example that we just went through there, we're using GitHub's built-in runner. Now what this means is that our workflows are just being run on GitHub's own infrastructure. So somewhere in there, GitHub has a server. I'd imagine they have a lot more than one server, but you get the idea, right? Somewhere in there, GitHub has a server that's going to be executing a given job. All right. And again, later on, we'll see how we can have self-hosted runners where we actually have our own computer be the one that runs these jobs instead. This can be a great way to save costs in certain cases. So anyway, we'll talk about that later, but moving on to the next part of this pipeline is steps.

9:33Now we already saw the steps in the YAML file that we created. These are just the specific things that we're telling whatever runner our job was assigned to, to do. All right. So basically, the steps just say, first, do this. Second, do this. Third, do this. And then fourth, do this, right? You can have as many steps as you want in theory in a workflow. And finally, we get to the output, which is essentially the value or values that a workflow wants to communicate back to GitHub or to other workflows that might be following it. Another thing that we'll take a look at later on in this course is how to have multiple workflows cooperate together. All right.

10:17And in our case, with the workflow that we created, the output was just the report that we created, right? The repo report, which contained all of the details, just some simple, which contains simple details about the repo, like the number of lines of code, the number of files, and the latest commit. All right. So anyway, that brings us to the end of that explanation. I would highly recommend taking a screenshot of this or otherwise just writing this down somewhere, because this mental model here will cover, I would say, probably about 95% of the situations that we're going to be walking through throughout the rest of the course. So this is a very important framework to keep in mind as we continue on.

0:00All right. Well, now that we've taken a look at the basic framework or mental model of workflows and GitHub actions, the next thing that we're going to do is we're going to make a few changes to this workflow that we set up. Basically, now that we've talked about that framework and seen the different pieces that are involved, I want to just briefly walk through what it looks like to change each of those pieces and how that impacts the workflow and how it behaves. So here's what we're going to do. We're going to start off by changing the events that will trigger a workflow. So here's what we're going to do. We're going to go back to our code space here.

0:38All right. So the first thing that we're going to do here is we're going to play around with the events that will trigger this workflow. So currently we just have this on workflow dispatch thing, which is I've, I believe I've already said a few times, um, this will, uh, allow us to manually trigger this workflow. All right. So that one we've already seen, but let's just add a few other potential triggers and see these in action. So if we want this workflow to be run, whenever someone pushes code to this repo, all we have to do is say push. And I'm putting these little, uh, colons after each of these things, this, what this will allow us to do is we'll see later on in the course is it'll allow us to filter these things further. So if we only want to run a particular workflow, when we push to a specific branch, what we could do again, we'll take a look at this in much more detail later, but we can say push branches main. And this would mean that this would only trigger this workflow if the push was to the main branch. So I'm going to leave those out for now, just for demonstration purposes, but that's the basic idea here. And why we're working with this funny syntax where there's nothing inside each of these. All right. Um,

1:55so let's, uh, let's also do pull requests here and that should be all we need to do for now. So let's commit these changes. We're going to just, um, stage those changes. We're going to say added new triggers, and we're going to commit this code. All right. So we'll sync those changes with GitHub. All right. And what we'll see now is if we go back to our GitHub repo, and in fact, let's go back to actions. All right. So as you can see, not only did we update this workflow, but in fact, the act itself of pushing that updated workflow to GitHub caused that workflow to be triggered. All right. So we see that we still have this old run of our workflow from when we executed it manually, but we now have this new run that was caused by that commit and push.

2:44So if we open this up, what we'll see is that pretty much everything is the same, except it was run on a different trigger, right? And in fact, if you look up here at the top left-hand corner of the info, you can see what caused a particular run of a workflow. So in this case, we see Sean Wassell pushed, and then it lists the commit. And if we go back to the other one here, let's just go back to our repository report there. We'll see that this says manually triggered one hour ago by this person. So hopefully that's making sense so far. The other thing that we added is this pull request trigger. Now, this may seem a little bit vague to you at first, right?

3:28What on earth do we mean by pull request? Do we mean opening a pull request, updating a pull request? What is it? Well, we'll take a look at this a little bit later in the course as well, but basically, we can zoom in on the exact events that we want to trigger here, right? So if we only wanted to trigger this workflow when a pull request was opened, we could say types, and then we would say opened. We'll get into that syntax in much more detail later, as I said, but the way that we have it now, this workflow will be triggered whenever anything happens that's related to a pull request. So when a pull request is opened, when it's updated, when it's closed, anything.

4:07Not typically what we want, by the way, but it's just for the sake of demonstration. So let's go back here and just see this in action. What we're going to do is we're going to go into our pull requests tab here, and actually, I don't know if we'll be able to open a new pull request if we don't have a branch to use it for. So let's actually go back to our code spaces here. We're going to quickly create a new branch, make a small change, and then push it up, and so here, let's just say branch. We'll say create branch. We'll call this branch something like trigger demo, and then what we're going to do is we're going to make a very small change to this. We'll just make a change to the code here somewhere. Maybe we'll add a new quote, and I'm actually going to add one from the pep8 style guidelines. A foolish consistency is the hobgoblin of little minds. Feel free to look that one up if you want to understand the context around it a little bit more, but anyway, now that we've made that small change, let's go back to our source control tab.

5:07We're going to stage this change, and we're going to push this up, which in and of itself will trigger this workflow to be run again. So we'll just say added new quote. We'll say commit, and we're going to publish this branch. All right, so now that we've done that, we should be able to open up our pull request. Let's just hit refresh here to reload those options, and we're going to say that we want to merge trigger demo into main. So we're going to say create pull request, and what we should see now, this goes back to what I was saying in the previous video about the importance of unique jobs in GitHub actions, is because we did two things, one after the other, that both triggered the same workflow, we're going to see that that workflow was triggered twice. All right, so let's just create this pull request, and now what we should see once we create that is, let's just go back to the actions tab. Sure enough, and this is actually kind of interesting because we get to see this thing is currently in the state of being run on this list, but we see that we have two new runs. The first one here, the first job is from when we pushed that commit to that new branch. The second one here is from when we opened that pull request,

6:22and you can see that actually just below the name for each of these runs, where it says pull request number one opened by, that's what triggered that. This one says commit blah blah blah pushed by. All right, so anyway, that is what happens when you play around with the triggers for a workflow. Let's take a look at some of the other things that we can play around with here. So in this particular workflow, again, we're just putting together a very simple summary of the repo that we're currently in. So it just prints out, again, the number of lines, the number of files, the latest commit, et cetera. However, as you can probably imagine, because we have the ability to run shell commands in this workflow, and we can edit this code as much as we want, there's a lot more than this that it's possible to do. All right, so here's what I'm gonna do.

7:10I'm gonna create a new workflow, and what this workflow is gonna do is it's actually going to run this quotes.py Python script instead of put together a summary. All right, so here's what this is gonna look like. We're gonna say new file. We'll say something like display quote dot yaml. All right, now that we've done that, let's go back to repo report dot yaml. I'm gonna copy this code in here and then paste it into here as a good starting point, and then let's just go through, we're gonna rename this one something like display quote, and then just to simplify this part back to what it was before, let's change this back to only workflow dispatch so that we'll only be able to trigger this manually, and then for the steps, we're gonna remove all of these shell commands here and replace it with a shell command that will run the Python script that we have in here, quotes.py, and put its output into that GitHub step summary variable that we saw earlier.

8:14All right, the same one that we used to put our report together here. That might sound a little bit confusing, but it'll be, it should be pretty straightforward, so here's what this will look like. Under run, we're gonna say echo, and then in double quotes, we're gonna say greater than sign, and then dollar sign, and in parentheses, we're gonna say Python quotes dot py, and then we're going to send that into the GitHub, there it is, step summary environment variable. All right, that might be a little bit confusing if you're not familiar with these types of commands, but all that that's doing is running our Python script and putting the output into the step summary. All right, now before we go run this workflow, there's actually a few more things that we're gonna have to add in order to make it work. If we were to run it now, we would get an error saying that it wasn't able to run this Python command. Now the reason for this is that by default, the container that our workflows are running won't have Python installed. Now the good news is that this is a pretty easy thing to add, and this will actually give us a little bit more experience with these actions, like this action slash checkout thing that we used to check out the code from the repo. What we're gonna do is down here under uses, we're gonna add another

9:31bullet point here and say uses actions slash setup Python at V7, and then underneath this, what we're gonna do is we're gonna say with, and then Python dash version, and you can choose whatever version of Python you wanna use, let's just use 3.13, and that will install and set up Python for this container, right? That basically brings that into the environment that this command is gonna be running. All right, so that should be all we need to do in order for this to work.

10:04So here's what this is gonna look like. We're gonna commit our changes, and actually let's switch back to the main branch here. We're just gonna say git checkout main, like so. That'll carry those changes over. So let's go back here, and we're going to stage that change that we just made. We'll say added display quote action. We're gonna say commit, and we'll sync those changes with GitHub, and now that we've done that, what we should see first of all is that we'll have another action available in here, and actually I'm not quite sure why it's being displayed in that ugly format, but we do see that it failed. That was actually because of a typo.

10:43As you can see here, I said users instead of uses, kind of a silly mistake there, so let's save that. We're gonna have to push that change up one more time. Corrected typo. We'll say here, we'll stage that change, commit it, sync the changes, and now if we go back here, hopefully we'll see that that will refresh for us, and sure enough, we see display quote is now displayed with its correct name that we gave it in the YAML file. All right, now let's open this thing back up, and what we'll see is that it's already run once. I actually don't know exactly why it was run just then. Maybe the same reason that it was displaying the wrong name up there. Maybe it's just a bug, or maybe that's intended behavior. Anyway, let's ignore that for the time being. I'll investigate that later, and what we're gonna do is we're gonna manually run this workflow on the main branch, and what we should see is... Let's just wait for that to finish.

11:35There we go. Sure enough, it runs successfully, and we see our Python quote of the day printed out here in the report summary. All right, so on the surface, this might seem like just another simple example of how to set up and run your own workflows in GitHub, but this actually hints at something very important around the usage of workflows and what we can make them do. The idea here is that because we can run arbitrary scripts like, you know, this Python quotes.py script here, this means that anything that we can express and run in some other programming language like Python or JavaScript or Java or whatever can, in essence, be incorporated into a workflow, and that is a very exciting possibility, right? This is a strategy that we'll be seeing a lot throughout the rest of this course, but anyway, hopefully you enjoyed that demonstration, and hopefully that helped you to understand some of the ways in which we can modify some of the most important pieces of our GitHub Actions workflows.

0:00All right, well at this point we've taken a look at a number of different examples that have hopefully helped you get a little more familiar with the basics of workflows in GitHub. So it's time for you to do a challenge now, and this challenge is going to have two parts. The first part of this challenge is going to be, you may have noticed that if you go to actions, there's this new workflow button. Have you tried clicking on that yet? What you'll see is that it actually brings you to this interesting page where it has all sorts of common workflows for different situations.

0:32So the first part of your challenge then is to take a look at a lot of these that are listed here and see if you can figure out how to integrate one of these into the existing project that we're working with. That is, if you're working with my repo here. If you're working with one of your own repos, obviously your needs are going to be a little bit different. All right, so as I said, that's the first part of your challenge. The second part of your challenge, and you may be able to find it if you search through these workflows. So if you can find a workflow for it, go ahead and use it, otherwise you'll have to figure this out for yourself.

1:05Anyway, the second part of your challenge is, given what we learned in this display quote workflow that we set up, you're going to need to create another workflow that will automatically run the tests on this repo against the code that they support. So you probably noticed that we have quotes.py, which has the production code in it. But then we have this quotes.test.py file that runs some tests. Really it's just one very simple test against that production code.

1:35Now this is another very common use case for GitHub Actions, is creating a workflow that will automatically test code when, say, you open up a PR or when you push that code up to GitHub. So that is the second part of your challenge, is to simply create a workflow that extends this one here, right? You might want to use this one as a starting point. And that runs the tests for this repo. Now in case you haven't looked at the readme file yet, this does have some information, in case you're not familiar with Python, that might be very useful for you, right?

2:10For example, it shows how to install the dependencies for this repo, which is an important thing. And then it shows how to actually run the tests. So anyway, that is your challenge. Feel free to give this maybe five to 10 minutes to complete. And once you've given it a try, you can move on to the next video where I'll walk you through the solution. So best of luck, and I'll see you in the next video.

0:00All right, well, hopefully you gave this challenge a try, so let's take a look at the solution. So the first part of the challenge, again, was to choose a workflow from this aptly named Choose a Workflow screen and see if you could integrate it into your repo. So what I did here is I chose this PyLint one. This one was nice and straightforward. And if we open up this, or rather click on this little Configure button, what you'll see is that this actually shows us the exact code or the exact YAML that is needed for this workflow, right?

0:36So some of this might look familiar, right? Like this actions slash checkout v4 thing, actions slash setup Python v3 thing. In fact, these might be a little bit out of date. If you try and run this, you might get some errors because I believe v4 and v3, well, I know that they're not the most recent ones. The most recent versions are v7, v7, at least at the time of recording. So my suspicion here is that this is a little bit of AI generated code. I see that quite a lot when using AI to generate these types of files.

1:06It tends to work with older versions. And I mean, more evidence here, Python version, it only goes up to 3.10, which is not one of the more recent versions. But anyway, another thing to notice, which is something that we'll talk about in much more detail later in the course. You're probably tired of me saying that by now, but well, that's the funny thing about workflows and GitHub Actions is that it's really kind of difficult to teach one thing without teaching everything. So there's just a lot of things that I have to say. We'll talk about that later. But anyway, this thing here is something that we'll take a look at in more detail later.

1:39This is called an input. Basically, this allows us to run the same workflow with different configurations. So if we wanted to run this with different Python versions, for example. But anyway, then down here, we see the actual script that it's running. It's running this pylint script and basically, what that's going to do is it's just gonna run a quick static analysis on our code to make sure that everything looks good. So let's try this. What we're gonna do is we're just gonna click commit changes. Note that this screen allows us to commit directly to the main branch.

2:11So for commit messages, GitHub Copilot just added that here for us. Nope, that's not what we want. Let's try this again. We're just gonna say something like added pylint action. All right, and we'll just say commit changes and that should commit it directly there. So let's take another look at this workflow here to see exactly when this is going to occur. Sure enough, we see a slightly different syntax here for on push. But basically, what that means is that this thing should already be running. So if we go back to action and take a look at the pylint action here, what we see is that it looks like it failed because I wonder why that is.

2:49You can always open these things up and look at them in more detail to see what happened if you want. But actually, this is expected because it looks like our code failed some of the pylint checks. This is something that you want, for example, if you really wanna be strict about the code that makes its way into your main branch. So a lot of people will actually make it so that you can't merge a PR if the pylint checks don't pass. So we could go through and fix those things. We're just gonna leave it for the time being. But anyway, that was the first part of the challenge. The second part of the challenge, of course, was to create a new action that would automatically run our Python tests for us.

3:27So first of all, let's actually pull the updates, right? We're just gonna say fetch and then we'll sync the changes like so and say okay. All right, we should see that we now have this new pylint.yaml workflow in here. But anyway, let's create a new file here. We'll call this one something like run tests.yaml. You don't have to be super creative with your names here. The more explanatory, the better. And we'll start off with the displayquote.yaml file. I'm gonna copy and paste that into here. We're gonna change the name, of course, to run tests.

4:00And you can choose exactly when you want this to run. Probably a wiser choice here would be to have it run on push or when a pull request is created or updated. But for the time being, we'll just leave it at workflow dispatch so that we can run it manually. And everything else is pretty much the way we want it except instead of generating a report, we're gonna install all of our dependencies and then we're going to run our tests. So here's what this is gonna look like. All right, so we're gonna say name install dependencies.

4:32This is the name of the step, by the way. You don't have to use this, but well, it makes it a lot easier to tell what step is running and it helps to separate things back here when the action actually ran. That's what we're seeing here is the names of each of the steps. All right. So we're gonna say run and this will be the actual code that's run. So we're gonna say here, we'll just go back to readme.md as I showed you before. We're gonna install requirements.txt. And now that we've done that, the next thing we're gonna do is add one final test or one final step rather that will run the tests.

5:05So we'll say name run tests. And then underneath this, we're gonna say run and we're gonna say python-m pytest is what I meant to write there, right? That's what we saw in this readme.md file. All right. And that's all we should need to do. So let's save this. We're going to push it up to GitHub by committing it. So we'll say added run tests workflow. We're gonna commit it. We'll say sync changes.

5:35We'll say, okay. And now that we've done that, what we're gonna do next is we're gonna go back and manually trigger that workflow. So we're gonna open up actions here one more time. We see our run tests workflow is in here. And now if we select run workflow and we'll run it on the main branch there, what we should see is that this thing will run and it will execute our tests for us. Now, whether or not this thing actually completes successfully, much like what we saw with PyLint, this depends on whether the tests pass or not.

6:10All right, so we got that little green check mark, which means that the tests must have all passed. So if we go to this run tests step, sure enough, we'll see that it ran one test and one test passed. All right, so anyway, hopefully you enjoyed this challenge and hopefully it helped to solidify a lot of the concepts that we covered in this skill.