My 3 Commonly Used Github Actions and their benefits

Transcript

Hi, my name is Stu, and if you're new here, this channel is all about me breaking down different technologies into easily digestible chunks. In this video, I'm going to take you through a few GitHub Actions that can help elevate your GitHub repositories and automate some key tasks for you.

In my previous video on git hooks, one of the things that I promised you is how to validate a commit message on the server side using GitHub Actions. This is just one of three GitHub Actions that I'm going to show you today, with the others being checking to see whether a file is included in a pull request, with the last one being updating all of your NuGet packages inside of a single pull request. So all of the GitHub Actions I'm going to show you today live underneath the .github/workflows folder inside of your repository. All of these GitHub Actions will be available on my videos repository, which there'll be a link to in the description below.

The first one that I'm going to take a look at with you is the commit message check. If you're unsure of why we're taking a look at this one, in our previous video on git hooks we said that we couldn't run a git hook on the server side due to security concerns with GitHub. However, one of the things that we might want to do is check the commit messages for a Jira issue number, and we can run a GitHub Action to validate this.

So with the commit message check, we first define a trigger that runs on a pull request when it is either opened, edited, reopened, or if any updates are added to the pull request in any way. For the steps of the job, we run two different steps. The first one gets all of the commits for the PR, and the second one runs a regex against each commit in order to validate the message. To do this, we run two different actions, both from the Tim Actions collection. The first one utilizes the Get PR Commits, and this one requires a GitHub token secret that is available for all GitHub Actions. The second is a Commit Message Checker With Regex, also from Tim Actions, that takes the output of the previous step, runs the specified pattern which is the exact same pattern that we ran in our git hooks video before, and lastly provides us with an error message.

Before I show you this in action, I'm going to show you the next GitHub Action, which is the check file for updates on PR. So the purpose of this GitHub Action is to verify that a file has been edited as part of the pull request. An example of why you might want to do this is if you have a manual process for updating something like a changelog, or you have a file that needs a version to be changed.

To do this, we've got a couple of triggers in place. The first trigger is a push trigger on the main branch. Now this could be useful for actions that happen after a file has been edited in the pull request. The next trigger is the same as the trigger we saw on the previous GitHub Action, which is any updates on a pull request that are opened, edited, reopened, or updated. For this GitHub Action, we actually have three steps. The first is the standard checkout step, meaning that our code is checked out for us and we have access to it. Next, we use an action from Foodie which is the PR Includes File Change, and here we specify the paths that need to be changed. The important note here is that we only ever run this when it is not the main branch. We also specify an ID for the step called "change" because we need to refer to it in the next step.

The second step simply checks the output of the first step by referencing it by the name "change" and checking to see whether the output called "match", which is declared inside of the action above, does not equal true. If it doesn't match, then we know we haven't had the file edited and we need to tell the user. We can do this by simply echoing out to the console and then making sure we call exit 1. This will tell GitHub Actions that we have an error in this application and we're going to abort the action.

So now let's take a look at both the GitHub Actions that we've currently seen and how they run inside of GitHub. So the repository that I'm showing you here has had a pull request raised by Dependabot. This pull request doesn't edit the file that we want, and it also doesn't contain a Jira issue number. We start to scroll down to the checks at the bottom. You see we have two failed checks. So let's click on the details for the Check File Updates on PR. Inside of this check, you can see that it's asking us to update the source file because that's the thing that we need to do in this repository. And if we go to the files changed, we can see that that file has not been edited in any way. If we go back to our checks, we can also see that our commit message check has also failed. So let's have a look at the details there, and again it goes straight to the bottom and says commit message does not contain a Jira issue number. And we can see by the commit, there is nothing in the message that contains a Jira issue number.

As with any other code, our GitHub Actions need to be kept up to date, and this is exactly what this pull request is about. I've set up a Dependabot config to automatically update all of my GitHub Actions inside of this repository to the latest version of the actions when they are available. This is a task that Dependabot is very good at, and something which I'll show you how to configure now. Switching back to our repository, we have a Dependabot.

yml file that is located underneath the .github folder. This configuration file is used by Dependabot to determine which ecosystems that Dependabot supports, when you want each ecosystem to run, and specific actions for that ecosystem. The configuration that I've got here specifies the GitHub Actions ecosystem, and it looks across the whole repository daily and it only sets a limit of 10 pull requests at any one time. This is just to ensure that my repository doesn't get overloaded if I have lots and lots of updates on a given day. For a full list of the ecosystems and the available options for this, I'll put a link to the Dependabot configuration settings in the description below.

One common task in the .NET world is to upgrade our NuGet packages to the latest versions, usually in response to security vulnerabilities or performance updates and bug fixes. Dependabot does have an ecosystem for updating NuGet packages, but it treats each individual NuGet package as its own individual PR. For small repositories this may work for you, but it can also create a lot of noise. This is where the last action that I'm going to show you comes into play and solves part of this problem for us, and this is our Update Outdated Packages GitHub Action.

So the purpose of this action is to run once a week and update all of the packages if they're needed inside of your repositories, and it does this using the dotnet-outdated tool which I'll put a link to in the description below. So taking a look at the triggers for this action, we have two distinct triggers. The first is the obvious on schedule that we run 6 a.

m. on every single Monday. The next is this one called workflow_dispatch. This is a special trigger defined by GitHub, and that allows you to run the GitHub Action from the UI at any time that you choose.

Now that we've taken a look at our triggers, let's take a look at the steps in order to update all other packages in a single go. The first one is we have a checkout action which checks out our code. Next, we set up the correct version of the .NET SDK. For reference, I'm using 3.1 but you could use any version of .NET that is supported by the action. The next step is to install the dotnet-outdated tool, which is a really good tool, very customizable, something that I thoroughly recommend you check out. I'll put a link to this in the description below. The next thing that we're going to do is check out a new branch, and we're just going to call this dotnet-outdated because it's going to be something very specific. And to ensure that we have all of the packages loaded and all the package information, we're just going to run a dotnet restore as our next step. Next, we actually get to run.

dotnet-outdated. When we run this, we've run this with a few command arguments. The first is the -u flag which tells us to upgrade. The -f flag which tells us to fail if there's any failures to update. Next, we lock in the version number, so we can either specify major or minor here, and we're going to lock to the specific major version. This allows us to stay on the same major or minor version and just either get bug fixes or the latest features but without doing any major version upgrades. Next, we exclude a couple of different libraries that we don't want to update. And finally, if the exit code is zero then we say we don't have any changes and we can end the action here. Otherwise, we say that there have been changes and it's something that we need to go and commit and create a pull request for.

The last two steps do the commit, pushing, and the creation of a pull request. There's nothing too special here, but I'll run through it anyway. When we detect a change, we can set up the git config to make sure that we know that the updates have come from a GitHub Action. We add all the files to the git repository to make sure that we capture them in the commit. We provide a default commit message including a Jira issue number if we wish, and finally we push it to the upstream. From there, we can create the pull request, and to do this we simply use curl against the GitHub API using the token from the GitHub secrets to create a pull request. In here, we can set any title or body that we wish and specify the branches, which is dotnet-outdated as our branch that we are creating, and the base could be the mainline branch or it could be the develop branch, whichever you choose.

The three GitHub Actions plus the Dependabot config that I've shown you today are all incredibly powerful tools, and it does depend on the use cases that you have as to which ones may be applicable for your scenarios.

If you enjoyed this video, consider subscribing to the YouTube channel for more content like this.