All these things sound highly optimistic. You're just hoping that people will run all the tests before pushing (what if CI time is over an hour?). You're hoping that people retrospectively review changes (what if the project is very big?).
I'm only seeing disadvantages compared to traditional MR/PR/diffs.
If they don't CI will fail and not even show that as code to review so it's not exactly an issue. And if they push to master it can always be reverted and the clown shamed. Works well enough
> You're just hoping
...yes, hoping that I'm not working with idiots and change the job if I would be.
It's different for OSS or any project with external contributor but you need to require some minimal level of competence
Yes, CI failing is a big issue! It means you can't bisect, and you show everyone else down while the big gets fixed.
> hoping that I'm not working with idiots
Ah you're one of those "only idiots make mistakes" types. Ok never mind; I hope you can learn that everyone makes mistakes - including you - one day, but I won't try to convince you now.
(You have successfully convinced me that trunk based development is a terrible idea though; at least for anything more than tiny teams working on small projects.)
Throwing some bad commit once a month is not a big deal and not "idiocy" I'm talking about. CI ain't gonna deploy it anyway. At absolute worst you'd have to "git bisect skip" it during bug hunt that one time in two years you get unlucky to hit it.
I'm talking about people that constantly do same stupid stuff or go around system put in place coz they think they are smarter and want to shave few seconds off
We do a bunch of checks in pre-commit stuff but nothing delaying it much, and trust devs will commit working tested code. So far that social contract works just fine
And yes, you can put far less baby bumpers around stuff and go faster if your co-workers are not babies that need every sharp object hidden from them.
I'm only seeing disadvantages compared to traditional MR/PR/diffs.