fix(ci): enable git long paths on Windows runners before checkout

.github/workflows/csharp-ci.yaml

@@ -253,6 +253,12 @@ jobs:
         shell: bash
         working-directory: ${{ inputs.working-directory }}
     steps:
+      - name: Enable git long paths on Windows
+        if: runner.os == 'Windows'
+        working-directory: ${{ github.workspace }}
+        # actions/checkout temporarily overrides HOME before making its own global git config changes, so a --global value set here would not be in effect during the checkout
+        run: git config --system core.longpaths true
+
       - name: Checkout
         uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6.0.2
 

.github/workflows/scala-ci.yaml

@@ -208,6 +208,12 @@ jobs:
         shell: bash
         working-directory: ${{ inputs.working-directory }}
     steps:
+      - name: Enable git long paths on Windows
+        if: runner.os == 'Windows'
+        working-directory: ${{ github.workspace }}
+        # actions/checkout temporarily overrides HOME before making its own global git config changes, so a --global value set here would not be in effect during the checkout
+        run: git config --system core.longpaths true
+
       - name: Checkout
         uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6.0.2
 

CHANGELOG.md

@@ -7,6 +7,10 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ## [Unreleased]
 
+### Fixed
+
+- Fix `csharp-ci.yaml` and `scala-ci.yaml` failing their Windows `build-and-test` shards in `actions/checkout` for consumers whose repositories contain long paths. The GitHub-hosted Windows images ship git with `core.longpaths` unset, so a repo path that crosses the 260-character `MAX_PATH` limit once prefixed with the runner's `D:\a\<repo>\<repo>\` workspace root aborts the checkout with `error: unable to create file <path>: Filename too long` — in step 2, before any toolchain setup, and with no lever on the caller's side because the `build-and-test` checkout takes no `with:` block. Both workflows now run `git config --system core.longpaths true` on Windows immediately before that checkout. It has to be `--system`: `actions/checkout` temporarily overrides `HOME` before making its own global git config changes, so a `--global` value written by an earlier step is not in effect during the checkout. The step is pinned to `working-directory: ${{ github.workspace }}` because the job-level `defaults.run.working-directory` points at the caller's `working-directory` input, which does not exist yet before checkout (the same pin, for the same reason, that the `pack` job's `Validate inputs` step already carries). Linux and macOS shards are untouched, and Windows consumers whose paths already fit see no change. Generated-code trees hit this most readily, since path depth follows source namespaces and grows on its own. (#39)
+
 ## [2.4.0] - 2026-07-14
 
 ### Added