Simplify testing of renovate's configuration

[davinkevin]

Tell us more.

Hello 👋

This is a follow up after this comment.

As a developer, I would like to "test" a change in the repo configuration. For that, I follow the usual dev-workflow, where I create a feature-branch and update the renovate.json5 file. Then I push my branch, making it available to every processes or automation.

For my local tests, in dry-run mode, I use the following command:

cd $(mktemp -d)
          
cp renovate-testing/.renovate_gitconfig .
cp renovate-testing/config_agent.js .
sops -d renovate-testing/renovate.env > renovate.env

mkdir -p $TMPDIR/renovate 
chmod 755 $TMPDIR/renovate

docker run -it --rm \
  -v $PWD/.renovate_gitconfig:/home/ubuntu/.gitconfig \
  -v $PWD/config_agent.js:/usr/src/app/config.js \
  -v $TMPDIR/renovate:/tmp/renovate \
  -e RENOVATE_DRY_RUN=true \
  -e RENOVATE_BASE_BRANCHES=release \
  -e LOG_LEVEL=debug \
  --env-file $PWD/renovate.env \
  renovate/renovate:38.94.3

The issue with this logic is I can't override all configurations from default branch by the configuration's feature-branch I have created.
The best I can do is to include the all the renovate.json5 into my config_agent.js and set requireConfig: ignored and onboarding: false… but it's complicated and not even the same format (js vs json5).

It's maybe optimistic to propose a solution, but from a user perspective, it would be good to have a flag where I can say "trust this branch and ignore everything else from the repo". And this would be a parameter at the config.js level where I provide the branchName.

Thank you for your help and wonderful product 😇

[rarkins]

How specifically are you testing it? e.g. it sounds like you would be checking through the logs for signs of problems? To compare how many branches would be created or deleted?

[davinkevin]

Yes. I use the debug output to understand what will be done:

• number of detection
• number of managers
• Update checks
• PR closed and/or opened

[rarkins]

I think the idea solution would leverage Renovate's existing renovate/reconfigure concept, but perform a dry run and add a comment to the PR (e.g. describing any changes to dependencies detected or branches to be created). This approach would allow "regular" developers to get the same benefit without needing to have access to run their own container. Unfortunately it's quite challenging to implement though.

Another possibility would be allowing some form of "override default branch" configuration by admins, which could then be used together with dry run to achieve what you're after

[davinkevin]

First solution is good and advanced, and more user friendly, indeed.

However, in the short term, something like the second solution would be good enough. In companies I worked in, doing a docker run (or podman run…) was definitively possible, so using a container was not an issue (and I worked in security, defense & bank environment).

note: allowing this will help engineers to configure renovate instead of asking the DevProd or DevOps team to manage that for them because… the workflow to test it is too complicated.