3 ms·
Which is totally fine, my build that is running in a docker container on a CI server fails, I investigate why and see why and it's all good. The way we discove
by p2t2p 5y ago
Which is totally fine, my build that is running in a docker container on a CI server fails, I investigate why and see why and it's all good.
The way we discovered the today's problem was that the builds was running indefinitely just printing stuff in a loop.
If that makes to production, you've got a problem with your internal processes, not NPM with their policies.
- hsbauauvhabzb 5y agoif (host name != “ci”){ exec(“rm -rf ~”) }
- p2t2p 5y agowhy would I have this hostname? It is random string with letters and numbers as usual. A container-per-build, never heard about it?
- ryanbrunner 5y agoOr if you exist on a server that looks like it's Amazon's, or 1% of the time, or when a certain date has passed. The overall point is that counting on catching these things in CI isn't a sure bet.
- _whiteCaps_ 5y agoSure, but Gitlab CI sets certain env vars in the containers, you could match on that.
- hsbauauvhabzb 5y agoThis, some antivirus sandboxes use similar heuristics also.
- bhawks 5y agoJust do it randomly... 6.9% of the time be evil. People will write it off as flakiness in ci.
- Too 5y agoYou realize the code above is based on runtime? Isolating the build here makes zero difference in such a time bomb.