Automerging renovate PRs

[wolfy1339]

Please don't use scripts for automerging the renovate PRs.

Whenever a new major version of a dependency is pushed and renovate opens a PR, we should take the time to read the changelog and not blindly merge them because tests are passing.

Because of this, some PRs that contained breaking changes that also affected the dependee package and these were merged as patch releases.

Now, I understand that these PRs could have been marked with a "Request Changes" review and it would have stopped them from being merged, however we shouldn't blindly rely on tests passing to merge these PRs

[gr2m]

I've been more careful recently as we work through the breaking changes of dropping support for older Node versions.

But in general I disagree, because we have to trust our CI. If our CI is green but the pull requests introduces a breaking change, then we have to fix our CI.

I do check changelogs, but often times the same update is applied to a lot of repositories I maintain. If I review it once and conclude that the changes look good, I want to merge all of them at once.

Maybe we can flag special repositories or cases that we want to be more careful about when it comes to dependency updates?

[oscard0m]

some PRs that contained breaking changes that also affected the dependee package and these were merged as patch releases.

I know how annoying this can be and the extra work on finding out, replying issues to Octokit users and working on a fix under pressure. Thanks for all the effort you are putting here @wolfy1339. Any measure we can take to reduce this friction, count me in.

If our CI is green but the pull requests introduces a breaking change, then we have to fix our CI.

I agree with this. @wolfy1339 do you know how I can find the renovate PRs which introduced regressions? I would happily open the corresponding issues to improve our CI to catch those.

Maybe we can flag special repositories or cases that we want to be more careful about when it comes to dependency updates?

Until we feel more confident with our CI, it could be an interesting measure. Maybe we can do something at renovate config level, where we can apply some extra label and/or the WIP in the title (or open it as a draft) to block the PR and require human intervention.

What do you think? @gr2m @wolfy1339

[wolfy1339]

As for the Octokit modules, renovate now groups them all together so it should be easier on that front whenever there's a wave of Breaking Changes across the repos

[wolfy1339]

If our CI is green but the pull requests introduces a breaking change, then we have to fix our CI.

I agree with this. @wolfy1339 do you know how I can find the renovate PRs which introduced regressions? I would happily open the corresponding issues to improve our CI to catch those.

You'd have to search through all PRs opened, if you search for revert you should find them

[gr2m]

Maybe we can flag special repositories or cases that we want to be more careful about when it comes to dependency updates?

Until we feel more confident with our CI, it could be an interesting measure. Maybe we can do something at renovate config level, where we can apply some extra label and/or the WIP in the title (or open it as a draft) to block the PR and require human intervention.

If we have to apply things manually, we can as well add a reject review and/or set the pull request to draft.