Shields.io badge service

I just made a PR to the shields.io project to add version badge support for ROS packages. This will allow ROS projects to embed a small image in their websites or Markdown READMEs that will show the latest version of a package available in a certain distro. For instance, https://img.shields.io/ros/v/noetic/moveit_msgs.svg would return a SVG image that looks like this:

image

The PR is here – I’d welcome any feedback or input on how I am interpreting the repo’s tags and the distribution.yaml files.

10 Likes

This is now live! For example, https://img.shields.io/ros/v/humble/vision_msgs returns this image:

2 Likes

@jtbandes The badges look nice, thanks for the addition!

I thought I’d add a note - the last part of the url should be the name of the repository the package belongs to.

Of course, this works if there is a package with the same name as the repo, like vision_msgs.

Thanks for the heads up. I’m not sure if I fully understand your point — are you saying that there is a problem with the way this badge is implemented, or just that I’m using the wrong terminology, or something else?

To provide an example of what I believe is being highlighted here:

This badge works: ros | noetic: v1.17.2
This badge doesn’t: ros: package not found: navfn

The first badge points to the “navigation” repository of the ros-planning github organization. However, that’s not a package: that’s just a repository. The actual package is DWA, navfn, etc, found within that repository. The second badge points to navfn, which is an actual package (and therefore has a version, can be installed, etc). Yet, this package is not found by the shield.

It seems to me like the shield is incorrectly conflating ‘repository’ with ‘package’: while these are often the same, it is common to see many packages in one repository, and they may not be the same version. Even in the cases where these are the same, what happens if I create a “navigation” repository on my github account? The ROS distribution wouldn’t find a problem with that (so long as the package names remain unique), but that would cause a conflict for these badges.

I think the answer to your question is that there’s likely an implementation problem. This is really cool though, and once it gets ironed out I look forward to putting it on my packages!

1 Like

Thanks for the explanation & example! I think this will fix it, let me know if it looks right:

2 Likes