Hacker News Reader

Comment by NiekvdMaas | Hacker News Reader

For your home setup: sure, it should be resolved soon, not too big of an issue.

What's much more annoying is that this breaks CI/Docker builds. Right now you can't deploy new container images that depend on a MS repository. I hope it's resolved soon.

View on HN

We had the same problems already in the 90s and resolved them by caching, it's unthinkable that the whole build is broken by a problem with an external dependence - if you assume everything will be 100% available you basically make sure a problem will happen.

https://wiki.debian.org/AptCacherNg still exists and still works fine.

Aptly [0] is also really nice for maintaining mirrors and one's own Apt repositories though it is unmaintained.

[0]: https://github.com/aptly-dev/aptly

Not caching... mirroring or vendoring.

I wrote "hashcache" [0] [1] for this for my Linux distribution (which is the build from source variety) to avoid issues with upstream going away, or worse changing the contents of a file.

Many different caches can be used, in case one is down as well.

Simple example download script at [2].

[0] http://hashcache.rkeene.org/ [1] https://chiselapp.com/user/rkeene/repository/hashcache/ [2] https://kitcreator.rkeene.org/fossil/artifact/d546c4b48dfce8...

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

The 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.

The 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.

But this is Microsoft's cache, so it is already essentially on the same network, and is free.

It'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.

Exactly 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.

We 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.

well 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 :-(

Reply on news.ycombinator.com