Flaky red build detector
The diagram above illustrates my preferred algorithm for detecting intermittent test failures in a CI system.
If you are building logic like this, you should first ask why are the tests flaky in the first place?
Here are 8 articles where different authors explore various approaches to flaky tests:
- No more flaky tests on the Go team
- What are the roots of ‘clowning’ or ‘clowny behavior’ or ‘clowntown’ at Facebook?
- How to solve intermittent issues
- Your test suite is trying to tell you something
- Testing Problems Are Test Results
- Buildbot and Intermittent Tests
- Did you ‘try’ it before you committed?
- Eradicating Non-Determinism in Tests
In the tech world we worry a lot about scaling. Whenever someone comes up with software innovation, one of the first questions they are likely to hear is: nice concept, but will it scale?
But what is it that does not scale?
In growing systems, technology and process may not scale. In the life…
Nice! Some guys are trying to fund this badass phenomenon of physics so we can all enjoy it. :D
"FLUX is based on a complex, thus rarely known law of physics, a phenomenon called Lenz’s law, which can defy our most commonly experienced physical law, gravity itself. It’s actually nothing new. Heinrich Lenz discovered it in the 1830s, we call it Lenz’s law to honor his discovery ever since."
"Every time the magnetic field changes inside a conducting material, it induces a voltage called electromotive force. Depending on the resistance of the material, it creates a current which behaves just like in traditional electromagnets: produces an additional magnetic field. Lenz’s law states that the magnetic field created by this induced current is so directed as to oppose the change in the source flux. To put it more simply, if you create a changing magnetic field by moving a magnet, it will produce a mechanical force trying to slow down the motion. The faster you move, the stronger the force gets. Every time."
Fund it here if you’re feeling this magical ish,..