Tomorrow (Sun Sep 13th) I will do some maintenance of the Windows CI runners which might require several reboots. Windows CI tests will be unreliable on Sunday. Please restart them in case they fail.
I need some help with this. The files which are left over appear to be junctions, but to TTF font files. As far as I know on Windows one can do only junctions to folders, but one can do symlinks to files. A Windows DIR command shows this:
Directory of C:\ci\cygwin64_21081_16603\usr\share\fonts\test
02/07/2020 13:52 <DIR> .
02/07/2020 13:52 <DIR> ..
01/07/2020 11:47 <JUNCTION> ahronbd.ttf [...]
01/07/2020 11:47 <JUNCTION> andlso.ttf [...]
01/07/2020 11:47 <JUNCTION> angsa.ttf [...]
01/07/2020 11:47 <JUNCTION> angsab.ttf [...]
01/07/2020 11:47 <JUNCTION> angsai.ttf [...]
01/07/2020 11:47 <JUNCTION> angsau.ttf [...]
01/07/2020 11:47 <JUNCTION> angsaub.ttf [...]
Even with 2 hours of googling I couldn't find any way to delete these files (some people said one has to install Linux, mount the file system and delete the files). Since handling symbolic links (usually) requires admin rights, I checked the policies that I have it - was OK. I am a bit llost here - will ask on the cygwin list.
If someone has seen this and has a solution, please let me know.
P.S.: I rebooted a few times and made sure that nobody has a lock on these files (using e.g. SysInternals ProcExplorer).
P.P.S.: Who has the admin password? I only have the password for user CI. @Maxime Dénès ?
@Michael Soegtrop Sorry, I'm slowly catching up with messages after being a bit sick for a few days. It seems I don't have the admin password for these slaves, but I'm checking the documentation.
I don't see any mention of an admin password, unfortunately. Maybe we could talk next week (when @SkySkimmer comes back from vacations). I'd need to understand the current roadmap for Windows CI to see how we can help.
It is not that urgent. The files are all of size 0 byte, but it are up to I think 2000 on each runner meanwhile. So it will not cause any trouble soon, but it is ugly.
I am also thinking about filing a support request with Microsoft. I privately do have a support contract with Microsoft which includes a few support incidents per year which I hardly ever use.
I would hope anyway to get rid of this infrastructure in the medium term and to start relying on GitHub Actions for Windows packaging instead. And I was thinking the Coq platform would be a good test case for this. @Jason Gross has some experience with GitHub Actions for Windows testing. A recurring issue is that Cygwin cannot reliably be downloaded from the GitHub Actions runners. But with @Michael Soegtrop we have been talking anyway of setting up a cache with Cygwin and all the packages that are needed. So to my eyes, this would be the first step.
What's the current status of the test-suite? Where do we run it on Windows?
@Théo Zimmermann
A recurring issue is that Cygwin cannot reliably be downloaded from the GitHub Actions runners.
I think this might depend on the mirror used. The issue with the CI runners was that they didn't accept the HTTPS signature of some mirrors (my Windows 10 did). As far as I can tell the latest choice or mirror (kernel.org) doesn't have this issue.
I would prefer to have latest Cygwin on master but a fixed Cygwin on releases branches. On the other hand it is quite rare that a Cygwin update breaks our CI - I remember only 2 incidents since Coq 8.7. So it is definitely not critical to test this on master. Still I wouldn't like to test it only once every 6 months - then it is hard to find out what has been changed, and I guess if we say we update our local repo once per week this is not that likely to really happen.
Maxime Dénès said:
What's the current status of the test-suite? Where do we run it on Windows?
As far as I know the Azure runners do this. The CI based on my script doesn't.
@Michael Soegtrop Instead of always testing the latest version in every PR (and have random breakage that can happen anywhere), my proposition is to set up automation to automatically generate a fresh cygwin cache which can be updated, say, every week.
@Théo Zimmermann : sure, this is an option. It is simply a trade off between the manual work of setting this up and the machine work to do redundant or unwanted tests. Since the latter also leads to manual work, it is probably a good idea to invest more time into a better CI. We all know the issue - trading a day of work now against several days a few month later does not always look as attractive as it is from today's perspective.
I'd be willing to spend a day or two setting this up (in the next few weeks) as I think it will become important for the platform. Of course, I will need your input, as I am not myself a Windows expert.
Last updated: Sep 25 2023 at 14:01 UTC