Renovate: Interactive Reconfigure PR

[rarkins]

Consider the case when someone has already activated Renovate but wants to make a configuration change. My idea:

They create an issue "Reconfigure Renovate".
Renovate bot looks for this each run
If found, it opens a "Reconfigure Renovate" PR to close that issue.
PR is initially "empty" but user can edit renovate.json in branch and see results just like the onboarding PR.

Essentially, it's an interactive way to update renovate configuration and helps them validate the config.

[rarkins]

Problem: only administrators should be able to do this

[ikatyang]

How about using a label like renovate-reconfigure?

[rarkins]

How about using a label like renovate-reconfigure?

@ikatyang that might be a good solution! So then the issue could be named anything you like (e.g. "aws-sdk updates are too frequent") and then once they add a renovate-configure label then that is the trigger to create a matching PR?

Maybe the PR could be named like "Reconfigure Renovate: aws-sd updates are too frequent"

[tunnckoCore]

I believe it is not needed, since you can just edit the renovate config (the file or from package.json) from github UI (or commit the updates) - they will take places in the next Renovate's run. Renovate already works that way - i tried it. Don't see value to open an issue.

[rarkins]

Yes but that means you need to "try and fail" on your master branch. It might take someone 2-3 tries to get it right and would be much nicer to have it interactive and can improve as we improve onboarding too.

[tunnckoCore]

mmm probably yea, it takes hours. it only will make sense if opening an issue makes that process faster, which means that renovate should install some listener for such named issues

[rarkins]

It will not make it faster - yet - but it will make it easier and less risky immediately.

[tunnckoCore]

I don't see how it may be useful if it takes same hours (actually, it is not hours - that depens on schedule config), but anyway.

In anyway, maybe it's good idea to think about setting some listener for faster triggering of the runs. I was thinking about that exactly because testing options and behaviors. Is it possible to set schedule option to something like every 30 minutes in weekday or even 10, haha? I've seen that this is based on later lib, but didn't dive deeply there.

Another reason because setting a listener (probably webhook?) is good idea, is that because when i ran renovate cli, it just created branches (after i accepted the Configure/Onboarding PR), but didn't created the PRs for these branches - even after hours, don't know - probably a bug?

[rarkins]

Speed is not the only form of usefulness that exists. I don't agree with your conclusion of "unless this speeds things up then I don't see the benefit". There would be many who are unsure if their configuration changes are correct or not and prefer to test in a branch rather than hacking away on master until it's right.

Importantly this doesn't force you to do anything differently so if you still don't see the benefits this would provide to a non "power user" then it's ok because you can keep committing your renovate.json directly as you were before.

Finally, let's not discuss other topics (scheduling) in the wrong issue. Please raise a new issue and we can discuss there.

[rarkins]

Waiting on #1399

[zephraph]

I'd mentioned an idea in #2879 along these same lines. It'd be nice to not have to have the over head of a special label or issue. If it was possible for renovate to listen for changes to the relevant configuration files on each PR, it could update it based on that info.

Granted, unless renovate is already listening to changes on every PR I know that's a potentially a lot more computational overhead. Thoughts?

[rarkins]

Renovate does already look for PRs that change a renovate configuration file, so this is not out of the question. Currently it tries to verify the config is valid so you don't merge invalid config to master.

To reduce the burden, we only look at ones that have "renovate" in the PR title or branch name (case insensitive check). The bigger challenge was how to run a "mock run" with the branch's config and display it - it would be like Renovate running inside Renovate, and perhaps even more than one time if there was more than one PR altering renovate config.

[zephraph]

Yeah, that definitely sounds challenging. I was taking a look at dry run as a valid alternative in the short term. It's unclear to me if you can run the renovate cli on a particular branch in a repo or if it only ever runs on master.

[rarkins]

I've never tried it but you might be able to do a dry-run CLI that way by specifying your reconfigure branch as baseBranches

[klieber]

I was about to create a feature request for something very similar to what @zephraph requested in #2879. I simply just want to extend the process where renovate validates any PR that contains changes to renovate configuration so that it also updates the PR with what new pull requests it would add if I merged my configuration changes.

My use case is that we just started using renovate so we had a lot of dependencies that needed upgraded and it was going to create around 75 pull requests so we configured renovate to disable a lot of the dependencies that we considered risky upgrades. That left us with around 40 pull requests when we finished onboarding. Now those 40 have all been merged and I want to start enabling those dependencies we originally disabled but I want to review them all first before having renovate create the PRs.

I know I can also rename the onboarding pull request to force onboarding again but that will also stop renovate from keeping other dependencies updated. I might not be ready to merge in the configuration changes for another 2 or 3 weeks so I don't want to completely disable renovate during that time.

Also, on the idea of having an issue or a label trigger renovate. Remember that not all platforms will support that. For instance, we are using Bitbucket Server and we have no way to create "Issues" within Bitbucket Server. Our issue management system is JIRA.

[zephraph]

@klieber one option is that you could enable those packages but have them behind the masterIssueApproval flag.

Here's a snippet from our config:

{
  managers: ["npm"],
  depTypeList: ["dependencies", "devDependencies", "peerDependencies"],
  packagePatterns: ["*"],
  excludePackagePatterns: ["^@artsy", "^@omakase"],
  masterIssueApproval: true
}

This is a package rule that enables massterIssueApproval for all dependencies which aren't in the scope @artsy or @omakase. It'll create an issue where all your dependency updates would be stored...

That said, it's really a work around. If you messed up, you could still get spammed with a bunch of PRs which you didn't intend. @rarkins, a more official solution would still be nice.

[rarkins]

I was going to recommend masterIssueApproval too actually. If you set it at the top level (i.e. not within a package rule) then there should be no possibility of getting "spammed with a bunch of PRs".

Also remember that Renovate's default setting within config:base is maximum 2 PRs per hour so even with a mistake you should notice you are getting PRs you didn't intend to.

Considering that the master issue gives a good preview of PRs, it's unlikely that this issue (Interactive Reconfigure PR) will receive any priority - it would be a lot of work to implement.