I just wanted to mention that in Coq platform CI we had several Cygwin update related issues recently. On 32 bit Windows tar is broken and fails sometimes since Jan 10 or so (rarely but reproducibly for a given tar file). On 64 bit Windows there is a non reproducible issue with the assembler since Jan 30 or so. I looked at Coq's CI and didn't see these issues. In case you see issues, the latest fixes for Coq platform are in
As far as I know only the python fix is in Coq's CI.
In general if you see Windows issues, it might be worthwhile to look out for PRs or changes to the above file(s). I don't look at Coq's Windows CI results regularly any more.
FTR, we don't test Windows 32bit anymore on the Coq side.
And there were indeed a few random Windows failures recently although most jobs went through just fine.
Here are the links to these failures. It seems that there are of three types.
remote: error: cannot lock ref 'refs/remotes/fb9e53fc5266f3285fd2364f0292dd62': reference already exists
Second type: ends with many lines like
Extracting from file://C:\ci\cache\cgwin/https%3a%2f%2fmirrors.kernel.org%2fsourceware%2fcygwin%2f/noarch/release/mingw64-x86_64-icu/mingw64-x86_64-icu-57.1-2.tar.xz
cp: error writing 'bin/coqidetop.exe': No space left on device
I will have a look at the runners. There is a cron job deleting left over debris once a day, so the disk full errors are odd - unless there where massive network failures on one day which left a lot of debris. I will report todays status of machines. We could change the cron jobs to run say every few hours.
I did a maintenance run on the servers. As it looks the cleanup cron job seems to do its job, bit for whatever reason on 2 servers a few folders did get access denied on the removal. Not sure why. Running the same script as the cron job does from the console did work. I guess I need to review the user rights of the cron job.
Last updated: Oct 21 2021 at 20:02 UTC