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?

[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.

[rarkins]

Renovate no longer does that. You need to run the renovate-config-validator yourself, which is bundled with renovate

[ben-foxmoore]

Got it - thanks!

[karfau]

I would love to understand why those checks were disabled. I think this would actually prevent the issue of what I described in #10630 all together.
Maybe it could be put behind some opt in configuration that reduces the related work?

Here is what I was thinking about over there:
The idea of opening an issue in the repo where change is needed might be nice, but maybe there could also be other "entry points" that are closer to the action somebody would naturally do: like creating a branch (starting with the configured branch prefix?) that makes a change to renovate.json, or creating a PR mentioning the renovatebot? Or even adding a commit to any branch but the default one that mentions the bot?

Or, following the idea of the "initially empty PR": having a checkbox in the dependency dashboard, the original onboarding PR or any of the created PRs that can be checked to create such a branch/PR.

My comment might be a bit off topic, but still wanted to add it here, since it's very related.

[rarkins]

Needing to fetch every open PR from the API just in case one of them changed Renovate's config was non-performant. It was easier for us to just fetch every open and closed PR created by our account as a single query. However if the topic can be revisited and an efficient approach found then it could be added back.

[viceice]

I think a better approach would be (at least for github actions) to use our github action to validate with a worflow, this needs renovatebot/github-action#548

I've a github pipeline where i use npx to validate 8 configs in ~1 minute (separate jobs)

[reitzig]

FWIW, I for one would be totally fine requesting a dry-run via (web-)hook from either the Git server (in my case: Bitbucket) or the CI pipeline (in my case: Jenkins).

What I totally see happening is having to configure a slew of regex matchers -- which will never be correct on the first or twentieth attempt. I don't want to do that kind of debugging on the main branch, and I don't want to wait for the hourly re-run of Renovate.

Currently, the only workaround I see is to start a dry-run (for only the current repo and branch) myself as part of the pipeline; any issues would fail the build (fine) and devs would have to read the raw log (meh, but okay).

Ideally, Renovate would be able to create a comment similar to the onboarding one on my PR (of a branch that changes the config file), and keep it current. Knowing repository and branch (see above), at least the problem of finding the PR to work with should be feasible.

[rarkins]

Related/blocked by: #13948

[MPV]

Since this has been implemented now:

• feat(config): validate reconfigure branch #24699
• Trigger renovate-bot to check the syntax of renovate configuration on PRs #13948

...could we review/reconsider this again now? ❤️

[rarkins]

PRs are welcome, this feature is no longer blocked