Let renovate run less frequently

[Frikki]

Investigate if we can configure renovate to only make PRs once a week (or so). If possible, implement it!

[TylorS]

cc @rarkins

[rarkins]

@Frikki @TylorS I'm happy to help.. it's one of my goals to make Renovate so that you eventually see it less and less.

However everything is a trade-off. For example:

• If you group dependencies together, you increase the risk that one dependency breaks and everything else is held up.
• If you set small windows of time for updates, you may not leave yourself enough time in the week to actually get them all merged, and then you increase the risk of them piling up, having conflicts, etc. This is particularly accentuated when you have lock files because it means everytime you merge one Renovate PR, you need the lock file recreated for all the other ones

My preferred approach to reducing the "noise" in a repo is to branch-push automerge as many dependencies as possible, i.e.:

• Renovate creates a branch
• If tests pass, Renovate merges that commit directly to master
• If tests fail, Renovate raises a PR

That way most of those upgrades will be "silent" and just appear in your master branch one by one. It works well if you have good tests and/or for dependencies that can't really "break" your build, e.g. linters, runners, etc. Practically speaking, you should do this for any dependency where you wouldn't have done manual testing/inspection anyway - i.e. save yourself the unnecessary PR and Merge work.

I plan to write up a guide/doc on all these approaches and their pros/cons but also happy to answer direct questions here in the meantime. Maybe a very simple place to start is to configure renovate to run on weekends only and see how you go getting them merged.

[Frikki]

@rarkins Thank you for your time and contribution. A few things, though. It is important to our git history that merges are made with --log and --no-ff flags set. Another thing is that branches derived earlier from master than the renovate merge, e.g., next and dev, will need to be rebased ever so often. Then feature branches, which are being developed, may also have incorrect packages compared to the master. While it's possible to handle it, I actually see an increased workload with that approach. I mean, there's a reason for lock files, yea?

[rarkins]

I'm not 100% sure that I follow your requirements so I'll try to repeat them back with my answers and you can let me know if I'm misunderstanding anything.

It is important to our git history that merges are made with --log and --no-ff flags set.

Renovate can be configured so that it always has 1 and only 1 commit per PR, if that helps. Also it supports two ways to perform automerges - branch push (which I described), where we essentially just update the base branch to point to our Renovate commit that is 1 commit ahead of base branch, or branch merge commit where we use the GitHub API to explicitly merge the renovate branch into base branch.

Here is the API we use for the second "merge commit" approach: https://developer.github.com/v3/repos/merging/
It doesn't appear to be configurable for --no-ff so possibly it will ff, unless GitHub has some other server-side configuration to enforce --no-ff on every commit and the API follows that.

Another thing is that branches derived earlier from master than the renovate merge, e.g., next and dev, will need to be rebased ever so often.

Meaning: if Renovate is updating master branch then next and dev would need to be rebased to stay up to date?

Then feature branches, which are being developed, may also have incorrect packages compared to the master.

Sure, so anyone who's branched off master prior to commits would by definition be out of date - or "incorrect packages" as you say?

While it's possible to handle it, I actually see an increased workload with that approach.

You're meaning that having lots of commits to master means lots of work rebasing all the other branches to keep up?

I mean, there's a reason for lock files, yea?

I don't know what you specifically mean by this.

One more thing: Renovate doesn't have to target your default branch i.e. master. It would also be possible to configure Renovate with baseBranch=next for instance, which means that Renovate would target pull requests to next and leave master alone. But even still.. any feature branches off nextstill need to keep up to date with next.

The only way to not have some work is not to update packages, then? Or more practically.. only update them right before a release? The longer you delay and the more you group - e.g. if you decide to have a single Renovate branch for all minor and patch updates - the more you risk breaks and maybe last minute hunts for which dependency broke things.

Anyway, Renovate is intended to support whatever workflow you prefer - I don't believe in "only one way" to do things - it's just a matter of making sure I understand what you want after you weigh up the pros/cons.

[rarkins]

FYI, I wrote an expanded doc on Noise Reduction for Renovate, if you've got the time to read.