<https://developer.ibm.com/blogs/case-study-increm...
# random
CC @busy-vase-39202
🔥 2
❤️ 3
b
Thread! https://twitter.com/pantsbuild/status/1562860861445660672?s=20&amp;t=AqOyDwkuQhHjrRAHytwyLA Thank you @bitter-ability-32190 @high-yak-85899 and @happy-kitchen-89482 for the combined impactfulness of your writeups. ❤️
h
nice! can we cross-post to Pants blog by chance? Or write a one-paragraph Pants blog that links to this?
b
There's a typo
Lines of metadata: 20,000 2,4000
has an extra 0 at the end 😛 Oh and I'm on twitter now: https://twitter.com/thejcannon
b
Thankfully the comma disambiguated the typo. Since twitter doesn't have an edit button, it'd be a pain to recreate the thread, images, and ALT text so I'm gonna leave it.
b
ah RIP. But that makes sense tho as well
a
Very cool! I'm curious - what was the biggest part of the 6-8 minutes of savings?
And what was the difference between the two systems that meant docker images were easier to make more custom per target?
b
Admittedly the prior art didn't cache the virtualenv needed to run formatters/linters between runs. That was a big chunk. And running those tools took time and weren't themselves cached. So we could've had some savings while sticking to Bazel, but I also wanted the big savings internally and externally as a "win".
Bazel doesn't use docker to build images. It uses a library that allows it to make images itself, and registers them with docker. It makes custom workflows really annoying, so devs piled everything in a base image. There was also issues with caching that made a monolithic base image desirable
(a part of all this is our engineers are data scientists, so very much a "path of least resistance" nature)
😊 1
Lastly, over specified dependencies hurts the cache granularity and we have some looooooong tests