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.

Custom and self-signed certificates aren't supported​

Custom certificates or self-signed certificates are only supported for linux nodes in a Kubernetes cluster. For Windows, directly mounting the certificate to the destination path will not work.

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 base image for the custom image must include the netapi32.dll file. To include this file 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: