CI: cygwin job is timing out at over 6 hours

[mattip]

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?

[seberg]

Ping @DWesl, since it's the Cygwin CI.

[EliahKagan]

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-1 as 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.

[mattip]

Looking through that issue, it seems turning off progress bars in pip may also solve the stall

[EliahKagan]

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.

[seberg]

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?)