Skip to main content

Run Windows builds in a Kubernetes build infrastructure

You can run Windows builds in your Kubernetes build infrastructure. Windows Server 2019 and 2022 images are available for running CI builds and for out-of-the-box CI steps such as Run, Save Cache, and Restore Cache.

Prerequisites​

These conditions apply when running Windows builds on Harness CI Kubernetes cluster build infrastructure.

Windows Server 2022 or 2019 is required​

Windows Server 2019 and 2022 images are supported.

  • Amazon EKS: The AMI type must be Windows Server Core.

  • GCP: Only Windows Server 2019 is supported.

  • GKS: Use the recommended image type for Windows Server 2019 or 2022.

Some built-in steps aren't supported​

The following steps aren't supported on Windows platforms on Kubernetes cluster build infrastructures: Build and Push an image to Docker Registry, Build and Push to ECR, Build and Push to GAR, and Build and Push to GCR. Try using the buildah plugin instead.

Docker commands aren't supported​

If your build process needs to run Docker commands, Docker-in-Docker (DinD) with privileged mode is necessary when using a Kubernetes cluster build infrastructure; however, Windows doesn't support privileged mode. If you need to run Docker commands, you must use another build infrastructure, such as Harness Cloud or a VM build infrastructure, where you can run Docker commands directly on the host.

Configure cluster and build infrastructure​

  1. Set up your cluster with both Linux and Windows node pools. Linux is required for running the Delegate.
  2. Install the Delegate on the Linux node pool by specifying the Linux node pool selector. For example, on GKE the Linux node pool label is kubernetes.io/os: linux and the Windows node pool label is kubernetes.io/os: windows. The selectors are automatically set up on the nodes.
  3. In your pipeline's Build stage, go to the Infrastructure tab and configure the following settings:
    1. Select Windows for the OS.
    2. Expand the Advanced section, and add a Node Selector to use the Windows node pool. Enter kubernetes.io/os as the Key and windows as the Value.

  1. Save and run your pipeline.
info

If you use a custom Windows image in a Run step, the container must be based on Windows Server Core version 1809 and must include netapi32.dll. To include this in your image, add the following command to the Dockerfile:

COPY --from=core /windows/system32/netapi32.dll /windows/system32/netapi32.dll

Pipeline YAML example​

This example pipeline runs on a Windows platform on a Kubernetes cluster build infrastructure. Note the presence of os and nodeSelector in stage.spec.infrastructure.spec.

pipeline:  
  name: WindowsK8  
  identifier: WindowsK8  
  projectIdentifier: myproject  
  orgIdentifier: default  
  tags: {}  
  properties:  
    ci:  
      codebase:  
        connectorRef: $GITHUB_CONNECTOR  
        repoName: testing-flask-with-pytest  
        build: <+input>  
  stages:  
    - stage:  
        name: Build and Test  
        identifier: Build_and_Test  
        type: CI  
        spec:  
          cloneCodebase: true  
          infrastructure:  
            type: KubernetesDirect  
            spec:  
              connectorRef: $K8S_CONNECTOR  
              namespace: harness-delegate-ng  
              automountServiceAccountToken: true  
              nodeSelector:  
                kubernetes.io/os: windows  
              os: Windows  
          execution:  
            steps:  
              - step:  
                  type: Run  
                  name: helloWorld  
                  identifier: Pre  
                  spec:  
                    connectorRef: $DOCKERHUB_CONNECTOR  
                    image: winamd64/python  
                    shell: Powershell  
                    command: "Write-Host \"hello world\" "

Default user for Windows builds​

Harness CI builds use a Lite-Engine and, for Kubernetes cluster build infrastructures, an Addon image. The Lite-Engine drives the stage workspace, and the Addon image drives additional build-related tasks required for Kubernetes cluster build infrastructures.

The default user for the Windows Lite-Engine and Addon image is ContainerAdministrator. ContainerAdministrator is assigned elevated privileges similar to the root user on Linux, allowing for system-level configurations and installations within the Windows container.

Don't change the default user for these images. The default user must be ContainerAdministrator because specific path and tool installations require it, and Windows doesn't allow setting the path otherwise.

For individual steps that run in containers, Harness uses user 1000 by default. You can use a step's Run as User setting to use a different user for a specific step.

Troubleshoot Windows builds on Kubernetes cluster build infrastructure​

Go to the CI Knowledge Base for questions and issues related to Windows builds on Kubernetes cluster build infrastructure, including: