3 ms·
IMO there's almost never a good reason to have automated commits in repos outside of two cases: 1) Automated refactoring 2) Automated merges when CI passes C
by xxpor 4y ago
IMO there's almost never a good reason to have automated commits in repos outside of two cases:
1) Automated refactoring
2) Automated merges when CI passes
Configs that can be generated should just be generated by the build.
But that's a different topic
- rrdharan 4y agoThere are at least two other hugely important use cases you missed: - automatic security / vendoring updates (e.g. https://github.com/renovatebot/renovate https://github.com/renovatebot/renovate) - automated cross-repo syncs, e.g. Google has processes and tools that bidirectionally sync pieces of Google3 with GitHub repos
- sangnoir 4y ago> IMO there's almost never a good reason to have automated commit This depends entirely on the quality of dev tools available. Also, commit =/= shipped code: you may have a automated commits and keep a human in the loop before shipping, by way of rejectable Pull-Request (or the proprietary equivalent). A simple library upgrade will result in a wave of commits/bot-authored PRs 1. Human makes a change to a core library, changing it from v1 to v2 2. Bot identifies all call-sites and refactors to v2-equivalent, creating 50 PRs for 50 different teams. One change, 51 commits.