Renovate badge

[tunnckoCore]

Hey! :hand:

I'm thinking to drop most of my badges and stick to as minimal as possible, but want to show that my deps are always up to date, because Semantic-Release (probably) and Renovate and good its specific config that i'm thinking now (low noises, big automation, plus pinning versions).

So i think this would be enough

[![Renovate - Always up to date][renovateapp-svg]][renovateapp-link]

[renovateapp-link]: https://renovateapp.com
[renovateapp-svg]: https://img.shields.io/badge/always-up_to_date-brightgreen.svg

[rarkins]

My thoughts:

• Installing Renovate doesn't necessarily mean you're up-to-date :) Even with automerge, some tests might fail.. How about or similar?
• Any value in having a dynamic badge that indicates if a repo has any outstanding updates? The downside is that most repos will have some dependencies out of date at some time, and then it might be discouraging to people if they always have a yellow or orange colour.
• Maybe a tricolor badge that shows if a repo is up-to-date for major/minor/patch?
• Or are we duplicating https://david-dm.org/ ?

[rarkins]

If we were doing statuses:

• "up to date" and bright green if no updates at all outstanding
• "patched" and green if all minor/patch updates applied but any major ones outstanding
• "out of date" and yellow if minor out of date
• "out of date" and red if patch out of date

But perhaps also with some "delay" incorporated? e.g. it's a bit annoying if your repository suddenly turns red the minute a new patch is out and you will have it patched within an hour or few hours or whatever.

[ikatyang]

How about indicating if Renovate is enabled for the repo?

[rarkins]

Yeah I'm thinking of how to do it in a forwards-compatible way so that it can be enhanced in future without changes to everyone's readme. Maybe I set up and dummy AWS API gateway endpoint that simply answers with "renovate enabled" and then later improve it to:

• show "disabled" if the repo is not known!
• show advanced details about a repo's status (out of date, etc)

Also need to think how to do it for private repos without it being a security concern for those (e.g. Needs a secret strong in addition to repo name)

[tunnckoCore]

How about monitored or similar?

Thought exactly for that, but is too long for my taste (David's "up-to-date" is long too) :D As about the other things, I believe there is a room for such service like David DM - your ideas sounds good.

answers with "renovate enabled" and then later improve it to:

Probably yea. It's a good start.

[hutson]

Installing Renovate doesn't necessarily mean you're up-to-date

I agree with that statement. While seeing a renovate badge will tell me a little bit about the efforts a package manager has put into the sustainability of their project, it doesn't tell me whether their package is, at that moment, up-to-date with their dependencies. They could quite easily leave renovate installed, but neglect to actually accept any renovate-generated pull requests.

Or are we duplicating https://david-dm.org/ ?

As a major consumer of npm packages, I actively look at david-dm badges on projects, and will take into consideration the state of those badges when deciding whether to use a package.

So maybe both badges are, in their own way, telling me part of the story about the suitability of a package for consumption. One is indicating whether the package is actually up-to-date, while the other tells me how much the maintainer cares about their package, and if the package is currently out-of-date, that perhaps it will be auto-updated in the near future.

[rarkins]

Hi all, thanks for the feedback. Based on your inputs, my current line of thinking is:

• David DM badge is useful/widespread and no need to duplicate it for now
• Whether a repository is up to date and whether it has renovate installed are separate matters :)
• For now, a simple voluntary and static "renovate enabled" badge should be fine
• Later, I will consider adding a dynamic badge for the service itself, which can indicate:
  • enabled or disabled
  • Number of PRs outstanding

So I think that the combination of "are dependencies up to date" courtesy of David, plus "number of PRs outstanding" could be good and complimentary.

So for example if someone is on Webpack 2.x and has decided not to upgrade to Webpack 3.x (i.e. closed the Renovate PR), then it might show as slightly out of date on David, but would show as green/0 PRs outstanding on renovate.

[daKmoR]

As seen here I was looking at david dm badge - and that really works well for "normal" git repositories. E.g. if you have one package.json file in the root of your git.

However my use case is a monorepo and I really like renovate because it picks up all the nested package.json and handles them.

So on how it behaves and looks, I would say david dm is really nice... so having the same feature but aggregated for ALL package.json files would be awesome :)

My guess would be that something like this would be out of scope for david dm*, but renovate should already have all the needed data right?

* I asked let's see what they say.

[rarkins]

Thanks for the update. It's useful to know if there's a feature gap in David DM now with monorepos.

For me the challenge is (1) how to "fairly" summarise update statuses into some single score, and (2) how to fit it into a single badge. e.g. a patch update open for 2 months is a lot different to a major upgrade open for the same.

Although if we do it with an API, I suppose that it's possible to support a few different approaches and let people choose which they use.

[nottrobin]

I'd also appreciate it if Renovate included a badge that could summarise the status of Python dependencies too. Or one that shows the status of all dependencies.

[tunnckoCore]

Yea, one more reason why Renovate should have a badge, and that isn't a duplication of DavidDM. Now Renovate supports more than NPM/nodejs so a badge showing a status would be great. Renovate will become DavidDM for all the languages that it supports :D

[rarkins]

OK, I plan to add this soon. To begin with, the badge will just say onboarding/enabled/disabled, but later on (without change of badge URL) will be updated to be more dynamic and perhaps even customisable, e.g. to display number of dependencies out of date, number of PRs, a score, etc.

[tunnckoCore]

@rarkins yup, sounds good.

You can try to use npm.im/badgen library (not the badgen service). :)

[rarkins]

Please help me through the logic here. I want it to be able to work both for self-hosted CLI users as well as the app, even though the app one is intended to be much more sophisticated.

So:

New config option badgeUrl which defaults to null. A PR proposing the badge will be created only if it's a non-null value, i.e. by default there is no Renovate badge in the CLI tool. CLI users could simply set it to a static SVG URL that says "renovate enabled".

If badgeUrl is non-null and the repo contains a readme.md then a PR will be raised only if the repository is already onboarded. i.e. for new repos, the PR will come after onboarding is completed but for existing repos they will all get a PR at the same time once this feature is turned on in the app.

To ignore/decline the badge suggestion:

• Ideally, you just close the PR and Renovate can find it again. Possibly though if you end up with 1000+ closed Renovate PRs then the badge comes back again because GitHub doesn't tell us about the closed PR anymore
• You can fully decline it by setting "badgeUrl": null in renovate config, including preset. This will stop it ever being created too, if present

The app will set the image to a dynamic renovatebot.com URL. Initially this will say "enabled", "disabled", "onboarding" or "unknown". The image will link to the dashboard for the repo.

In future, how to make it customisable? In the best tradition of Renovate, I think it should be via config, e.g. a new option badgeParameters or something like that. Renovate CLI would ignore them, but Renovate the App would read these during its normal run and write them to its backend DB and then use that to determine what to display whenever the badge is requested. e.g. it could be "simple" (enabled/disabled/etc), it could instead say "7 updates" (meaning 7 dependencies), or it could say "2 PRs" if there is grouping. I guess it's OK to defer this decision.

[nottrobin]

Does the badge need to be something managed by Renovate through config?

I understand that filing PRs is what Renovate does, but I'd personally feel more comfortable if it only did that specifically for its core MO of upgrading dependencies, and not for all sorts of other things like adding badges. Otherwise I'd start to feel like I didn't know what Renovate might do on my repo next.

Like, what happens if Renovate files the PR to add the badge, it's merged, and then you set badgeUrl: null again - does it now file a PR to remove it again from the README? What if it's been modified? I feel it would make Renovate users feel more empowered if they added that to the README.md themselves.

All I was expecting was that somewhere in documentation it would tell me how to add a renovate badge to my README.md myself, with a snippet similar to:

![renovate dependency status](https://renovatebot.com/badges/dependency-status.svg?repo=canonical-webteam/docs.snapcraft.io&branch=master)

(Any additional options could just be supported as further query parameters on the URL. Or through different endpoints.)

In any event, it seems that simply providing a badge image endpoint would be the first step, and then you could explore automation options for managing it through config as an enhancement.

[rarkins]

Renovate would suggest the badge in a PR once per repo - after onboarding - and anyone with multiple repos using their own preset could even disable that behaviour because they will merge the custom preset as part of onboarding.

If you want to remove a badge after adding it, you'd remove it yourself - no PR from Renovate for that. The badgeUrl option controls only whether it is suggested or not.

I would be pretty certain if you made badge addition DIY-only, you'd get something like 3% adding it to their README. If you proposed it in a PR, I would expect it to be 10x that or more, especially if the badge content is meaningful (e.g. providing context on the dependency state of the repo). The difference between those two values is simply down to it being convenient or not. Ignoring the fact that I made those figures up, it's up to you which is more important: the 27% of users who want it but can't be bothered adding it manually, or the 70% who'd close the PR.

Remembering that Renovate already raises 100s/1000s for PRs per-repo in most cases, I'd hope it's a rare for someone to object to 1 additional PR immediately after onboarding which suggests a badge that shows visitors to the repo (a) that you keep dependencies update, and (b) how well you're keeping up with that. I've seen other services include the badge readme update with their onboarding, i.e. if you don't want it then you have to manually delete the readme.md change out of the initial PR before you can merge it. What I'm proposing is much politer.

We would also not want unsigned image URLs for private repos, so providing instructions on how/where to get the full URL would make it even less likely that people add it manually.

What I can maybe do though is make a random selection of users accounts initially (for example, just users starting with n) see what the ratio is of merged:open:closed. I could also delay that introduction until the badge can nicely say how many updates there are and colour code a "score", so people are more likely to see the value.

[nottrobin]

Those are all very good points. It is especially true that people are much more likely to add it under your model. I agree that a separate PR is better.

I think, though, for that purpose, you might want to simplify the config option to just badge: true|false? Presumably Renovate is the one that knows the URL, and probably wants the ability to change it. In future, you could extend it to badge: { ... options ... }, when there are further options.

[tunnckoCore]

Absolutely agree with @nottrobin. It sounds more complicated than it should be. Just expose an API endpoint that gives you status metadata as json, so we can use it. And another endpoint for the badge.

I think, though, for that purpose, you might want to simplify the config option to just

Yea.. I don't get what badgeUrl could be. true/false sounds me better.

@rarkins: What I can maybe do though is make a random selection of users accounts initially

Yea, definitely better :D

And yes, for sure, it's more likely most will accept those PRs than consider adding a badge themselves manually. But I'm against such PRs because have strict preferences about my readmes and I even don't modify them manually, I generate them. Even if didn't do that, still don't like the idea because no one can know where to put that badge exactly. Yea, there is some convention, but still.

[rarkins]

@tunnckoCore I think you're potentially the only user who autogenerates their readme's, so I don't want to optimise for that particular case. i.e. so long as you can disable automatic PR insertion, that's all you need.

badgeUrl would only be the concern of bot admins, not of bot users.

For the app's URL, I would prefer to keep its URL simple and control its contents via config. That way - regardless of whether the badge is added with automated PRs or manually - it means that users can centrally control (via presets) how their badges look, which will be particularly important assuming the badge's richness and configurability will be improved over time (e.g. including changing colour if there are vulnerabilities among the updates waiting).

Right now the URL in planning would be like https://badges.renovateapi.com/github/renovateapp/renovate

[cdaringe]

[![Renovate](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovatebot.com)

for now, i'm using shields.io ^

[JamieMagee]

@cdaringe Nice! I took your idea a little further, and added the renovate logo. I put the code in a gist

[vidavidorra]

Would love to see this feature~ @rarkins is there any update/timeline on it?

[rarkins]

Nothing really planned yet. Moving this to the app repo though because it's dependent on the service and not the open source code.

[mizozobu]

If you just need a shortcut to your dashboard like me, here it is. Customize it to your preference on https://shields.io