Skip to content

Latest commit

 

History

History
75 lines (56 loc) · 6.64 KB

SelfHostedGitHubRunner.md

File metadata and controls

75 lines (56 loc) · 6.64 KB
Raw

#13 Set up your own GitHub runner to increase build performance

Prerequisites: An AL-Go repository setup using one of the scenarios

When running the CI/CD workflow, the build job is by far the most time-consuming job. By adding your own GitHub Runner, which can cache the generic image, the build image and also the artifacts, the time for running the build job can become much faster.

GitHub runners can be registered for an organization (accessible for all repositories in the organization) or for a single repository.

  1. Navigate to https://github.com/organizations/{organization}/settings/actions/runners/new to create a self-hosted runner for your organization. Use https://github.com/{organization}/{repository}/settings/actions/runners to create a self-hosted runner for a single repository. Organization new runner
  2. Now, you can either Use the Azure VM Template to create your self-hosted runner or you can Create your self-hosted runner manually

Use the Azure VM Template to create your self-hosted runner

  1. To create an Azure VM hosting x self-hosted runners, open a new tab and navigate to https://aka.ms/getbuildagent.
  2. Enter the Resource Group name, Region, VM Name, Admin Password of your choice.
  3. Enter the number of agents you want to create on the VM.
  4. Grab the token, the organization Url, and the Agent Url from the Create Self-Hosted runner page, and specify self-hosted in labels. getbuildagent
  5. Select Review and Create and then review the deployment and choose Create.
  6. Wait for the Azure VM creation to finalize, navigate back to see that the Runners have been registered and are ready to use. Runners
  7. Go to Allow your repository access to your runners to continue the configuration.

Create your self-hosted runner manually

  1. To create a self-hosted runner manually, choose Windows under Runner Image and x64 in architecture and follow the description on how to create a self-hosted runner manually
  2. Make sure that the following software is installed on the computer (the suggestion in parentheses explains the mechanism used in https://aka.ms/getbuildagent)
    • Docker (getbuildagent use this script to install or update Docker Engine on the Azure VM)
    • The AZ PowerShell module (getbuildagent use Install-Module az -force)
    • GIT (getbuildagent use choco install git --force --params "/NoAutoCrlf" after installing choco using https://chocolatey.org/install.ps1))
    • 7zip (getbuildagent use choco install 7zip)
    • GitHub CLI (getbuildagent use choco install gh)
    • PowerShell 7.4.1 (getbuildagent use choco install pwsh -y)
    • Microsoft Visual C++ Redistributable for Visual Studio 2015-2022 14.36.32532 (getbuildagent use choco install vcredist140 -y)
    • Microsoft .NET (getbuildagent use choco install dotnet -y)
    • Microsoft .NET SDK (getbuildagent use choco install dotnet-sdk -y)
    • nuget.org added as dotnet nuget source (getbuildagent use dotnet nuget add source https://api.nuget.org/v3/index.json --name nuget.org)

Note

If the Deploy Reference Documentation job results in an error like this, then you need to check your GIT installation as described in the issue.

Allow your repository access to your runners

  1. On the list of Runners on GitHub, choose the runner group Default and allow public repositories if your repository is public. public
  2. Now navigate to your repo settings file (.github/AL-Go-Settings.json) and set gitHubRunner to self-hosted.
    • Note that you can use other tags than self-hosted to identify special runners for GitHub jobs, or you can set gitHubRunner to "self-hosted, Windows" to ensure that a Windows version is selected if you have self-hosted linux runners as well.
  3. Save and inspect your workflows performance increase on the second run.
  4. Inspect that one of the runners pick up the workflow. Active
  5. Clicking the runner reveals that the job it is running. Job

GitHubRunner vs. runs-on

You might have noticed that there are two settings in the repository settings file controlling which runners are selected, GitHubRunner and Runs-On.

"runs-on" is used for all jobs that don’t build/test your app, such as jobs that don’t require a lot of machine power or a docker container. AL-Go for GitHub supports using ubuntu-latest for runs-on, which is faster and cheaper than windows-latest (which is the default). Many jobs run in parallel using these runners, and we do not recommend using self-hosted runners for this type of job.

"githubRunner" is used for build/test jobs, which require more memory and a container.

Additional info on build performance

  1. Running 6 CI/CD workflows simultanously, causes 1 workflow to wait as I only had 5 runners. Wait
  2. Connecting to the runner VM and looking at utilization indicates that the VM is pretty busy and probably over-allocated when starting 5+ builds at the same time. Every build was ~50% slower than when running only 1 build. CPU
  3. Decreasing the number of runners to 4 causes the build performance to be similar to when running just 1 build.
  4. Turning off real-time protection on the self-hosted runner makes builds go ~25% faster. Better utilization

back