gopkg icon indicating copy to clipboard operation
gopkg copied to clipboard

Badge

Open nathany opened this issue 10 years ago • 13 comments

I'd like to create a badge that displays the latest version in READMEs:

GoDoc

It would link to the package page on gopkg.in.

Having already done the badge for GoDoc, I'd be happy to take this on (when I have a spare evening or two).

nathany avatar Jul 10 '14 06:07 nathany

Neat, thanks!

niemeyer avatar Jul 10 '14 07:07 niemeyer

This is a great idea @nathany . Looking forward to it.

spf13 avatar Jul 17 '14 22:07 spf13

Great idea indeed!

GeertJohan avatar Jul 28 '14 08:07 GeertJohan

Just so you know, I probably won't get to this until September. Other priorities right now.

nathany avatar Aug 07 '14 05:08 nathany

For now, this is focused on having a badge. We can follow up with providing information on how to get the badge.

Going through a handler that retrieves the highest ref from GitHub and then redirects to shields.io for the SVG may be expensive if it needs to be done on every request for the badge.

  • Caching the highest version would complicate deployment (unless it's just in memory).
  • Invalidating the cache would require a GitHub webhook which complicates things for users as well (unless it's just time based, which is less precise).

nathany avatar Sep 24 '14 04:09 nathany

Caching the highest version would complicate deployment (unless it's just in memory).

Can be done in-memory with a simple map[pkg]version (both strings).. Update when 10s old, remove from cache when 1d old ?

Letting users connect a webhook before the badge will work isn't too userfriendly, but do-able... Then it's not required to get a list of all the branches from the github repo anymore.. The downside of updating based on webhook calls is ofcourse that you'd need to sync this information between the deployments.. @niemeyer was it loadbalanced or failover? In th second case it could still work fairly easy.

GeertJohan avatar Sep 24 '14 07:09 GeertJohan

Something like that should work fairly well. I can start without any sort of caching and see how it goes. Still figuring out the code base though #26.

Right now it's possible to use gopkg.in with a repo that has the proper tags even if they aren't familiar with gopkg.in. To keep that ability, webhooks should be optional at best... if supported at all.

nathany avatar Sep 24 '14 13:09 nathany

Any update on this? I'd really like to put a badge on some of my repos :)

eapache avatar Feb 27 '15 20:02 eapache

Sorry Evan. I haven't looked at this at all in the past 6 months. :-(

nathany avatar Feb 27 '15 20:02 nathany

As a work around, you can use Shields.io to create a custom badge, but you will have to update the version # manually with each release.

http://shields.io/

nathany avatar Feb 27 '15 20:02 nathany

If we expose an endpoint that returns a list of all[1] or even the latest versions based on username/repo I could add a badge to http://shields.io. I'll look into the code and see if I can add it myself. A good thing about this approach is that shields.io itself handles the caching.

[1] This would also close https://github.com/niemeyer/gopkg/issues/12

montanaflynn avatar Sep 03 '15 03:09 montanaflynn

I'd prefer to have the badge being served by gopkg.in itself because that's both easy and much more convenient, but I'm not against people using something else if they wish. Caching should be taken into account either way, though. We can't assume that people would not use the API if we provide it.

niemeyer avatar Sep 03 '15 16:09 niemeyer

Though gopkg.in can still be applicable when using the vendor support that Go 1.6 is helping enable, I personally don't see myself using gopkg.in in the future (eg. https://github.com/go-fsnotify/fsnotify/issues/108). That is to say, I'll leave this idea open, but I have no plans to work on it. So long and thanks for the fish.

nathany avatar Feb 12 '16 02:02 nathany

o/

niemeyer avatar Oct 20 '23 10:10 niemeyer