CircleCI jobs can now run on Windows, letting you build and test Windows-native applications without the overhead of VMs or Docker.
Let’s see it in action. Imagine you’re building a .NET application. Your config.yml might look like this:
version: 2.1
jobs:
build-and-test:
executor:
name: windows-machine
os: windows
version: 2022 # Or 2019
steps:
- checkout
- run:
name: Install .NET SDK
command: |
Invoke-WebRequest -Uri "https://download.visualstudio.microsoft.com/download/pr/3311811e-a619-4275-9112-4d6936c479e3/d7f8f7d8010b112b8f7a07c25d61866a76b88a25/dotnet-sdk-6.0.400-win-x64.exe" -OutFile dotnet-sdk-installer.exe
Start-Process -FilePath .\dotnet-sdk-installer.exe -ArgumentList "/quiet /norestart" -Wait
Remove-Item .\dotnet-sdk-installer.exe
- run:
name: Restore Dependencies
command: dotnet restore
- run:
name: Build Project
command: dotnet build --configuration Release
- run:
name: Run Tests
command: dotnet test --configuration Release --logger trx
deploy:
executor:
name: windows-machine
os: windows
version: 2022
steps:
- checkout
- run:
name: Deploy to Azure
command: |
# Example deployment script
echo "Deploying to Azure..."
# Add your Azure deployment commands here (e.g., Azure CLI, PowerShell scripts)
This configuration defines two jobs: build-and-test and deploy. Both use the windows-machine executor, specifying windows as the operating system and 2022 for the Windows Server version.
The build-and-test job checks out your code, installs the .NET SDK, restores dependencies, builds the project, and runs tests. Notice the Invoke-WebRequest and Start-Process commands – these are standard PowerShell cmdlets for downloading and executing installers.
The deploy job also uses the Windows executor and includes a placeholder for your deployment commands. This demonstrates how you can chain Windows-specific tasks together.
The problem this solves is the need to test and build applications that are inherently tied to the Windows environment – think .NET Framework applications, COM components, or GUI testing. Previously, you’d have to maintain your own Windows build agents, manage their patching and scaling, or resort to less-than-ideal workarounds. The windows-machine executor abstracts all of that away, providing a managed Windows environment directly within CircleCI.
Internally, CircleCI provisions a dedicated Windows virtual machine for each job that utilizes the windows-machine executor. This VM is pre-configured with common development tools and libraries. You can customize this environment further by installing additional software or dependencies within your job’s steps. The os and version parameters allow you to select between Windows Server 2019 and 2022.
The windows-machine executor is a powerful abstraction, but it’s important to understand that it’s running on a full Windows Server instance. This means you have access to the full Windows API and command-line tools (like cmd.exe and PowerShell). When you specify command: | ..., CircleCI executes these commands within a PowerShell shell on the Windows VM. For commands that might require different shells or executables, you can often invoke them directly (e.g., .\my_program.exe).
When you’re working with the Windows executor, remember that file paths are typically case-insensitive but it’s good practice to match the case of your source code. Also, be mindful of environment variables; they behave as they do on a standard Windows machine, so you might use %TEMP% or $env:TEMP depending on the shell context.
The next step after successfully running your Windows jobs is to explore how to manage secrets and credentials for Windows-based deployments.