15 ms·
As the other comment says: cache it yourself. Not only will you save time downloading it, avoid sudden version changes, your build environment should really not
by ohgodplsno 5y ago
As the other comment says: cache it yourself. Not only will you save time downloading it, avoid sudden version changes, your build environment should really not depend on pulling things out of your control every single time
- iso1631 5y agoThe modern argument would be that you're more likely to have problems with your own cache than someone else, and you should just use caching as a service.
- ohgodplsno 5y agoThe modern argument is most likely made by people who sell caching as a service and have an interest in you blowing $500/month on a glorified FTP or a script to setup Artifactory.
- Symbiote 5y agoBut this is Microsoft's cache, so it is already essentially on the same network, and is free.
- pdpi 5y agoIt's a lot easier to remove yourself from the critical path if your cache has problems than it is to add the caching after the fact when a third party is having problems, though.
- hnlmorg 5y agoExactly this! You plan for failure. What happens if your cache fails? You fall back to Microsoft. But what happens if Microsoft fails and you don't have a cache? Well you build a cache in advance and default to that. Caches can also improve build time, allow for security tools to scan, and other such benefits too. So there are other benefits outside of creating a redundancy.
- coredog64 5y agoWe do local caching, and it’s caused more outages, downtime, headaches and lost productivity than I can count. Although the hardware requirement is minimal, all that other stuff makes it expensive. So run a risk calculation for your own use case.
- merb 5y agowell we cached the final docker images ;-) unfortunatly if you need to add another dependency for our build image were done. (well we could pull the old one and add the dependency and repush this image) also there are cache misses :-(