We may ask you to create a "minimal reproduction" repository to help us fix bugs or work on a feature.
This document explains why we need a minimal reproduction, why we won't use your production repository to debug, and how to create a good minimal reproduction.
A minimal reproduction helps us to:
- Fix your bug faster
- Work on your feature request faster
- Confirm the cause of the behavior
It's fastest if you - as the bug reporter or feature requester - create the reproduction.
The first benefit of a public reproduction is to prove that the problem is not caused by your environment or by a setting you left out of your description, thinking it wasn't relevant. If there were any doubts about whether you'd found a genuine problem before, they are usually removed once a reproduction is made.
Next, when a reproduction has minimal config, it can often let us narrow down or even identify the root cause, suggest workarounds, etc. This means we can often help you from code inspection alone.
Finally, by making the code/dependencies minimal, it usually makes the problem feasible to step through using a debugging if code inspection wasn't sufficient. Production repositories or non-minimal reproductions are often very difficult to debug because break points get triggered dozens or hundreds or times.
The basic idea of a minimal reproduction is to use the least amount of both code and config to trigger missing or wrong behavior. A minimal reproduction helps the developers see where the bug or missing feature is, and allows us to verify that the new code meets the requirements.
If you can, use GitHub to host your reproduction. If the reproduction needs to be on GitLab or Bitbucket, that's also okay.
There are two ways to create a minimal reproduction:
- Start with an empty repository and copy files from your production repository
- Start with a fork of your production repository and remove files and config
General steps:
- Create your minimal reproduction repository on GitHub, only use GitLab or Bitbucket if really needed
- Use the fewest number of repository files and dependencies
- Reduce the Renovate config to a minimum
- Remove private or secret information
- Create a
readme.mdfile that explains the current behavior and expected behavior - Set the repository visibility to
public - Give us the link to the repository
You may think:
Why do you even need a minimal reproduction? I already have the reproduction on my production repository and it's public. Why not use that to debug?
A production repository usually has:
- many dependencies
- many custom rules in the Renovate configuration file
- many files that are not relevant
Having lots of "moving parts" makes debugging tricky, because debug break points can be triggered hundreds of times.
When you have lots of custom config for Renovate, it's hard to find the root cause of the behavior. Bugs are often caused by multiple features interacting. Reducing the config to a minimum helps us find out exactly which config elements are required to trigger the bug.
We'd love to get down to zero reported bugs or feature requests remaining, but we have a lot to do and must set our priorities. This means we prefer working on issues with a minimal reproduction, as they allow us to spend our time efficiently.
If you don't create a minimal reproduction, we won't prioritize working on your issue.
Issues without a reproduction will probably stay open until you, or somebody else, creates a minimal reproduction. After a while, issues without a reproduction may be closed unfixed.
Thank you for describing your issue in detail. But we still need a minimal reproduction in a repository, and we'd like you to be the one to make sure it matches both your description as well as expected behavior.