[Github] Make Windows container use zstd

[boomanaiden154]

This enables much faster image unpack times. We benchmarked 20-30% improvements when testing this initially. Use skopeo to copy the image as it just works over the docker-archive/OCI container formats and does not need to unpack the image to upload it.

[boomanaiden154]

Output from skopeo inspect docker://ghcr.io/boomanaiden154/ci-windows-2022:latest | jq (the image pushed by this workflow to my fork:

{
  "Name": "ghcr.io/boomanaiden154/ci-windows-2022",
  "Digest": "sha256:36c3c6959b25c25a9496644fdc56a3a9fc6207e2ddae2f59fe0cb1fbf46b416e",
  "RepoTags": [
    "1762661533",
    "latest"
  ],
  "Created": "2025-11-09T04:12:21.4696948Z",
  "DockerVersion": "",
  "Labels": null,
  "Architecture": "amd64",
  "Os": "windows",
  "Layers": [
    "sha256:05ecc0d5d730e6d5a9a5d840fe85e2773d78b2825bdf781ad48ba107261905a4",
    "sha256:5a90d48a2ac708ac5c8a0e1520a7b38bef7116b8740a94609f931ffe3ef27450"
  ],
  "LayersData": [
    {
      "MIMEType": "application/vnd.oci.image.layer.v1.tar+zstd",
      "Digest": "sha256:05ecc0d5d730e6d5a9a5d840fe85e2773d78b2825bdf781ad48ba107261905a4",
      "Size": 113188653,
      "Annotations": null
    },
    {
      "MIMEType": "application/vnd.oci.image.layer.v1.tar+zstd",
      "Digest": "sha256:5a90d48a2ac708ac5c8a0e1520a7b38bef7116b8740a94609f931ffe3ef27450",
      "Size": 62542,
      "Annotations": null
    }
  ],
  "Env": null
}

I'm thinking we can eventually refactor the push-container composite action to use skopeo and then we can use it for both the Linux and Windows jobs. I'll leave that to a future patch though. This should save quite a bit of time because we don't actually need to load/extract the container in the push job, just recompress it.

[llvmbot]

@llvm/pr-subscribers-github-workflow

Author: Aiden Grossman (boomanaiden154)

Changes

This enables much faster image unpack times. We benchmarked 20-30% improvements when testing this initially. Use skopeo to copy the image as it just works over the docker-archive/OCI container formats and does not need to unpack the image to upload it.

---

Full diff: https://github.com/llvm/llvm-project/pull/167022.diff

1 Files Affected:

• (modified) .github/workflows/build-ci-container-windows.yml (+10-6)

diff --git a/.github/workflows/build-ci-container-windows.yml b/.github/workflows/build-ci-container-windows.yml
index b6c46b70030ab..3996948bb44e0 100644
--- a/.github/workflows/build-ci-container-windows.yml
+++ b/.github/workflows/build-ci-container-windows.yml
@@ -56,7 +56,7 @@ jobs:
       - build-ci-container-windows
     permissions:
       packages: write
-    runs-on: windows-2022
+    runs-on: ubuntu-24.04
     env:
       GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
     steps:
@@ -66,8 +66,12 @@ jobs:
           name: container
       - name: Push Container
         run: |
-          docker load -i ${{ needs.build-ci-container-windows.outputs.container-filename }}
-          docker tag ${{ needs.build-ci-container-windows.outputs.container-name-tag }} ${{ needs.build-ci-container-windows.outputs.container-name }}:latest
-          docker login -u ${{ github.actor }} -p $env:GITHUB_TOKEN ghcr.io
-          docker push ${{ needs.build-ci-container-windows.outputs.container-name-tag }}
-          docker push ${{ needs.build-ci-container-windows.outputs.container-name }}:latest
+          sudo apt-get update
+          sudo apt-get install -y skopeo
+          skopeo login -u ${{ github.actor }} -p ${{ secrets.GITHUB_TOKEN }} ghcr.io
+          skopeo copy docker-archive:${{ needs.build-ci-container-windows.outputs.container-filename }} \
+            --dest-compress-format zstd \
+            docker://${{ needs.build-ci-container-windows.outputs.container-name-tag }}
+          skopeo copy docker-archive:${{ needs.build-ci-container-windows.outputs.container-filename }} \
+            --dest-compress-format zstd \
+            docker://${{ needs.build-ci-container-windows.outputs.container-name }}:latest

[vbvictor]

Looks good as long as it works, but I don't have a strong opinion on this change.

One drawback I see is the increasing pool of tools we use. This can bring us more potential bugs that could appear during version bumps. Also, entry barrier is slightly increased with introduction of scopeo.
However, if the decompress speed is favorable over potential complexity/bugs I have nothing against.

[boomanaiden154]

One drawback I see is the increasing pool of tools we use. This can bring us more potential bugs that could appear during version bumps. Also, entry barrier is slightly increased with introduction of scopeo.

The versions here are managed by the stable release distros since we just install from the package manager. skopeo is also pretty simple. If we couldn't use skopeo, I would probably end up writing my own python script to manually repack the images with zstd, but this makes it a lot simpler. The full implementation of that I think would be a couple hundred lines of Python. Instead we get to use a well supported tool that is part of the standard container ecosystem. It would be pretty pretty weird if a version bump of skopeo broke our workflows given what it does is not super complicated.

It's also a much simpler tool than anything else that we're using, especially for this use case. It reads a JSON blob, modifies some objects in a CAS, and then pushes an archive to a server. I don't think the entry barrier tangibly changes.