ABI/API Compliance Checker in github workflow

Hi ROS users and developers,

i would like to open discussion and have feedback from community.

Problem

  • Development and Operation Burden: maintainer and developer burden to check ABI compatibility for backport.
  • Quality: we sometimes miss backporting for released distribution unless requested. (bug fixes basically should be backported to available distribution to keep the consistent quality for all supported distribution.)

Proposal

Integrate ABI/API compliance checker in github workflow to check ABI compatibility for every PR to see if the fix can be backported automatically with label.

What’s in it for us?

  • User: Quality Improvement, potentially all bug fixes that ABI compatible with can backport to already released distribution.
  • Developer/Maintainer: Cost Effective, automatically determine if the fix is backport-able for already released distribution. (automatically labeled.)

Comments and feedbacks are welcome!!! Please share your thoughts!

Best,
Tomoya

6 Likes

Great idea! I have always wondered how to check ABI compatibility so if somebody can produce an example package that demonstrates how to incorporate this into a ROS2/cmake workflow, that would be awesome. I’d definitely use it.

Is this going to be just for rclcpp for now, or are you planning on making this accessible to all ros packages, maybe by providing an ABI check via action-ros-ci?

1 Like

industrual_ci offers ABI checks as used e.g. by ros2_control.

1 Like

I was originally thinking that rclcpp for 1st trial, but that would be better if they can accept this kind of feature.

industrual_ci offers ABI checks as used e.g. by ros2_control .

@fmauch i was hoping this kind of feature is already available somewhere! thanks! i am not sure if we can just rely on this CI with github workflow, but definitely look into this.

I’d love a github action for this - it would take out some of the ambiguity when I’m doing backports for syncing to released distributions in Nav2. Even if it just tags which could be backported, that would be a big acceleration in the release process. If it automatically triggered the backports for distributions that it was API/ABI compatible for, that would be even greater!

The only thing that wouldn’t immediately solve is what happens when a PR itself isn’t ABI/API breaking, but depends on previous work that was and thus not backported. I assume the crazy merge conflicts would make that clear in the ensuing PR - but if it could detect that as well (depends on a change from main that wasn’t backportable), that would let us basically completely automate the mainhumble, iron, jazzy syncs in big projects like Nav2! But that’s probably out of scope, just something that I run into as well when I’m backporting for release syncs.

1 Like

ABI/API compliance checker is required for us indeed.

That’s a good idea!