Fix sourceforge-caused regression: failed Windows dependency download leads to incomplete exe execution and a 6h CI timeout - #1417

okay, this works like a charm, windows completed in 1 minute

Do you remember that you removed caching of the installed FPC when you switched the Windows build from 32 to 64 bits?

yes, iirc that was the consensus back then that the caches are causing more problems than they are solving. wasn't there some CI build issues where something went wrong with the caches, ... i'd have to go back and check the discussions from back then.

update: only found your comment and my reply that i simply removed the caching and everyone seemed fine with it...

but if your suggestion is to reenable caching for this, i can take a look at that tomorrow. i would still add these failsafes because even with a cache they could occur and then leave the cache in a corrupt state

The only discussion I could find in that old PR about the caching is #1149 (comment)

It would be great if you could make caching work again. We added it because Github sometimes exceeds the rate limit of Sourceforge.

I don't think Github updates the cache when the build fails so aborting downloads would not be a problem.

it would still let it run into the 6h timeout on the failing build, which is then not cached. I think that's worth preventing either way.

also switching to the official download link seems like the right thing to do.

i found a minute now, i'll check it out

totally makes sense why i removed it. the old key was not taking the architecture version into account, so while i was fighting with the CI to get 64-bit to compile (which it locally did) it always used some other (I think 32-bit fpc! which obviously would not compile me 64-bit binaries) files from the cache on the CI system. that's why the builds always failed while they were working locally and why this caused a lot of headache back then. my headache back then was getting the CI to somehow do the same thing that worked locally :D ---> that's why my conclusion was that the caches cause more problems than they were solving as i was unsure how often such mismatches would happen. does that make sense now?

i also checked github's documentation which says:

When key doesn't match an existing cache, it's called a cache miss, and a new cache is automatically created if the job completes successfully.

so we can indeed rely on that assumption

(still need a second to verify whether it works and indeed pulls stuff from the cache --- update: argh, i tried to check by updating 1409 to see whether it gets the cache but obviously that does not work, i needed a dummy change on this one - sorry!)

looks good to me

thanks for the feedback!

Still, the cache restore took almost 20% longer than the original download/install, so it is not faster actually - do we still want it?