Introduction: A fun use case<\/h2>\n
The example application for this article is a profanity filter. Over half a decade ago, I developed a GitHub profanity filter<\/a> as an Azure function to handle GitHub webhooks. The original implementation was written in C# using .NET Core 2.2, which was later upgraded to .NET Core 3.1. At that time, GitHub Actions were just being introduced, so the project didn’t utilize them. However, it has been known for some time that you can author .NET apps as GitHub Actions, and official documentation is available to help you get started:<\/p>\n In this article, I will demonstrate how the original project has evolved into a containerized GitHub Action using .NET 8 and Native AOT.<\/p>\n The new profanity filter (named Potty Mouth<\/em>)<\/a> is a .NET app that runs as a GitHub Action. This means that this filter can be used in any repository. The app is a great way to demonstrate the power of .NET and GitHub Actions. The app itself is a .NET console app that’s published as a container image.<\/p>\n The app maintains several lists of profane content in various languages. It uses these lists to search for matching profane content in GitHub issues and pull requests as they’re updated. The app is configurable exposing a set of inputs<\/a>, so you can choose how to handle profane content. For example, you can replace profane content with a series of asterisks or emoji or some other desired strategy.<\/p>\n To help visualize the flow of the profanity filter, consider the following diagram:<\/p>\n <\/p>\n The preceding flow chart diagram depicts the following steps:<\/p>\n Job summaries are useful for auditing purposes as they provide a detailed account of the profane content that was replaced. This is especially useful for repositories that have strict content guidelines. Later in this post, I’ll share an example job summary.<\/p>\n GitHub Actions are deployed as containerized apps, and they need to run quickly and efficiently. This is especially true for Actions that are run on every pull request, such as build validation.<\/p>\n To publish your .NET app as a container image, use the .NET CLI For more information, see the Containerize a .NET app with Writing .NET apps that are used as GitHub Actions isn’t something that’s new, I covered this is previous posts:<\/p>\n While it’s not new, we’ve come a long way since then and I have some applied learnings that I’m excited to share!<\/p>\n To make your Action run more quickly, it’s best to build and publish your container image separately from the consuming workflow. One common pitfall is to define your action.yml<\/em> to run using the Dockerfile<\/em> as the This causes your Action to build the container image on every run, which is slow and inefficient. For example, each workflow run needs to pull down the Dockerfile<\/em> to build the image before running it. Instead, you should build your container image once (or as needed) and publish it to a container registry such as Docker Hub or the GitHub Container Registry. This avoids the cost of building the container image on every run.<\/p>\n Ideally, your action.yml<\/em> file should point to a container image that’s already built and published. For example, if you’re using GitHub Container Registry, you can use the following syntax:<\/p>\n For more information on the action.yml<\/em> syntax, see the Metadata syntax for GitHub Actions<\/a> documentation.<\/p>\n I’ve consistently observed .NET container image build times taking on average 1-2 minutes, and this is a significant amount of time for a GitHub Action to run. By building and publishing your container image separately from the consuming workflow, you can avoid this cost.<\/p>\n The GitHub Container Registry is a great place to publish your container images. It’s integrated with GitHub, so you can use your GitHub username and the GitHub Action’s Potty Mouth eats its own dog food. In other words, the GitHub repo that contains the source code for the Action also has a workflow that consumes the published version itself. You can see the Potty Mouth container image<\/a> in the GitHub Container Registry, and view the GitHub Action in the public marketplace<\/a>. Consider the following release workflow that publishes the app to the GitHub Container Registry:<\/p>\n The preceding workflow is used to publish the Potty Mouth container image to the GitHub Container Registry. The workflow is triggered when a new release is published. The workflow uses the The Why am I using Native AOT? Previously, when I was basing my image on For more information on the available .NET images, see the .NET container images<\/a> documentation.<\/p>\n Our friends at GitHub maintain the official \n
The evolution of the profanity filter<\/h2>\n
![\"Profanity](\"https:\/\/devblogs.microsoft.com\/dotnet\/wp-content\/uploads\/sites\/10\/2024\/02\/flow-chart.png\")
<\/p>\n\n
\n
emoji<\/code> is configured.<\/li>\nswear<\/code> is considered profane<\/em>, “some swear words” becomes “some \ud83d\udca9 words”.<\/li>\nAuthoring .NET GitHub Actions<\/h2>\n
publish<\/code> command. The .NET CLI has built-in support for building and publishing container images without the use of a Dockerfile<\/em>, and it’s as simple as running the following command:<\/p>\ndotnet publish \/t:PublishContainer<\/code><\/pre>\ndotnet publish<\/code><\/a> documentation.<\/p>\n\n
Optimize consuming GitHub Action workflows<\/h3>\n
image<\/code>, rather than the container image. In other words, if you see something like the following in your action.yml<\/em> file\u2014there’s likely an opportunity for improvement:<\/p>\nruns: # \ud83d\ude48\n using: \"docker\"\n image: \"Dockerfile\"<\/code><\/pre>\nruns: # \ud83e\udd13\n using: \"docker\"\n image: \"docker:\/\/ghcr.io\/username\/your-dotnet-action:latest\"<\/code><\/pre>\nPublishing to the GitHub Container Registry<\/h3>\n
${{ secret.GITHUB_TOKEN }}<\/code> to authenticate. This is especially useful for GitHub Actions, as it’s very convenient to not have to worry about managing any additional repository secrets or variables, such as credentials for Docker Hub.<\/p>\nname: Release\n\non:\n release:\n types: [published]\n\nenv:\n IMAGE_NAME: ievangelist\/profanity-filter\n BASE_IMAGE: mcr.microsoft.com\/dotnet\/nightly\/runtime-deps:8.0-jammy-chiseled-aot\n\njobs:\n deploy:\n runs-on: ubuntu-latest\n permissions:\n contents: read\n packages: write\n\n steps:\n - name: Check out the repo\n uses: actions\/checkout@main\n\n - name: Get the version\n run: echo \"RELEASE_VERSION=${GITHUB_REF\/refs\\\/tags\\\/\/}\" >> $GITHUB_ENV\n\n - uses: actions\/setup-dotnet@main\n\n - name: Login to GitHub Container Registry\n uses: docker\/login-action@v3\n with:\n registry: ghcr.io\n username: ${{ github.actor }}\n password: ${{ secrets.GITHUB_TOKEN }}\n\n - name: Publish app\n working-directory: .\/src\/ProfanityFilter.Action\n run: |\n dotnet publish \\\n \/t:PublishContainer \\\n -p DebugType=none \\\n -p ContainerBaseImage=${{ env.BASE_IMAGE }} \\\n -p ContainerRegistry=ghcr.io \\\n -p ContainerImageTags='\"latest;${{ env.RELEASE_VERSION }}\"' \\\n -p ContainerRepository=${{ env.IMAGE_NAME }} \\\n -bl\n\n - uses: actions\/upload-artifact@main\n if: always()\n with:\n name: msbuild.binlog\n path: src\/ProfanityFilter.Action\/msbuild.binlog<\/code><\/pre>\ndotnet publish<\/code> command to build and publish the container image. The dotnet publish<\/code> command is configured to use the ghcr.io<\/code> registry, and specifies latest<\/code> and dynamic version tags. The latest<\/code> tag is used to represent the latest release, and the dynamic version tag is used for the specific release version. The dotnet publish<\/code> command also generates a msbuild.binlog<\/code> file, which is uploaded as an artifact. This is useful for debugging purposes, as it contains detailed build information.<\/p>\nBASE_IMAGE<\/code> is what the resulting container image is based on. In this case, it’s the .NET 8 nightly runtime-deps image. This specific base image is the mcr.microsoft.com\/dotnet\/nightly\/runtime-deps:8.0-jammy-chiseled-aot<\/code> variant and it’s optimized for Native AOT.<\/p>\nmcr.microsoft.com\/dotnet\/nightly\/runtime:8.0<\/code>, the resulting image was over 200 MB. Using the Native AOT base image results in a container image that’s only 38 MB. This is a significant reduction in size, as the container image is a meager 19% of the size of the original! The image also starts up much faster, which is especially useful for GitHub Actions.<\/p>\nImproving the GitHub Action developer experience for .NET<\/h3>\n
@actions\/toolkit<\/code>, which enables GitHub Action authors who target JavaScript and TypeScript to have a great developer experience. Their toolkit provides a set of APIs that make interfacing with GitHub Actions feel seamless. I set out to enable .NET app developers to have a similar experience, while providing dependency injection and other common patterns and idioms found in modern .NET app development. I’ve been using my GitHub Actions Workflow .NET SDK<\/a> with much success despite not having full feature parity. Some of the features that I’ve implemented correspond to the existing toolkit packages, such as:<\/p>\n
![\"Apply](\".\/example-fast-run.png\")
<\/p>\n![\"Example](\".\/example-issue.png\")
<\/p>\n![\"Example](\".\/example-job-summary.png\")
<\/p>\n