GitHub Actions A Recipe for the Automated
and Time-saving Backup
of your Code Quality

The GitHub Kitchen: many Chefs working together on one Piece of Code

Imagine GitHub as a kitchen in which many different ingredients are mixed to create a dish. The developers sit in front of their respective pots - in the case of the AGOLUTION team this is usually Visual Studio Code  (VS Code) - and create their part of the code of a software product. As soon as the code is completed, it is transferred to GitHub to save the progress first. GitHub acts like a “depository” by storing a status of the code and thus making it possible to return to each previous “step of cooking”. Because GitHub is first and foremost a tool for version control.

This also makes it possible for several “cooks” to work on the same “dish”. In contrast to the proverb, however, it is precisely this parallelism that ensures that a project can be implemented by several developers without them getting into each other’s way. All chefs working on a project create their own personal “cooking pot” by creating their own branch, adding their code and bringing it back into our GitHub kitchen .

For a Tasty Dish: monitoring through Code Reviews and GitHub Actions

Before this code is simply “stirred” into the project, however, it is best to run several checks so as not to spoil the dish.

In the AGOLUTION kitchen there are two control mechanisms. Firstly, all developers are each assigned a “sous-chef” in form of another developer. These assistant chefs carry out code reviews, i.e. they review the program code and add suggestions for changes if necessary. If they notice any errors in the “preparation” of the code, they pass the pot back to the developer.

The second control mechanism is automated: the GitHub Actions. These work like a “scanner” at the door of the GitHub kitchen. As soon as the developers step through this door with their pot - by transferring the freshly developed code to GitHub via pull request - this scanner examines the code. This is where workflows and pipelines come into play. But what do they do actually?

Workflows and Pipelines - Recipe and Ingredients of GitHub Actions

Workflows and pipelines work like “recipe” and “ingredients”. First you need the recipe, the workflow. This is the place where you specify when exactly GitHub should examine the code. For every pull request, so as soon as it is “carried into the kitchen”? With every merge, that is, when the new code is merged with the existing code? Or simply every day at a defined point in time?

In addition, the workflow contains the list of ingredients to be used by GitHub to check the code. Such as the information which pipeline will be used for the check as well as further “preparation options”, e.g. sending a notification if an error occurs during the check.

Here you can see the basic structure of a workflow:

name: Example workflow
// The name of the workflow
on:
// The time/event at which the workflow starts
env:
// Specification for global variables that presets and saves values for multiple jobs
defaults:
// Standard parameters can be specified here, e.g. whether to work with PowerShell
jobs:
// Listing of the different tasks that are to be processed, for example “build” or “notify”
  steps:
  // Each “step” belongs to a “job” and describes a step that must be carried out for the implementation, including calling the pipeline

GitHub is testing the “Code Dish” in a Virtual Environment

GitHub stores projects in repositories. In our AGOLUTION kitchen, this would correspond to a large shelf. Each individual compartment of this shelf represents a repository in which a specific dish is stored.

In addition to the workflow document, which is maintained as a .yml file in the .github\workflows folder in the repository of the product to be tested, there are two other important files. Firstly, the Pipeline-Settings.json, that is relevant for calling the pipeline and transfers the most important settings for the test to it. Secondly, the Pipeline` folder, which contains the files that are to be processed when calling the pipeline - usually several PowerShell scripts.

To understand this construct even better, just imagine that our automated check has its own “recipe book” - the pipeline folder. The GitHub Actions create a virtual environment according to the specifications from the workflow and add the new code to the existing code. They add the ingredient to our dish and check with the recipes whether our “code dish” will also “taste”, i.e. work.

This additional check catches many errors that might otherwise be overlooked and allows developers to react quickly and comprehensively. Furthermore, you can also use GitHub Actions in a predictive way - for example, by regularly checking the current state of programming against a future version.

React promptly: nightly Compatibility Check of Business Central Add-ons and PTE Extensions

Our Business Central add-ons, which can all be found in Microsoft AppSource, are checked every night for compatibility with the next Business Central major release. The same applies to individual customizations, which we deliver to our customers as tested PTE extensions. This enables us to respond promptly to upcoming changes in Business Central - for example, if a field or function will no longer be available with the next version.

You can extend the workflow as you wish. In addition to the check described above, it is also able to execute other actions using a pipeline. On the GitHub marketplace  you will find many actions that you can add.

Integration of Teams Notifications with Actions, Secrets and Webhooks

The following is an example of how a notification to Teams is integrated into a workflow using the action “Notify Teams” from thechetantalwar .

The creation of such a message consists of three parts: an action in the workflow, a secret in the associated GitHub repository and a webhook in Microsoft Teams.

A secret is a kind of “secret drawer” on the repository shelf. For each shelf compartment and for the entire shelf, you can create protected values, which are then retrieved via a variable. The actual stored value is not visible, but is invoked when the code is executed. This allows you to store passwords, for example, so that developers who do not know the password can still contribute to the code.

A webhook is the connection option to Microsoft Teams. This creates a value in Teams that establishes communication between GitHub and Teams, provided the webhook is stored in GitHub.

Back to our example notification. The action “notify” is a job and is therefore set at the same level as the “build”, which “builds” the pipeline. It has its own steps that are executed.

notify:
    runs-on: ubuntu-latest
    // The virtual operating system required to run this job
    if: failure()
    // Execution of the job only if an error occurred in the previous job
    needs: build
    // Only when the “build” job has finished can “notify” be executed
    steps:
      - name: Notify ms teams
        // The name can be selected freely
        uses: thechetantalwar/teams-notify@v2
        // Reference to the action from the Marketplace that is to be used
        with:
        // The following parameters are required for execution
          teams_webhook_url: ${{secrets.TeamsWebhook}}
          // A secret stored in the repository that contains the Teams webhook, i.e. the counterpart to which the message is to be sent
          message: "Run of the workflow ‘${{github.workflow}}’ by ${{github.actor}} for ${{github.server_url}}/${{env.repositoryName}}/actions/runs/${{github.run_id}} failed due to an error."
          // Message to be displayed

The location where a webhook for Teams is created can be found in the channel that is to receive the notification under Connectors:

Then you need to add and configure an Incoming Webhook:

The webhook created here is then stored as a secret in the desired repository. It is also possible to maintain it as a central secret if you want to collect messages from all workflows in all repositories in a specific channel.

And this is what the output in Microsoft Teams looks like:

You can design the message to be displayed in a relatively free manner. In our example, we have opted for a very simple design, as we are primarily concerned with the informational value of this message as well as its quick development.

Teams Message: learn about new Customizations directly - even without Access to GitHub

Such a Teams notification also enables colleagues without access to GitHub to receive feedback that an adjustment to the next version is pending. This allows them to discuss with developers in a timely manner how to deal with the “announced error”. And long before there is an urgent need for action. Only such a small notification already means a time buffer, freedom to act and consequently saved money.

GitHub Actions: developing Secure, High-quality and High-performance Code - and saving Time in the Process

Overall, GitHub Actions are a great asset for the development of stable software products. They save time for those involved and enhance the code backup by developers with automated tests and actions such as notification via Microsoft Teams. They enable developers to focus on ensuring that the code produced is high quality, efficient and up-to-date.

And they offer much more: with GitHub Actions, you can use different virtual operating systems for your code checks at the same time. You can also test the code against upcoming versions and build your own actions , which are exactly tailored to your needs.

The GitHub Actions can handle the most diverse programming languages, such as Node.js, Python, Java, Ruby, PHP, Go, Rust, .NET etc. The GitHub Action Marketplace  offers a large number of helpful actions. There you will find a suitable action for almost every challenge.

In our AGOLUTION kitchen, the GitHub Actions are therefore not just another unnecessary kitchen gadget that collects dust somewhere in the very back corner because it is only used three times a year. They are - similar to a Thermomix - an integral extension and upgrade and simplify and optimize the daily “code cooking”. In the end, they make a major contribution to “tasty dishes” and consequently safer software products.