3 ms·
> The first seems like it would be very frustrating if code with failing tests if pushed with any frequency, but seems to be literally what the phase "work on m
by science4sail 5y ago
> The first seems like it would be very frustrating if code with failing tests if pushed with any frequency, but seems to be literally what the phase "work on main" means.
Yep, that's the point - it's to discourage devs from checking in failing code (because then they'll be swarmed by annoyed coworkers). It's fairly common to see developer A make a breaking change to some low-level library and then see developer B push a rollback of A's changes a few minutes later (with or without A's permission).
- sparsely 5y agoIf that's fairly common it doesn't seem like a great setup? Why not automatically run the tests beforehand? And presumably there is no need for a staging env, since your code is deployed to production as soon as it has passed tests.
- Jensson 5y agoAt Google your tests are automatically run beforehand, but not all tests of entire Google are run for your commit beforehand. Sometimes you break others code with your change. Edit: Just to clarify, it isn't ok to break downstream projects, if you do the change gets rolled back almost immediately. And you can run all tests for the change before submitting, but it isn't default since it is expensive for many core projects to run so many tests.
- dboreham 5y agoTests were run beforehand. Just not the right test.