I know that stabilityDays has some edge cases, where it's not always functioning well.

I was thinking that Merge Confidence, is also a more useful concept, as it gives more feedback and information on the proposed upgrade. So it might make sense to scrap stabilityDays in favor of a mergeConfidence feature where you can select a preferred stability level.

So the question is what is the direction you're going to take this? Is Merge Confidence a straight up replacement of stabilityDays or are you keeping both things around?

Not sure this is the right place to put this request, but I'd really like to be able to only get PRs for packages that are X days old. I've seen many times where I get a PR for a new boto3 version, but when my CI tests run it can't find that version yet. If I could put an age requirement on it, then I could avoid that situation. It seems like right now the Age only shows up on the badge, but you can't include it in the configuration options.

• allow PR opening and automerging to be governed by Merge Confidence values

I just tried out WhiteSource Renovate today. So far, all of the PRs are causing failures during CI testing.

$ git fetch origin +refs/pull/364/merge:
fatal: couldn't find remote ref refs/pull/364/merge

$ git checkout -qf f2bb2ca98968b82ce4700d7e33c3500870444543
fatal: reference is not a tree: f2bb2ca98968b82ce4700d7e33c3500870444543
The command "git checkout -qf f2bb2ca98968b82ce4700d7e33c3500870444543" failed and exited with 128 during .

Seems it has something to do with the fact that every PR created by this app force-pushes and there's some race condition happening between the PR and the CI.

Nice work on the merge confidence feature! This is very interesting and feels like there’s lots that could be done with this data like you show in your blog post.

From the perspective of a package maintainer – I think I would be very interested in having access to the merge confidence data for my packages’ updates. Is this something you’ve considered? For example, as a maintainer of draftjs_exporter, when I make a release I would be interested in knowing whether users’ test suites are passing with this new release, whether people have managed to merge the upgrade, etc. Projects like Prettier, or any and all linters generally, could also be projects where it’s very interesting to know how much breakage there is with each release, as the breakage is somewhat inevitable.

Currently there isn’t really a good way to do this at scale in the package management ecosystem. Some package repositories have quantitative info about adoption in the form of "download statistics" for packages, but that’s about it. Some projects publish alpha/beta/RC releases in the hopes of collecting feedback from users, but that’s all very ad-hoc and qualitative rather than quantitative. Merge confidence feels like it could automate this feedback loop.

Trying to use it self-hosted renovate. We are getting above error.

Thank you for your help.

Create a public-facing website which lets users dig into Merge Confidence details, such as visualizing adoption usage across all releases.

I think it would be good to fill in the About section with a nice description of the repository, and add some relevant tags.

See the About section that is on the Renovate bot repository (right side of picture):

The images used for age, adoption, passing, and confidence level are not accessible to screen readers. Currently, the markdown looks like:

![age](...)

The text in the square brackets should be useful alternative text. Just repeating the title is not describe the meaning of the image.
The markdown simply needs to be adjusted to reflect actual age, percentage, or confidence level.

I was looking through a Renovate dashboard for a big project, and I noticed they have a lot of major upgrades pending.
It would be nice if the Renovate bot can tell you on the dashboard about the confidence level of pending upgrades.
So that a team that's behind on upgrades can pick high confidence upgrades first.

I was thinking of adding a badge for all fields, but that would only clutter things up.
I think using the Merge Confidence badge alone is probably enough.

A badge with "low/neutral/high/very high", for a quick at-a-glance feel of whether the upgrade will be "hard" or "easy" to merge.
I don't know how to get different badges for my mock-up, so I'm grabbing them from a Renovate PR.

Mockup time:

This issue contains a list of Renovate updates and their statuses.

Pending Approval

These branches will be created by Renovate only once you click their checkbox below.

• build(deps): update dependency aws-sdk to v2.812.0
• build(deps): update dependency ini to v2
• chore(deps): update dependency @types/markdown-it to v12

Awaiting Schedule

These updates are awaiting their schedule. Click on a checkbox to ignore the schedule.

• chore(deps): update mcr.microsoft.com/vscode/devcontainers/typescript-node docker tag to v0.154.0
• chore(deps): lock file maintenance (no badge because of multiple deps)

Pending Status Checks

These updates await pending status checks. To force their creation now, check the box below.

• build(deps): update dependency commander to v6.2.1
• build(deps): update dependency got to v11.8.1
• build(deps): update dependency ini to v1.3.8
• chore(deps): update linters (@typescript-eslint/eslint-plugin, @typescript-eslint/parser, eslint, eslint-plugin-jest) (no badge because of multiple deps)

• Check this box to trigger a request for Renovate to run again on this repository

Badges don't currently display in gmail, seemingly because they are SVG. ref

Although SVG is generally preferable, we will look into rendering them as PNG due to this.

First of all, congrats for this great feature. I've had an idea that might take it one step further.

In my experience, I've had (minor or major) version upgrades failing because I needed to upgrade not just one but multiple dependencies at the same time, and sometimes, wait for Package B to release a version compatible with Package A's new version. Figuring that out takes a bit of time.

It seems that with the data you have, you may be able to find correlations between a release's test results and the presence and version of other dependencies, e.g.:

• Upgrading to react v17 from v16 has a 80% test success rate
• Among repos also using react-dom v16, this upgrade has a 20% success rate
• Among repos also using react-dom v17, this upgrade has a 98% success rate
• We conclude that the upgrade to react v17 is successful when it is made along with react-dom v17, and we can help developers upgrade by informing them of that correlation.

This is a fictional example since react is a monorepo, but you probably get the idea.

There is an error with this repository's Renovate configuration that needs to be fixed. As a precaution, Renovate will stop PRs until it is resolved.

Error type: Cannot find preset's package (github>whitesource/merge-confidence:beta)

How to use? --> "extends": ["github>whitesource/merge-confidence:beta"], adding on renovate.json we get this error above.

Hi,

i found whitesource's general privacy policy, but it would be useful for transparency and other reasons to clarify which kind of data is collected/transmitted etc..

(btw the privacy policy link on https://resources.whitesourcesoftware.com/news-whitesource/merge-confidence-feature# links back to the page itself)

regards,
strowi

Currently most monorepo updates such as for @angular show low data because we currently exclude branches with more than one update from our statistics. However, for packages which are nearly always upgraded together, this means we filter out all the data!

First step will be to prefer source URL for each package and base our filtering on unique source URLs instead of package names.

Second step will be to include weighted scores for multi-source PRs, especially if they pass.

The markdown engine we are using for BitBucket server does not support @ in links.

We have been able to fix this by replacing {{replace '/' '%2f' depName}} with {{replace '@' '%40' (replace '/' '%2f' depName)}}

There should be a way to disable merge confidence for specific repos so that internal project names are not leaked to https://badges.renovateapi.com

Take prettier for example. From using it for 1-2 years:

1. Quite often the new version doesn't fail/break anything, so we merge
2. Sometimes it breaks things, but I like the change, so we fix it and merge
3. Occasionally I don't like the change, and hold off hoping they'll revert it (only happened once)

Both scenarios (2) and (3) don't mean "bad upgrade!". In scenario (1), I shouldn't really care even if it broke something big like 40% of other repos. In scenario (2), it can be useful to know "it wasn't just me" but it doesn't really change my decision whether it's 2% or 40% of others breaking. For (3), if I see it causes a large percent of repos to fail then it's interesting to know but still doesn't change much.

The same thing goes especially for things like eslint plugins.

WhiteSource rebranded to Mend, so the image should be updated.

• Make new screenshot of Merge Confidence badges in PR
• Make background dark/blurry like in the existing image
• Replace existing image with the new image
• Open PR

Link to image

Hi guys, I am figuring out how to configure renovate to auto-merge my own dependencies.

It saves us some time when we release patches to our type libs.

Some advice about this?

Jose

I'm not certain this is a solvable issue, but here's what I've seen.

Using:

• renovate gitlab runner
• Python 3.10.3
• Poetry version 1.1.13

Steps:

• poetry add fabric (this adds Fabric to pyproject.toml, poetry will not resolve fabric)
• manually downgraded to 2.6.0
• ran renovate CI pipeline
• MR was created, with merge-confidence badges, but they are all dataless (examples below)
• Editing MR to use Fabric instead of fabric in the renovateapi urls shows the correct data

Current Behavior:

Package	Change	Age	Adoption	Passing	Confidence
Fabric (source, changelog)	2.6.0 -> 2.7.0

| Package | Change | Age | Adoption | Passing | Confidence |
|---|---|---|---|---|---|
| [Fabric](https://fabfile.org) ([source](https://github.com/fabric/fabric), [changelog](https://www.fabfile.org/changelog.html)) | `2.6.0` -> `2.7.0` | [![age](https://badges.renovateapi.com/packages/pypi/Fabric/2.7.0/age-slim)](https://docs.renovatebot.com/merge-confidence/) | [![adoption](https://badges.renovateapi.com/packages/pypi/Fabric/2.7.0/adoption-slim)](https://docs.renovatebot.com/merge-confidence/) | [![passing](https://badges.renovateapi.com/packages/pypi/Fabric/2.7.0/compatibility-slim/2.6.0)](https://docs.renovatebot.com/merge-confidence/) | [![confidence](https://badges.renovateapi.com/packages/pypi/Fabric/2.7.0/confidence-slim/2.6.0)](https://docs.renovatebot.com/merge-confidence/) |

Expected Behavior:

Package	Change	Age	Adoption	Passing	Confidence
Fabric (source, changelog)	2.6.0 -> 2.7.0

| Package | Change | Age | Adoption | Passing | Confidence |
|---|---|---|---|---|---|
| [Fabric](https://fabfile.org) ([source](https://github.com/fabric/fabric), [changelog](https://www.fabfile.org/changelog.html)) | `2.6.0` -> `2.7.0` | [![age](https://badges.renovateapi.com/packages/pypi/fabric/2.7.0/age-slim)](https://docs.renovatebot.com/merge-confidence/) | [![adoption](https://badges.renovateapi.com/packages/pypi/fabric/2.7.0/adoption-slim)](https://docs.renovatebot.com/merge-confidence/) | [![passing](https://badges.renovateapi.com/packages/pypi/fabric/2.7.0/compatibility-slim/2.6.0)](https://docs.renovatebot.com/merge-confidence/) | [![confidence](https://badges.renovateapi.com/packages/pypi/fabric/2.7.0/confidence-slim/2.6.0)](https://docs.renovatebot.com/merge-confidence/) |

Issue #11 and #12 were manually closed, but the project board still lists them as "To do", instead of moving the cards to "Done".
I think this is because there is no automation setup on the project board.

See https://docs.github.com/en/github/managing-your-work-on-github/configuring-automation-for-project-boards

whitesource/merge-confidence:beta

This should be low: