Some automerge thoughts

[HonkingGoose]

I deliberately gave you a really simple automerge config, it's tricky to get this right the first time out of the gate, and I don't want to create a mess in case I did something wrong. That said, there are some things you'll probably want to tweak later on.

What type of dependencies are automerged

Right now you only get lockfile updates on Monday, that should be automerged.

I understand that you might want to automerge devDependencies next, that should be somewhat safe, provided you have test coverage.

Renovate bothers me with PRs for automerged dependencies

Each time Renovate opens a PR you get a GitHub notification for it if you're following the repo (which as maintainer, you probably are...). It will probably annoy you to get notified about a PR that's automerged succesfully anyways.

Luckily Renovate has an option that we can configure called automergeType:branch to make the automerge process as silent as it can be.

Quote from the Renovate docs on the automergeType setting:

If you prefer that Renovate more silently automerge without Pull Requests at all, you can configure "automergeType": "branch". In this case Renovate will:

1. Create the branch, wait for test results
2. Rebase it any time it gets out of date with the base branch
3. Automerge the branch commit if it's: (a) up-to-date with the base branch, and (b) passing all tests
4. As a backup, raise a PR only if either: (a) tests fail, or (b) tests remain pending for too long (default: 24 hours)

I need more documentation on this automerge thing, where can I find it

You can search for the term automerge on the https://docs.renovatebot.com/configuration-options/ page of the docs to learn more.

[gr2m]

Luckily Renovate has an option that we can configure called automergeType:branch to make the automerge process as silent as it can be.

I love this. +1 from me. What do you think @travi?

But for this to work we will have to enable builds for renovate/** branches in order for the tests to run without creating a PR

[travi]

i was aware of the branch option, but had forgotten about it. i personally dont mind the noise and like the visibility because i like to read the release notes of things that get updated. however, we have a lot more folks that follow our repos than my typical projects, so that could be a good balance. i'm curious what @gr2m thinks.

edit: looks like he's supportive :)

[gr2m]

I think for the lockfile and dev dependency updates we are good, for production dependencies I wouldn't want auto merges in the first place. Or maybe automerges are okay, but only once a maintainer approves the PR

[travi]

i have a branch available for this config adjustment, linked just above this comment. i think github is having issues though, since it tells me the branch doesnt exist when i try to create a PR from it :\

i'll try again later, but feel free to open a PR for me if you get to it first

[travi]

also worth noting with auto merging... merges don't happen immediately after the checks go green, but instead get processed the next time renovate scans the repo. that should change at some point, assuming that renovatebot/app-support#39 becomes unblocked at some point

[travi]

got it sorted out. note for the future... dont use a renovate/ prefix on a branch name. i think that triggered renovate to clean up the branch since it didnt know about it, haha. i'm a little surprised ive never hit this before, but i probably havent tried to be that organized with branch names for renovate config changes

still left github in a weird state (its still suggesting that i open a PR since i recently pushed commits to that branch)