doc/ci/runners/hosted_runners/windows.md
{{< details >}}
{{< /details >}}
Hosted runners on Windows autoscale by launching virtual machines on the Google Cloud Platform. This solution uses an autoscaling driver developed by GitLab for the custom executor. Hosted runners on Windows are in beta.
GitLab keeps iterating to get Windows runners in a stable state and generally available. You can follow the work towards this goal in the related epic.
GitLab offers the following machine type for hosted runners on Windows.
| Runner Tag | vCPUs | Memory | Storage |
|---|---|---|---|
saas-windows-medium-amd64 | 2 | 7.5 GB | 75 GB |
The Windows runner virtual machine instances do not use the GitLab Docker executor. This means that you can't specify
image or services in your pipeline configuration.
The latest Docker version is installed when the image build runs and you can use literal Docker commands in shell runner jobs.
You can execute your job in one of the following Windows versions:
| Version | Status |
|---|---|
| Windows 2022 | GA |
The following files list the available pre-installed software:
The installed .NET Core SDK version and the specific version of Visual Studio Build Tools together determine the pre-installed .NET runtime versions.
The following code runs on a schedule in PowerShell Pipelines on GitLab CI and produces this example list:
For all three runtimes (Microsoft.AspNetCore.App, Microsoft.NETCore.App, Microsoft.WindowsDesktop.App), the available versions are:
.NET Framework is version 4.8.04161.
To discover the current state, run the following code or look at a recent log of PowerShell Pipelines on GitLab CI:
Write-Host "=== Modern .NET (Core 3.1, 5, 6, 7, 8+) runtimes ===" -ForegroundColor Cyan
if (Get-Command dotnet -ErrorAction SilentlyContinue) {
dotnet --list-runtimes
} else {
Write-Host "Not present"
}
Write-Host "`n=== .NET Framework versions ===" -ForegroundColor Cyan
$ndp = "HKLM:\SOFTWARE\Microsoft\NET Framework Setup\NDP"
if (Test-Path $ndp) {
$found = Get-ChildItem $ndp -Recurse |
Get-ItemProperty -Name Version, Release -ErrorAction SilentlyContinue |
Where-Object { $_.Version -and $_.PSChildName -notmatch '^S' } |
Select-Object @{n='Component';e={$_.PSChildName}}, Version, Release |
Sort-Object Version -Unique
if ($found) { $found } else { Write-Host "Not present" }
} else {
Write-Host "Not present"
}
The latest Docker version is installed when the image build runs and you can use literal Docker commands in shell runner jobs.
To discover versions, run the following code or look at pipelines from PowerShell Pipelines on GitLab CI:
write-host "Docker client and service version:"
docker version
Hosted runners on Windows have PowerShell configured as the shell.
The script section of your .gitlab-ci.yml file therefore requires PowerShell commands.
Hosted runners on Windows for GitLab.com run CI/CD jobs as an elevated admin process. This process lets you install additional software or configure the OS before job execution. This permission level is acceptable because the runner creates a new VM for each individual job and discards it after the job completes. This process is essentially the same as how container jobs work for security and disposal.
.gitlab-ci.yml fileUse this example .gitlab-ci.yml file to get started with hosted runners on Windows:
.windows_job:
tags:
- saas-windows-medium-amd64
before_script:
- Set-Variable -Name "time" -Value (date -Format "%H:%m")
- echo ${time}
- echo "started by ${GITLAB_USER_NAME} / @${GITLAB_USER_LOGIN}"
build:
extends:
- .windows_job
stage: build
script:
- echo "running scripts in the build job"
test:
extends:
- .windows_job
stage: test
script:
- echo "running scripts in the test job"