GitLab has had support for Windows CI/CD Runners for quite a long time, but if you were doing Windows development, you needed to install and manage these Runners yourself. This works great for customers who prefer to manage their own Runners, but for customers who prefer to use GitLab.com shared Runners managed by the GitLab team, the choice has been limited to Linux.
Today, we are happy to announce that Windows Shared Runners hosted by GitLab is available in beta. As we are starting to roll out this important service to our community, we invite you to help shape the direction of CI/CD tooling for the Windows ecosystem on GitLab.com.
What's new?
Now, you can take advantage of a fully-managed, auto-scaling, and secure environment for running your build jobs on Windows virtual machines (VMs). These GitLab-hosted Windows Shared Runners are pre-configured with various software packages such as the Chocolately package manager for Windows, Visual Studio 2019 Build Tools, Microsoft .Net Framework, to name a few. So you have a base set of tooling to start building your Windows applications without needing to set up and install your own self-hosted Windows Runners. You can find a full list of available Windows packages in the package documentation.
With the Windows Shared Runners on GitLab.com, each job runs in a new virtual machine instance that gets deleted after the job is complete, ensuring that your code is 100% isolated and secure. We also take care of maintenance and upgrades to the pre-configured software packages, so you don't have to. Just like with GitLab.com Linux Runners, there’s no requirement to use Shared Runners. If your build tooling configuration or security requirements demand it, you can, as always, install and self-host Windows Runners on your infrastructure.
Technology Overview
The following details a few key specifications for the Windows Shared Runners:
- The Windows Shared Runners use the GitLab custom executor that we introduced in 12.1.
- A new Windows Shared Runners virtual machine is created for each pipeline job and deleted after the job is completed.
Pricing
To begin with, Windows Shared Runner pricing will be the same as Linux Runners. Usage for Windows Runners will be deducted from your Runner minute pool depending on your plan. You can optionally purchase additional runner minutes that will be used for both Linux and Windows shared runners.
In the future, Windows Shared Runners will likely use separate pricing that is higher than Linux Minutes. Any future pricing changes will be announced on the GitLab blog.
Getting started
To get started, create a .gitlab-ci.yml file in your GitLab hosted project's root directory and add the following tags: shared-windows, windows, and windows-1809 as shown in the example configuration file.
.shared_windows_runners:
tags:
- shared-windows
- windows
- windows-1809
stages:
- build
- test
before_script:
- Set-Variable -Name "time" -Value (date -Format "%H:%m")
- echo ${time}
- echo "started by ${GITLAB_USER_NAME}"
build:
extends:
- .shared_windows_runners
stage: build
script:
- echo "running scripts in the build job"
test:
extends:
- .shared_windows_runners
stage: test
script:
- echo "running scripts in the test job"
Including the .gitlab-ci.yml file in the project repository means that any new commits will trigger the execution of your GitLab CI/CD pipeline. In this file, you have the option of specifying tags so that a job will only run on GitLab Runners that match the tag specified. For more information on the use of tags, refer to the tags section of the GitLab CI/CD Pipeline Configuration Reference documentation. The Shared Runners section of the GitLab.com settings documentation page covers more configuration information for the Windows Shared Runners.
Notable limitations and known issues
The hosting of Windows Shared Runners is a new service on GitLab.com. This section covers any limitations or known issues that users of the beta should take into consideration when using this service.
- The average provisioning time for a new Windows VM is at five minutes. This means that for the beta, you will notice slower build start times on the Windows Shared Runners fleet compared to Linux. In a future release, we will add capabilities to the autoscaler to enable the pre-warming of the virtual machine instances. This will significantly reduce the time it takes to provision a VM on the Windows fleet. Additional details and plans are covered in this issue.
- Pending queue times will be longer than the queue times on the Linux Shared Runner fleet.
- Since Windows Shared Runners are currently in beta, the performance, uptime, and capabilities will be limited, and so, they are not recommended for production use.
- The Windows Shared Runners virtual machine instances do not use the GitLab Docker executor. This means that unlike the Linux Shared Runners, you will not be able to specify
imageandservicesin your pipeline configuration. - For the beta release, we have included a set of software packages in the base VM image. If your CI job requires additional software that's not included in this list, then you will need to add installation commands to
before_scriptorscriptto install the required software. Note: Each job runs on a new VM instance, so the installation of additional software packages needs to be repeated for each job in your pipeline. - There is the possibility that we introduce breaking changes that will require updates to pipelines that are using the Windows Shared Runner fleet.
Next steps
We plan to continue to iterate quickly and improve the build environment, Runner, and tooling during the beta period. We invite you to complete this short form because your feedback is critical to helping us prioritize work on the most valuable improvements to the Windows Shared Runners solution.
To report a bug or request a feature or enhancement, follow these steps:
- Open an issue in the GitLab Runner project.
- Describe the feature enhancement and, if possible, include any links to examples from your repository.
- Add these labels to the issue:
Shared Runners::Windows,group::runner - Tag @DarrenEastman on the issue.
Cover photo by William Daigneault on Unsplash
