Add [ROS] version service

[jtbandes]

Adds version service at /ros/v/:distro/:packageName for ROS packages. Version information is loaded directly from the ros/rosdistro repo on GitHub, using tags to determine the latest available distribution, and then parsing the distribution.yaml file from that distribution.

I was hoping to make the :distro show up as the badge label in error cases, but it seems like when an error is thrown, only the defaultBadgeLabel (or 'version') is used as the label. And I would've happily used the raw.githubusercontent.com method of loading the distribution.yaml file, but it didn't seem like one service would be able to make both GraphQL requests and REST requests (when I tried to make a REST request, it still prepended the GraphQL endpoint's base URL). Any advice on these would be appreciated!

[shields-ci]

	Messages
📖	✨ Thanks for your contribution to Shields, @jtbandes!

Generated by 🚫 dangerJS against df1f059

[calebcartwright]

Thanks for opening a PR!

To the best of my knowledge, we don't have any open issues requesting this badge with the relevant details, so before we proceed it would be helpful for us if you could speak to some of the questions we ask in the issue template for new badges so that we've a sufficient amount of context (I've not heard of ROS myself)

I think the first several are implicitly covered already, so I've taken a pass at filling them in, but certainly feel free to correct.

• Which service is this badge for e.g: ROS (but more info/context about the nature of this service would be most appreciated)
• What sort of information should this badge show? standard version badge
• Is there a public API? No. The data is retrieved through a set of sequential API calls to GitHub to retrieve a yaml file which is then parsed and processed
• Does the API requires an API key? Not in the traditional sense
• Link to the API documentation. (anything that helps codify the schema or would otherwise be relevant)
• What is the specific use case?
• Who are the users of the service/target audience for the badge?

[jtbandes]

• Which service is this badge for: ROS is an ecosystem of robotics software and tools, organized into packages. It has wide adoption across both education and industry. See ROS community metrics, ROSCon. There are two major versions of ROS (ROS 1 and ROS 2) which are actively maintained (the last distro of ROS 1 will be EOL in 2025).
• Link to the API documentation. Some info about the rosdistro repo contents/structure is here:
  • https://github.com/ros-infrastructure/rosindex/blob/aedbdddaec60a66eb5be100909c14d941fff8027/about/design.md#official-index
  • https://ros.org/reps/rep-0141.html
• What is the specific use case? Who are the users of the service/target audience for the badge? I'm imagining that developers of ROS packages would use the version badges in their repo READMEs just like npm package developers do with npm version badges today. The version service is segmented by distro, because multiple ros distros are being maintained at the same time (ROS 1, ROS 2), and a different package version can be released in each distro. The service supports both ROS 1 & 2 because all of the distribution info is stored in the same repository. The target audience would be developers of robotics software who are browsing available packages (e.g. on GitHub) and could use version information at a glance.

I've also shared a link to this PR in the ROS Discourse to notify the maintainers and request any feedback they might have: https://discourse.ros.org/t/shields-io-badge-service/26379

[jtbandes]

Hi @calebcartwright, just to follow up on this, is there any more info I can provide?

[calebcartwright]

Hi @calebcartwright, just to follow up on this, is there any more info I can provide?

No, the info you've provided is great thanks! Someone should get around to reviewing this in the not too distant future

[chris48s]

Thanks for submitting this and including tests. It is looking in pretty good shape to start with and its clear you've worked through the documentation and contributing guidelines 👍

[chris48s]

For version badges, the label is usually the name of the package registry, as opposed to the package.

I think we do want to include ros in the label. With the conda badges, we include the channel in the label separated by a pipe. How about we do similar here - ros|distro e.g:

[jtbandes]

Ok, makes sense. What do you think about including spaces around the pipe? Like this: I think it makes it more readable.

[chris48s]

Yeah agreed 👍 Change it on this PR and I will do another PR to update the conda one.

[jtbandes]

done!

[chris48s]

I was hoping to make the :distro show up as the badge label in error cases, but it seems like when an error is thrown, only the defaultBadgeLabel (or 'version') is used as the label

This is normal - I wouldn't worry about it. We probably should set the defaultBadgeLabel to 'ros' though.

I would've happily used the raw.githubusercontent.com method of loading the distribution.yaml file, but it didn't seem like one service would be able to make both GraphQL requests and REST requests

We could find a way to do this, but tbh I think the approach you've already used of doing both queries using GraphQL is fine and maybe the neatest solution anyway. I don't think we need to change it

[chris48s]

LGTM