We will be summarising an established GitHub Action built in .NET that could be applied to manage a code metrics html file in this article. Then a demonstration on how to use .NET to develop your custom GitHub Actions. I’ll teach you ways to create meta – data that identifies a GitHub repository as an activity. Lastly, I’ll tie everything up with a super awesome illustration: upgrading an action on the .NET demos repository to incorporate data model support with GitHub’s newly designed Mermaid diagram feature, so it builds upgraded class diagrams with every edit. 

Using .NET to create a custom GitHub Action

Various types of developing apps are supported by actions:

Because .NET can operate in Microservices, you’ll need to containerize your project if you want a fully functional .NET app to operate as a GitHub Action. See .NET Docs: Containerize a .NET App for more information on .NET with Docker.

Rather than containerizing a .NET project, you could construct a .NET worldwide utility that can be downloaded and invoked using the run terminology rather than the uses. This method is valuable for constructing a .NET CLI software which can be exploited as an universal solution, but it’s outside the subject of this article. See .NET Docs: Global Tools for more information on .NET global tools. 

The goal of the instructional

A guide on building a GitHub Action with .NET may be found on the .NET Docs. It explains methods to containerize a .NET application, as well as how to compose the action.yml file that contains the action’s information and receive it from a pipeline. Instead of duplicating the whole guide, I’ll outline the act’s purpose and then discuss how it was modified. 

The tutorial application analyses code metrics by doing the following:

• In a source repository, screening and identifying *.csproj and *.vbproj project files.
• Examining the identified source code in these projects for the following:

Complexity of cyclomatic structure

Index of maintainability

Inheritance levels

coupling by class

Number of source code lines

Lines of executable code estimated

• Making a CODE METRICS.md file (or modifying one).

When the CODE METRICS.md document updates, a pull proposal is generated dynamically (and immediately) as an element of the receiving pipeline architecture. To put it another way, when you publish modifications to your Repo, the cycle executes and utilises the .NET code metrics action to update the markdown form of the coding measures. The CODE METRICS.md file is accessible, with automated connections and parts that may be collapsed. Images are used to emphasize code metrics at a peek; for example, when a module has a high cyclomatic complexity, an emoji comes to the surface to the design stage, leading the markup. You can then go deeper into the class and look at the performance measures for each technique. 

Microsoft.CodeAnalysis is a library that analyses code. The Code Analysis Metric Data class in the Code Metrics library provides the Cyclomatic Complexity attribute. This characteristic is a gauge of the code’s morphology. It’s made by calculating the amount of various code routes in the project’s cycle. A system with a complex control flow will require more testing to obtain high code quality and will be more difficult to sustain. When the program is inspected and the CODE METRICS.md file is updated, the GitHub Action adds an emoji to the header using the following syntax: 

internal static string ToCyclomaticComplexityEmoji(
this CodeAnalysisMetricData metric) =>
    metric.CyclomaticComplexity switch
    {
>= 0 and <= 7 => “:heavy_check_mark:”,  //
8 or 9 => “:warning:”,                  //
10 or 11 => “:radioactive:”,            //
        >= 12 and <= 14 => “:x:”,               //
        _ => “:exploding_head:”//
    };

This action’s code is available in the .NET freebies repo, as well as in the .NET documentation code samples web interface. The action is auto as an example of usage (or dogfooding). The operation continues as the code changes, and it keeps track of CODE METRICS.md in a CODE METRICS.md file via periodic pull submissions. Take a look at the screencaps below, which demonstrate some of the most important portions of the html folder:

Heading CODE METRICS.md

Project File Reference pipe heading CODE METRICS.md

The coding statistics html file offers the succeeding structure to describe the code it analyses:

Project ➡️ Namespace ➡️ Named Type ➡️ Members table

When you dig deeper into a specified class, there is a hyperlink to the auto-generated diagram at the bottom of the table. This is covered in the chapter on adding features. See .NET samples to navigate the example file on your own. CODE METRICS.md. 

Metadata for actions

A GitHub repository must define metadata in an action.yml file in order to be identified as a GitHub Action.

# Name, description, and branding. All of which are used for
# displaying the action in the GitHub Action marketplace.
name: ‘.NET code metric analyzer’
description: ‘A GitHub action that maintains a CODE_METRICS.md file,
reporting cyclomatic complexity, maintainability index, etc.’
branding:
icon: sliders
colour: purple
# Specify inputs, some are required and some are not.
inputs:
owner:
description: ‘The owner of the repo. Assign from github.repository_owner. Example: “dotnet”.’
required: true
name:
description: ‘The repository name. Example: “samples”.’
required: true
branch:
description: ‘The branch name. Assign from github.ref. Example: “refs/heads/main”.’
required: true
dir:
description: ‘The root directory to work from. Example: “path/to/code”.’
required: true
workspace:
description: ‘The workspace directory.’
required: false
default: ‘/github/workspace’
# The action outputs the following values.
outputs:
summary-title:
description: ‘The title of the code metrics action.’
summary-details:
description: ‘A detailed summary of all the projects that were flagged.’
updated-metrics:
description: ‘A boolean value, indicating whether or not the CODE_METRICS.md
was updated as a result of running this action.’
# The action runs using docker and accepts the following arguments.
runs:
using: ‘docker’
image: ‘Dockerfile’
args:
– ‘-o’
– ${{ inputs.owner }}
– ‘-n’
– ${{ inputs.name }}
– ‘-b’
– ${{ inputs.branch }}
– ‘-d’
– ${{ inputs.dir }}
– ‘-w’
– ${{ inputs.workspace }}

The .NET sampling code statistics action’s metadata is nested within a subdirectory, therefore it isn’t recognised as an action that may be presented in the GitHub Action marketplace. It can, however, still be used as an action.

See GitHub Docs: Metadata syntax for GitHub Actions for additional information about metadata.

Workflow efficiency

A workflow file must exist in the.github/workflows directory from the root of the GitHub repository to consume the .NET code metrics action. Take a look at the following workflow file:

name: ‘.NET code metrics’
on:
push:
branches: [ main ] paths-ignore:
# Ignore CODE_METRICS.md and README.md files
– ‘**.md’
jobs:
build:
runs-on: ubuntu-latest
permissions:
contents: write
pull-requests: write
steps:
– uses: actions/checkout@v2
# Analyse repositories source metrics:
# Create (or update) CODE_METRICS.md file.
– name: .NET code metrics
id: dotnet-code-metrics
uses: dotnet/samples/github-actions/DotNet.GitHubAction@main
with:
owner: ${{ github.repository_owner }}
name: ${{ github.repository }}
branch: ${{ github.ref }}
dir: ${{ ‘./github-actions/DotNet.GitHubAction’ }}
# Create a pull request if there are changes.
– name: Create pull request
uses: peter-evans/create-pull-request@v3.4.1
if: ${{ steps.dotnet-code-metrics.outputs.updated-metrics }} == ‘true’
with:
title: ‘${{ steps.dotnet-code-metrics.outputs.summary-title }}’
body: ‘${{ steps.dotnet-code-metrics.outputs.summary-details }}’
commit-message: ‘.NET code metrics, automated pull request.’

To create, this workflow uses jobs.job id>.permissions, setting contents, and pull-requests. This is necessary for the process of updating the repo’s data and creating a request form based on those modifications. Watch GitHub Docs: Workflow syntax for GitHub Actions – permissions for more information on permits.

The following sequence diagram can be used to illustrate how this procedure works:

• When a programmer uploads code to the GitHub repository.
• The workflow is started after it has been triggered.
• The code written is saved in the $GITHUB WORKSPACE directory.
• The action .NET code metrics are used.
• The CODE METRICS.md file is updated once the source code is analysed.
• The create-pull-request action is triggered if the .NET code metrics step (dotnet-code-metrics) outputs that metrics were changed.
• The file CODE METRICS.md has been added to the repository.
• A pull request is created automatically. See .NET examples / pull requests for an example of pull requests made by the app/github-actions bot.

Incorporating more features

GitHub has introduced Mermaid-powered Latex diagram capability. Our customised method has a conceptual grasp of the types it’s evaluating because it can analyse C# as part of its execution. In the CODE METRICS.md file, this is used to generate Mermaid class diagrams programmatically.

Metrics for .NET code Mermaid support has been added to the GitHub Action example code.

static void AppendMermaidClassDiagrams(
MarkdownDocument document,
List<(string Id, string Class, string MermaidCode)> diagrams)
{
document.AppendHeader(“Mermaid class diagrams”, 2);
foreach (var (id, className, code) in diagrams)
{
document.AppendParagraph($”
{id}”>
“);
document.AppendHeader($”`{className}` class diagram”, 5);
document.AppendCode(“mermaid”, code);
}

The ToMermaidClassDiagram extension function can be used to inspect the code that generates the diagrams parameter. See the following diagram for an example of how this looks in the CODE METRICS.mdMarkdown file:

Synopsis

You learnt about the many sorts of GitHub Actions in this blog, with a focus on Containers and .NET. I described how the GitHub Action for .NET code statistics was upgraded to incorporate Mermaid data model functionality. You also viewed a sample action.yml document, which acts as GitHub Action information. The ingesting pipeline was then shown, as well as how the code metrics action is ingested. I also showed you how to extend the code metrics action with new features.

What are you going to develop, and how will it benefit others? Create and share your own .NET GitHub Actions, and I encourage you to do so.