Hacker News Reader

Comment by nurettin | Hacker News Reader

This is probably apple's continuous integration tests, lazily written to download the whole thing every time someone merges a commit.

View on HN

that's really stupid. I mean, I would have set a cache repository (SonaType Nexus maybe?), download everything there and use that repository. In the tweets the author says they've blocked the download from Apple IPs, so now their pipeline is broken.

I bet that 95% of all in-house CI would break if it doesn't have access to the internet. I also bet that 95% of those wouldn't need to have access if they were properly designed.

We rarely hear about CI servers being taken over but it has to happen frequently enough.

Most enterprises use Artifactory or something similar -- or should anyway. Once you start enforcing "no internet for CI" you start to see how poor some ecosystems are. I'm looking at you, Javascript ecosystem packages, with your hardcoded mystery URLs that you sneakily download artefacts from...

We had a situation at work where some developers really got attached to downloading npm modules at container start time to make builds fast. But then starting the containers took 15 minutes :P

Surely lots of orgs would eschew packages with such sneaky behavior? Turning off the network would be a good way to test for that...

You're absolutely right. It's the reason we always use devpi for python mirrors, and firewall off CI.

Ultimately you need to be able to rebuild the product when upstream goes poof.

Fairly sure that was the vector for the big matrix.org breach.

Unfortunately it's very common for companies to set up their CI without any form of caching. I think it's mostly because developers are under time pressure from their managers. In some cases it's because CI is set up by juniors who don't fully understand the tools and the consequences of setting them up at this scale.

It's also not a problem until it is. Then, you can devote resources at it, but meanwhile you got things up and running for months/years faster than if you tried to get everything setup just so from the get go...

So they can fix it, now, that is is a problem, and they didn't have to spend time worrying about that before.

Sounds very smart on their party: move forward with what matters (building your codebase, tests, etc) and don't do something (like an internal cache), unless you have to -- the ops equivalent of lazy-loading...

I was asked to scrape some prediction website millions of times every day. Instead of doing that, I reverse engineered their prediction curves from a few hundred data points and served the models myself. Not sure which one is more ethical. Scraping at scale or stealing the models using mathematics. But I know second one is cooler.

Every medium-sized org I’ve worked at has put a caching layer in front of their build dependencies, so builds aren’t blocked when GitHub/PyPI are unavailable. No build/release engineer would leave that trivial door open if they were responsible for the build

Sounds like the build pipeline was set up by a regular dev.

It's smart but pretty fucking rude tbh.

It's not that smart because they might throttle the bandwidth as a result. Also, one day the downloading may take longer than the time between tests and the entire test will start failing. Further, if you want to test the testing procedure, you want a cache anyway.

The data should probably be distributed using e.g. git, so that downloads are incremental by default.

Reply on news.ycombinator.com