This just reads like a prequel to "why PR reviews are useless" blog post.<p>If a bot "approves" a PR in this fashion, it's not an approval, you've just set up a "changes to this file are not worth reviewing" rule, and handed out a green check-mark particpation award. Just let your developers force-merge such non-issue pull requests. The very essence of PR approvals is someone else looking at your masterpiece, thinking about it and pointing out the things you forgot. If you don't have time for that, be honest with yourself and let go of the mandatory approval requirement.<p>As for the latter part, the instant PRs and merges for updates, congratulations on re-implementing a monolith while calling it a microservice.<p>Sincerely,
- A very cranky developer currently very slowly steering a carelessly reviewed codebase back on track.
I like the intent here, but I think some things should be clarified.<p>If the swagger files are being autogenerated, then why would you ever review them? You should <i>test</i> them, but reviewing isn't appropriate. You should review the things that generate them instead. When they change, that's a build artifact (I don't review my generated libraries and binaries, I only test them before delivering them).<p>On the commitbot, I hope you're not doing that in deployment without running it through test first. Can it also generate issues if a particular service fails its tests after the update?
Automating repetition of code is a sign that your stack is poorly factored for your needs. Automating code repetition up front won't save you from maintenance repetition, and maintenance is about 2/3 of average product cost.<p>The most productive stacks I have worked with trimmed out stuff that wasn't needed for our particular organization.
Every organization has common patterns they are used to and like. But, off-the-shelf stacks have to cater to a wide variety of organizations and organization preferences. Get a <i>tunable</i> stack and trim trim trim, and refactor duplication. Learn from each generation of product releases and make your API's better for the next.<p>Make special behavior as-needed plug-ins, not part of the main stack. Don't be a feature horder in the main stack, but keep a library of handy add-ons that are known to fit your stack when needed.<p>As an example of flexible factoring, you shouldn't normally have to specify the title and max length of an input field more than once (D.R.Y. Principle). If you have to keep doing it twice, find out why and factor it out. However, keep in mind that sometimes you do need to override the default title for specific needs such that you shouldn't remove the <i>potential</i> for task-specific customization in your effort to refactor. Use shared defaults for a field, but don't force shared defaults.<p>You should spend most of your coding time plugging in parameters to well-tuned API's, not copy and pasting repetitious code. Most of your actual coding should be for behavior that is unique to a project. Think twice, type once, instead of the other way around.
i am all for having your ci ensuring the quality insurances which can be automated (firing unit tests, static code analysis, etc.) to reduce the amount of work any reviewer has to do on a pull request.<p>nevertheless, auto approving and merging pull requests and also auto bumping dependecies with only a bot as reviewer does sound like a very bad idea in general. how does one make sure the bump required for service A doesn't break service B which also relies that dependency? admitted, testing someone else's code is not the most exciting part of being a developer, but it's a necessary evil isn't it?<p>to be honest, this workflow sounds like hotfix hell to me when you'd combine it with continuous deployment...
Taken in isolation, the poster's example seems silly. It's just a PR, right? We'll add some process to ensure people look at it in a timely fashion yada yada yada.<p>Ok, but what about _all these small tasks over there_? They may also be small, but you have to think about them, work on them. Every second you are working on them you are not adding any value. Your brain gets tired, it makes everything feel so difficult to do, increasing friction on all tasks.<p>One thing that can't be overlooked: deploying changes to bots should also be seamless and automated as far as humanly possible. Otherwise they too will fall behind.