How do we debug/test configuration options

[kpturner]

For example, I have added some configuration to add language specific labels and (matchLanguages) and component specific labels (using matchPaths) and none of this is working as expected. No doubt I have made a mistake or I have misunderstood the purpose of these config options, but how on earth is one supposed to find out what is wrong? Are there diagnostic logs or something somewhere that one can look at? At the moment it seems I have to commit config changes and then just cross my fingers.

[rarkins]

It's a bit like debugging SQL. You can of course validate if an SQL statement is syntactically wrong, but there are no tools which can tell you if the SQL you wrote will return what you want it to return, without you running it on real data, or a copy.

If you have ideas for a feasible type of "playground" and anything similar you've found which we can take inspiration from, then feel free to suggest it in Ideas & Suggestions here.

If in doubt:

• Ask here for help beforehand reviewing your package rule, or
• Fork the repo you will run against, run against the fork - or debug against the fork

There is also the option of running locally with --dry-run=true, so that you can add changes to your config.js instead of committing them, and without the risk of any changes being made to the actual repo. And always run with LOG_LEVEL=debug, even though that won't log every single if/else statement related to package rules.

[billy-mosse]

@rarkins , does this solve the problem of running Renovate on the local repository? What I am very interested in doing is in doing quick iterations of renovate configurations by both:

1. Running renovate locally through a command
2. Running renovate over my local copy of the repository I'm working with (and not the one hosted on github)

[rarkins]

Whenever we say run renovate "locally" we're meaning running it from source, but against a "remote" repository

[viceice]

Renovate always needs a remote repo.

[billy-mosse]

Honest question: why does it need a remote repo by design? Is it extremely hard to add the possibility of analysing a repository that lives in the local filesystem?

It makes things a bit hard when testing different configurations for initial setup/bugfixing. Imagine for example someone works for a company where they can't commit directly to main without a PR review. How would they debug issues with their config?

[rarkins]

It could probably be done, so you're welcome to submit a PR if you want to take a shot. Naturally you can't create PRs locally, and I'm not sure if you'd like to even create branches in all cases

[kpturner]

I did look at "Ways to run Renovate" at the bottom of https://docs.renovatebot.com but I confess it kept talking me in circles. I went to docs.renovatebot.com and then to https://www.npmjs.com/package/renovate where the readme told me to Install the renovate CLI tool from npmjs, run it on a schedule (e.g. using cron) which I think is where I am already - so where are the instructions to actually set up and run renovate CLI locally. I have gone README blind.

[rarkins]

If you want to run locally with dry run then installing from npm is easiest. If you want to debug locally then there's instructions for running from source in docs/contributing/ in this repo

[rearl]

I just tried to run renovate locally in order to validate my change on the configuration. I did this by installing renovate via npm as suggested. But even after hours of trying execution still fails:

fatal: unable to checkout working tree
warning: Clone succeeded, but checkout failed.
You can inspect what was checked out with 'git status'\nand retry with 'git restore --source=HEAD :/'


    at Object.action (C:\\Users\\XYZ\\AppData\\Roaming\\npm\\node_modules\\renovate\\node_modules\\simple-git\\src\\lib\\plugins\\error-detection.plugin.ts:42:29)
    at PluginStore.exec (C:\\Users\\XYZ\\AppData\\Roaming\\npm\\node_modules\\renovate\\node_modules\\simple-git\\src\\lib\\plugins\\plugin-store.ts:29:29)
    at C:\\Users\\XYZ\\AppData\\Roaming\\npm\\node_modules\\renovate\\node_modules\\simple-git\\src\\lib\\runners\\git-executor-chain.ts:127:42
    at new Promise (<anonymous>)
    at GitExecutorChain.handleTaskData (C:\\Users\\XYZ\\AppData\\Roaming\\npm\\node_modules\\renovate\\node_modules\\simple-git\\src\\lib\\runners\\git-executor-chain.ts:124:14)
    at GitExecutorChain.<anonymous> (C:\\Users\\XYZ\\AppData\\Roaming\\npm\\node_modules\\renovate\\node_modules\\simple-git\\src\\lib\\runners\\git-executor-chain.ts:100:40)
    at Generator.next (<anonymous>)\n    at fulfilled (C:\\Users\\XYZ\\AppData\\Roaming\\npm\\node_modules\\renovate\\node_modules\\simple-git\\dist\\cjs\\index.js:55:24)
    at processTicksAndRejections (node:internal/process/task_queues:95:5

In our CI we use the docker renovate image. As such I didn't find a way to "extend" the renovate.json configuration which we use on CI with the missing parameters we set via environment variables.

Please let me know if I should open a separate issue.

[rearl]

Just tried the same on a Ubuntu (run with WSL2) and it works. So it seems there is an issue either with Windows in general (git for windows) or with PowerShell (pwsh.exe) I was using.

[snuggie12]

I'm curious if there's a tool that, given a file, will traverse the extends section and renders all the presets to the final config. Essentially a renovate config parser. Is that doable or do you need to run the full binary to print that out?

[rarkins]

You need to run the full binary. The challenge we had with trying to do this in the validator was that it wouldn't work as soon as you had private presets as it was lacking hostRules awareness

[jzaefferer]

For me running npx renovate --platform=local (as described on https://docs.renovatebot.com/modules/platform/local/ ) helped me check configuration issues (wrongs keys) before going through the steps running the pipeline on GitLab. Maybe that will help some others, too.

[stdedos]

I think that a "summary screen" would be helpful.

From the POI of the onboarding, a "Dependency Dashboard", including:

• Would open MRs:
  • x
  • y

would be useful.

Probably there are other changes it does too, but I cannot think of them.
In abstract, I can think of "Would close", "Would mutate", ...

Ofc, for public repos, I guess it's "equivalent" to opening/onboarding a fork.
However, for non-public, non-github repos, it is more complicated (of course, I may be doing a more-complicated-than-necessary setup ...)

[stdedos]

A way to follow only a single project/package/baseBranch on the output - either as instructions on the documentation site, or also changing output.

Hopefully in a way that would be easy to reconfigure on a CI level (== env variables)