Weird behaviour with Windows wheels repair

Description

When I try to run the following git workflow: https://gist.github.com/gnikolov95/fa1f95d39bed741ebc559bbd3b01ec56 It fails when it tries to repair the wheel, raises a stop iteration error.

This is the relevant part from .toml:

# Use delvewheel on windows
[tool.cibuildwheel.windows]
before-build = [
    "pip install delvewheel",
    "if exist build rmdir /s /q build",
]
repair-wheel-command = ["delvewheel repair -w {dest_dir} {wheel}", "pipx run abi3audit --strict --report {wheel}"
]

[tool.cibuildwheel.linux]
before-build = "rm -rf {project}/build"
repair-wheel-command = [
  "auditwheel repair -w {dest_dir} {wheel}",
  #"pipx run abi3audit --strict --report {wheel}",
]

[tool.cibuildwheel.macos]
before-build = "rm -rf {project}/build"
repair-wheel-command = [
  "delocate-wheel --require-archs {delocate_archs} -w {dest_dir} -v {wheel}",
  #"pipx run abi3audit --strict --report {wheel}",
]

Everything is pretty much created from the examples on the documentation page. I thought that maybe I am somehow messing up the dest_dir and wheel dirs but it works for macOS and Linux.

The exception stack

2023-08-08T16:39:24.4888381Z repairing C:\Users\runneradmin\AppData\Local\Temp\cibw-run-7_2kent2\cp311-win_amd64\built_wheel\<redacted>-0.0.1-cp311-cp311-win_amd64.whl
2023-08-08T16:39:24.4889297Z finding DLL dependencies
2023-08-08T16:39:24.4889904Z no external dependencies are needed
2023-08-08T16:39:24.8214620Z Traceback (most recent call last):
2023-08-08T16:39:24.8223942Z   File "<frozen runpy>", line 198, in _run_module_as_main
2023-08-08T16:39:24.8224862Z   File "<frozen runpy>", line 88, in _run_code
2023-08-08T16:39:24.8225478Z   File "C:\Program Files (x86)\pipx\.cache\637068be72fe8b2\Scripts\cibuildwheel.exe\__main__.py", line 7, in <module>
2023-08-08T16:39:24.8226119Z   File "C:\Program Files (x86)\pipx\.cache\637068be72fe8b2\Lib\site-packages\cibuildwheel\__main__.py", line 144, in main
2023-08-08T16:39:24.8317162Z     build_in_directory(args)
2023-08-08T16:39:24.8319397Z   File "C:\Program Files (x86)\pipx\.cache\637068be72fe8b2\Lib\site-packages\cibuildwheel\__main__.py", line 328, in build_in_directory
2023-08-08T16:39:24.8321382Z     platform_module.build(options, tmp_path)
2023-08-08T16:39:24.8322962Z   File "C:\Program Files (x86)\pipx\.cache\637068be72fe8b2\Lib\site-packages\cibuildwheel\windows.py", line 489, in build
2023-08-08T16:39:24.8323624Z     repaired_wheel = next(repaired_wheel_dir.glob("*.whl"))
2023-08-08T16:39:24.8324096Z                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
2023-08-08T16:39:24.8324521Z StopIteration
2023-08-08T16:39:24.8686958Z creating virtual environment...
2023-08-08T16:39:24.8687632Z creating virtual environment...
2023-08-08T16:39:24.8688590Z determining package name from 'D:\\a\\_actions\\pypa\\cibuildwheel\\v2.14.1'...
2023-08-08T16:39:24.8689256Z installing cibuildwheel from spec 'D:\\a\\_actions\\pypa\\cibuildwheel\\v2.14.1'...
2023-08-08T16:39:25.8558899Z ##[error]Process completed with exit code 1.
2023-08-08T16:39:25.8756824Z Post job cleanup.
2023-08-08T16:39:25.8990623Z Post job cleanup.
2023-08-08T16:39:26.1079522Z [command]"C:\Program Files\Git\bin\git.exe" version
2023-08-08T16:39:26.1344189Z git version 2.41.0.windows.3

If the glob is empty the call on next should be guarded by StopIteration except I guess. However, that glob should not be empty when we initially call next, which makes me wonder why the glob is empty if the wheel build succeeded, so not sure whether I made a mistake somewhere or it is a issue.

Apologies, but cannot provide links for the time being as the project is still not open sourced as of yet.

Build log

No response

CI config

No response

pypa / cibuildwheel