@wycats isn't commiting the lib lockfiles a CI hazard? Like if I tell travis to build+test my repo, it will use the lock by default?
anyway, you don't have to agree with me. I changed my mind after years of agreeing with you and seeing costs slowly shift.
-
-
I'm saying there's basically zero impact of intermittent failures for small projects. I can run it like 5 times in a mins to be sure
-
they suck EGGS for large projects because it's like "well crap there goes another hour"
-
it has nothing to do with running it 5 times. It has to do with reproducing the failure in an env that has a debugger.
-
CI spews the exact numbers: https://travis-ci.org/rust-lang-nursery/regex/jobs/176188633#L228-L243 …
-
if you want a more ergonomic experience: set up the defaults so CI will literally output a lock file in the logs.
-
making CI stagnant, when machines have infinite capacity for vigilance, is a bad solution to reproducing CI results.
-
consistent developer experience is worth a lot. making community defaults "run cargo update" isn't hard.
-
yes, your new dev argument is reasonable. But it comes at the cost of bad CI policy.
- 3 more replies
New conversation -
-
-
if you're trying to accomplish "CI should catch future regressions", run `cargo update` on a matrix line.
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.