libgnatdoc and liblal_refactor 24.0.0

[Fabien-Chouteau]

No description provided.

[Fabien-Chouteau]

Ping @reznikmm

[Fabien-Chouteau]

Errors on Windows seem to be unrelated to the crates. We have to work on improving stability here.

stderr: Failed Outcome because of exception: 
stderr: file "C:\Users\runneradmin\AppData\Local\alire\settings\indexes\community\repo\.git\objects\pack\pack-d4da5daa0c2ac681f11001baa49d7e93695d5a08.idx" could not be deleted
stderr: raised ADA.IO_EXCEPTIONS.USE_ERROR : file "C:\Users\runneradmin\AppData\Local\alire\settings\indexes\community\repo\.git\objects\pack\pack-d4da5daa0c2ac681f11001baa49d7e93695d5a08.idx" could not be deleted

stderr: ADA.IO_EXCEPTIONS.USE_ERROR
stderr: copy of "C:\Users\runneradmin\AppData\Local\alire\cache\releases\libgpr2_24.0.0_eda3c693\testsuite\tests\load-preinstalled\fake-ada-x86_64-wrs-vxworks7\x86_64-wrs-vxworks7\rtp\share\gpr\preinstalled.g
stderr: raised ADA.IO_EXCEPTIONS.USE_ERROR : copy of "C:\Users\runneradmin\AppData\Local\alire\cache\releases\libgpr2_24.0.0_eda3c693\testsuite\tests\load-preinstalled\fake-ada-x86_64-wrs-vxworks7\x86_64-wrs-vxworks7\rtp\share\gpr\preinstalled.g

[mosteo]

The fact that both the old and new implementations for syncing, which are quite different, fail on gpr2, makes me suspect that there is indeed some specific trouble on Windows not just in the CI setup.

I'll check ASAP, but this week I'm on a work trip so time is scarce.

[mosteo]

It turns out it was too long paths.

[Fabien-Chouteau]

It turns out it was too long paths.

Is there a way for us to configure this in the runners?

[mosteo]

What I did is relocating the cache to /tmp using alr settings before the test (in the alire-index-checks repo). Is that what you mean?

I'm also thinking that the long hashes for the build dirs could be truncated (with clash detection); I doubt the whole hash is ever needed.

[Fabien-Chouteau]

There are options to enable long-path support:

• On Windows. Which seems to be enabled for GH runners: Windows long paths support actions/runner-images#4913
• And git. Not enabled by default on GH runners: [Windows] Set core.longpaths option actions/runner-images#4915 (comment)

Not sure if the the git option is useful.

I'm also thinking that the long hashes for the build dirs could be truncated (with clash detection); I doubt the whole hash is ever needed.

Users will encounter this problem on their machine, so we should find a robust solution.

Also I spotted this: https://stackoverflow.com/questions/21194530/what-does-mean-when-prepended-to-a-file-path
Not sure if it's applicable to us.

[mosteo]

Not sure if the the git option is useful.

It says in the 2nd issue you linked to that it causes issues with, among others, msys. I might at least try it to see what happens.

Also I spotted this: https://stackoverflow.com/questions/21194530/what-does-mean-when-prepended-to-a-file-path
Not sure if it's applicable to us.

In this particular case, the error happened when trying to sync from the download folder to the build folder (which is 64 chars longer approx), so it might well apply. It wouldn't make us safe from the error happening during checkout by git itself, unless we can safely enable longpaths in git.

I'll create an issue to track this information.