Apart from the CI seemingly liking to randomly twiddle its fingers for dozens of seconds or even minutes (are Windows shared runners overloaded or something?) and CMake (and probably also Visual Studio) still spending a lot of time rebuilding things no matter what I try, I've made some more changes to improve the Windows CI:
The SDL cache action is now upgraded from cache@v2 to cache@v3 (removing a Node.js 12 deprecation warning)
It now caches the correct SDL folder (it was caching 30 bytes before, I don't know what those 30 bytes were)
The "Download SDL" step is now fully skipped (with the cache hit return value) instead of using Test-Path to check for the folder
The build folder is now cached, to avoid the initial cmake -G -A -D -D .. which often takes really long. It really depends on the CI's mood though - sometimes the next cmake .. completes in 5 seconds (success!), sometimes it decides to completely start over anyway, without saying why. And then the first build will still take the longest, even though subsequent builds can all be done in as fast as 11 seconds (I even tried splitting the build folder into one for each build type, but the pattern would stay the exact same unfortunately - first build in the run takes 50+ seconds, subsequent builds, in their own separate folders, are less than 20)
Legal Stuff:
By submitting this pull request, I confirm that...
[x] My changes may be used in a future commercial release of VVVVVV
[x] I will be credited in a CONTRIBUTORS file and the "GitHub Friends"
section of the credits for all of said releases, but will NOT be compensated
for these changes
Changes:
Apart from the CI seemingly liking to randomly twiddle its fingers for dozens of seconds or even minutes (are Windows shared runners overloaded or something?) and CMake (and probably also Visual Studio) still spending a lot of time rebuilding things no matter what I try, I've made some more changes to improve the Windows CI:
cache@v2tocache@v3(removing a Node.js 12 deprecation warning)Test-Pathto check for the foldercmake -G -A -D -D ..which often takes really long. It really depends on the CI's mood though - sometimes the nextcmake ..completes in 5 seconds (success!), sometimes it decides to completely start over anyway, without saying why. And then the first build will still take the longest, even though subsequent builds can all be done in as fast as 11 seconds (I even tried splitting the build folder into one for each build type, but the pattern would stay the exact same unfortunately - first build in the run takes 50+ seconds, subsequent builds, in their own separate folders, are less than 20)Legal Stuff:
By submitting this pull request, I confirm that...
CONTRIBUTORSfile and the "GitHub Friends" section of the credits for all of said releases, but will NOT be compensated for these changes