Repository navigation
CI: cygwin job is timing out at over 6 hours #25708
Description
Activity
This strongly resembles a Cygwin CI timeout on the GitPython repository, described in detail (with some updates in comments) and worked around in gitpython-developers/GitPython#1814. This likewise coincided with the Cygwin python39 package going from version 3.9.16-1 to 3.9.18-1, and pinning that Cygwin package to 3.9.16-1 was sufficient to get things working again.
Is there a way to pin the python version
Cygwin's installer supports specifying package versions, but I was not able to get cygwin/cygwin-install-action to do so. Pinning does work when egor-tensin/setup-cygwin is used. Switching to that action and specifying
python39=3.9.16-1as a package was effective. (I did verify that the action wasn't itself the cause, both by switching the action without pinning as a test, and also by reproducing both the bug and the workaround in Cygwin on a local Windows 10 machine.)I suspect an analogous change may address the problem here, too.
Looking through that issue, it seems turning off progress bars in pip may also solve the stall
For GitPython, turning off progress bars was not sufficient, because another stall occurred while running the tests, in a test that had not been having any problems on Cygwin before.
At least superficially it looks like such a problem happened for NumPy in #25714 as well, though I don't want to assume that, since I see that an alternative explanation (of an actual new bug) has not been ruled out.
Just hypothesizing, but is there maybe any way to change the shell settings which could affect things, so that the tools will print/draw things differently?
(I.e. maybe it draws like an interactive shell, but it could be set to behave more like a non-interactive one?)
The builds https://github.com/numpy/numpy/actions/workflows/cygwin.yml have been timing out for two days. There is a warning about node 20 and the cleanup-path warning, which should be solved by egor-tensin/cleanup-path#2. I don't think that is the problem. Comparing the versions of the packages installed by cygwin between a good and bad run, I see they updated cpython 3.9.16 -> 3.9.18. More likely, but why? Is there a way to pin the python version so we could test that hypothesis? Does anyone see anything else off?