From the course: Deploying ASP.NET Core Applications: From Fundamentals to Advanced Deployment Strategies

Setting up CI with GitHub Actions - ASP.NET Core Tutorial

From the course: Deploying ASP.NET Core Applications: From Fundamentals to Advanced Deployment Strategies

Start my 1-month free trial Buy for my team

Setting up CI with GitHub Actions

“

- [Instructor] In this part, you'll learn how to set up continuous integration with GitHub Actions. CI, or continuous integration, ensures that the code integrated into a central repository works as expected, so in other words, continuous integration is used to basically check if the code that is deployed built successfully, and if there are any tests, it also checks if the tests are passing. Now I'm going to use GitHub, but, of course, you can use other tools like Azure DevOps, Bitbucket, et cetera, so let's go to GitHub and see it in action. In GitHub, I have already created a repository, and it's my username, and then this is the repository name, and you can see it's a private repository, and this repository has just a single branch named master. Now, to create an action, you just need to go to the Actions tab in here, and since we want to set up continuous integration, you just need to scroll down, skip the Deployment section, and go to Continuous integration, and here you have different options, and you have even more if you just go to View all. You can see all the different continuous integrations that you can use to set up in this project or different projects. Now, since mine is a .NET project, I'm going to choose this workflow option in here, which is .NET. It's built by GitHub Actions, and it's used to build and test .NET or ASP.NET Core projects, so I'll just click Configure, and you can see that this body fold does create a .NET YAML, and this file is inside the workflows folder, github folder, and then inside the project. Now, let us have a look at this file, and then we are going to test this file to see if everything works as expected. The name keyword that you see in here is used to set the name of the workflow to .NET, and if you want, can just change this to say .NET Build and Test, and in here, we can see two events, so this workflow is triggered on push event to the master branch, so whenever some code gets pushed to the master branch, then this file's going to be executed, or whenever you merge a pull request into the master branch. Then the job that needs to run, so whenever the events are triggered, there is a job that needs to run. This job has been named build, and it's going to run on the latest version of Ubuntu, and then, down here, we have all the steps. The first step is that it defines that this is going to use the version 4 of the checkout action. Then we have a name. The name is Setup .NET, and this is basically to just going to use the actions/setup-dotnet@v4, and the .NET version that this action is going to use is the version 8.0.x, so this is just basically for the minor versions. The next step is that it's going to restore the dependencies, and it's going to restore the dependencies using the .NET restore command. After this step, we are going to build the app, and the app gets built with the dotnet build and the flag --no-restore, and if the project has any test, then the last step is going to be to run the test in the project using the dotnet test command. Now, we also have these other flags, which are --no-build. - -verbosity is set to normal. To trigger this action, let us just scroll up in here and commit changes, and then this is just going to be Create dotnet.yml. Commit directly to master, and since we have this workflow in here, what this means is that once we commit the changes, a build is going to be triggered. To see the builds, just go to Action. You can see that it's in progress, and it was successful. Now, since we didn't have any tests, you will see in here just the build part, but if you would have unit tests as well, then in here you would see the build and then test. Now, let us go back to Actions, and I'll just go to Visual Studio. In here, inside the master branch, I'll just open the app and go to any file 'cause I just want to test, like, another build, just space, save, trigger build action, Commit. Then Push to master. That's Pull then Push, and that's because we did create the action file, but we didn't pull the call here. Okay, the code is pushed. Now let's go to GitHub, and on here, you can see that we have another workflow running, and this is the second one, and this one was successful as well. Now, on the next part, you're going to learn how we can set up continuous deployment so each time we push some code to this branch, the project is built, and if successful, the code is deployed to an Azure web app.

Contents