Closed MichalStrehovsky closed 2 years ago
I know this is not your main point, but it is possible to override the timeout w/ TimeoutInSeconds.
Regarding checking if there's progress, I don't see this realistically being prioritized. However, I'd be open to a PR.
Yes, I ended up adding the timeout parameter by hacking the project file in my nuget cache (the project in question also comes from this repo). I don't know what was the original reason to add a timeout, but on my devbox I can't think of a scenario where I would want to abort a build because it's taking too long. It's a time sink because I'll need to retry.
yea....it would be best to keep going so long as there's anything. Unfortunately, I don't see our team prioritizing this work.
I'm going to close this for now, but if someone feels strongly that there's a better business case for it, or wants to do the work themselves, by all means feel free to reopen.
I've been getting the failures below while trying to build the runtime repo.
After a bit of troubleshooting, I found out the acquire-wix.proj project uses the DownloadFile task from this repo. The download was too slow and DownloadFile task unceremoniously cut it off after 100 seconds (I was getting about 100 kB per second when I tried manually with curl).
I hacked around it locally by increasing the timeout.
Should there be a timeout if the download is making forward progress though? The failure mode was really obscure and I spent quite a bit of time on this.