Tutorials on Continuous Integration (ci)

In this article, we will learn how to set up automated release creation for an ASP.Net Core project with GitHub ActionsRelease management can be a complicated beast at the best of times, and is notoriously hard to get right. Previously, shell scripts and batch files used to be the most common tools used for automation, and countless hours were spent trying to get them working as expected. This has changed in recent times, with platforms such as GitHub Actions providing a much simpler way of automating tasks and managing releases. In the last article , we have seen how GitHub Actions can be used to set up a pipeline for Continuous Integration (CI). In the following sections, we will build on that, and add a workflow that publishes release artifacts when new code is merged to the main branch. For the purposes of this tutorial, we will use a simple .NET Core console application. This can be created via the following command using the .NET CLI which is installed along with the SDK. We will use the GitHub repository that we created in the previous article, which already contains a GitHub Actions CI workflow that builds and runs unit tests on pushes to main and pull request branches. A tag is a label that can be applied to any commit in your repository for later identification. Tags are typically used to mark commits for releases. You can create a tag using the following commands in your terminal/command line. Tag names can be any arbitrary string, but are usually version numbers like v1.0.0 or v.1.1.2-beta5. When a tag has been published, it will appear in the 'Tags' section in your repository. You can then use the created tag to create a GitHub release - each release has a title, short description and attachments such as release notes, source code and built artifacts. In the next step, we will learn how to build our project and associate the built app code artifacts with the just-created release. Let us now create a release.yml file in the .github/workflows directory alongside the ci.yml workflow we have defined previously. We will use the release published event to trigger our workflow. This means our workflow will get triggered when a new release is published using the mechanism from the previous step. Let us now understand what this workflow does: We can now create a release using the steps described earlier. Let us first tag the last commit in our repo. I'll call the tag v1.0 . The tag will now appear in the 'Tags' section, and we can create a release from it. The release notes can be automatically populated based on the commits since the last tag. Once we hit publish, a release gets created on the 'Releases' page. Note that this only has the source code, and not the built artifacts from the tagged commit. Publishing the release also triggers our new workflow. When the workflow has finished, the built ZIP file and tarball are added to the release assets, and we have successfully released v1.0 of our app! 🎉 In this tutorial, we have learnt how to create and automate tasks around releases for an ASP.Net Core project using GitHub Actions. We built on concepts we learnt in the previous tutorial on CI with GitHub Actions . If you find yourself stuck at any point during the tutorial, you can view all the source code on my GitHub here . More detail on all the events that can be used to trigger GitHub Actions workflows can be found in the GitHub docs .

In this article, we will learn how to set up a simple build workflow for an ASP.Net Core project with GitHub Actions.Modern apps often have large codebases with multiple teams of developers working across different geographical locations and time zones. In this scenario, it is of utmost importance to ensure that each change to the codebase works correctly not just in isolation, but in the context of all the existing code. This keeps quality levels high and guarantees the best possible experience for the app's users. Continuous Integration (CI) can be used to automatically run an array of checks on the codebase that could be triggered before code changes are merged, thus ensuring the quality of all released code. GitHub Actions is a powerful continuous integration (CI) and continuous delivery (CD) platform available for all code repositories hosted on GitHub. It allows you to build, test, and deploy your code on multiple platforms, right from your source code repository. GitHub Actions are triggered via GitHub workflows, which are YAML (either  *.yml  or  *.yaml ) files within the .github/workflows/ directory in your repository. A workflow references one or more GitHub Actions, run in a specified sequence to accomplish a given task. In the following sections, we will learn more about how GitHub Actions and workflows function, and understand how they can be used to automatically build, test, and release an ASP.Net Core project. For the purposes of this tutorial, let us use a simple .NET Core console application. We can create one using the .NET CLI which is installed along with the SDK. You can create a repository on GitHub and push the code created by the above command using the instructions in the GitHub docs . A .gitignore file can be added to ignore the build output and an optional readme file for documentation. At this stage, your GitHub repo should look somewhat like this: Now that we have our app code on GitHub, we can start creating our automated workflows. We can begin by defining a Continuous Integration(CI) workflow that will run each time code is committed to a PR branch or to main . Let us define a simple CI workflow with three steps that will install our project's NuGet dependencies, build it and run any tests, all using the dotnet CLI. We want this workflow to run on each commit to a PR branch or to main , and run on two platforms - Linux and Windows, to make sure our app works perfectly on both. As can be seen from the diagram above, each step in the workflow depends on the step before it, and can only run if the previous step is completed successfully. Now, we can create a .github/workflows directory and create a ci.yml file in there that defines this as a GitHub workflow. The YAML syntax is quite simple and readable and is easy to understand. Please refer to the comments inline in the below code block for more context. Let us now look at the structure of the workflow in detail: We've used the actions/checkout and actions/setup-dotnet predefined actions in our workflow. These, along with a wide variety of other actions are available in the GitHub Marketplace . If one isn't available for your specific purpose, you can create your own using either JavaScript or a Docker container. One of the great things about GitHub Actions is that the workflows are defined right alongside your source code. This means you can create, test, and refine new workflows on a branch before applying them to your main branch. Let us create a branch called add-ci-workflow , commit the workflow file that we have defined above in .github/workflows/ci.yml , and open a pull request to trigger the workflow. GitHub immediately recognizes the new workflow and starts the process of running the jobs defined in it. You should see status updates for each of the jobs appearing at the bottom of the pull request. You can then click through to view the details of each workflow run, where you can read through the console output from the various commands running on the build machine. This can also be accessed from the 'Actions' tab on your repository page. Once all checks have been completed, the branch can be merged into main . This will trigger a run of our workflow jobs against the newly merged code in main . A very important part of your CI setup is the idea of ensuring that only good code makes it to the main branch. To this end, GitHub allows you to set up rules that require certain GitHub Actions workflows have successfully completed before a branch can be merged. This can be used in conjunction with code reviews to keep quality levels high. The rule in the screenshot below specifies that pull requests are required for merges to main , and they can only be merged when our CI checks have succeeded. You can add a status badge for any GitHub Actions workflow in your repository to your readme file, which shows visitors and potential users of your repo the status of your CI/CD pipelines. This can be added using the URL scheme below and added as a markdown image URL in your readme: There are more parameters you can add to the URL, that are documented here . In this article, we have learned how to set up a continuous integration workflow for an ASP.NET Core app using GitHub Actions. We have also discovered how to leverage GitHub's branch protection rules with workflows to ensure only high-quality code makes it to the main branch. Most of the concepts we have explored around creating and running workflows are generic in nature, so you can apply them to any project with a different technology stack with the appropriate modifications. In an upcoming article, we will take things a step further and learn how to create releases and publish artifacts for ASP.Net Core projects with GitHub Actions workflows. All the example code used in this article is available on GitHub .