Repository navigation
ABI/API Compliance Checker in github workflow #2555
Description
Feature request
Feature description
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.
Background
In principle, all bug fixes should be backported to the supported downstream distributions, precisely because they are fixes. Today, however, this backport decision and process depends entirely on the maintainer's manual effort and judgment, so it happens on a need-to-do or requested basis rather than automatically and systematically. (we can find comments requesting or asking for the backport to released distribution.)
One of the key blockers is that it is not always easy to tell whether a fix is ABI compatible with the released distributions. Currently, for every PR, we (developers and maintainers) check the ABI compatibility by looking at the source code, but sometimes it is hard to tell for sure, and this depends on the developer's skill and experience. (I personally run ABI compliance checker to make sure for this.)
We can also see cases where community developers hit a problem on a released distribution, spend time debugging it down to the root cause, and only then discover that the fix already exists on the rolling/development branch but was never backported. They then have to request the backport themselves. This is a waste of effort for everyone involved.
To avoid this burden and keep the high quality of ROS distributions, it would be nice to have an ABI compliance checker automatically run against every PR, so that we can know whether the fix is ABI compatible via a tag or label provided by the workflow. Making this process more automatic and systematic would save significant time for maintainers, developers, and users alike.
Note
This ABI Compatible or Backport-able tag is an additional information for maintainers, says this does not mean we have to backport the fix to already released distros.
Although ABI is compatible, different behavior or significant different user-experience should be avoided breaking the user space.
https://github.com/ros-industrial/industrial_ci/tree/masterv and https://github.com/osrf/auto-abi-checker/tree/master are similar approach against this issue, but they use https://github.com/lvc/abi-compliance-checker that is out dated for a long time. i would suggest we can rely on https://sourceware.org/libabigail/ that looks well maintained and supported.
Implementation considerations
- we can integrate https://sourceware.org/libabigail/ to github workflow. (or any other tools or recommendation?)
- build target branch and PR branch or repo to check the ABI compatibility for every commits.
- new label
ABI compatibleneeds to be introduced and tagged by workflow.
I am creating this issue on rclcpp (because that is where i can find this situation most.) but the following core repositories can have the same ABI checker CI.
- https://github.com/ros2/rcl.git
- https://github.com/ros2/rcl_logging.git
- https://github.com/ros2/rcpputils.git
- https://github.com/ros2/rcutils.git
- https://github.com/ros2/rmw.git
- https://github.com/ros2/rmw_connextdds.git
- https://github.com/ros2/rmw_cyclonedds.git
- https://github.com/ros2/rmw_dds_common.git
- https://github.com/ros2/rmw_fastrtps.git
- https://github.com/ros2/rmw_implementation.git
- https://github.com/ros2/rosbag2.git
flowchart TD
A[PR / Every Commit] -->|workflow| B[ABI Compliance Check]
B --> C{ABI Compatible?}
C -->|Yes| D[Tag / Label]
D --> E[Code Review]
C -->|No / Not Required| E[Code Review / Approval]
C -->|ABI Compatible Required?| A[PR / Every Commit]
E -->|Mergifyio| F[Backport Process]
after all, i think this will do some good for ROS users, developers and maintainers to accelerate the development process and ROS quality.
Tomoya,
Activity
ros-discourse commentedon Jun 8, 2024
This issue has been mentioned on ROS Discourse. There might be relevant details there:
https://discourse.ros.org/t/abi-api-compliance-checker-in-github-workflow/38141/1
clalancette commentedon Jun 11, 2024
I think that this is a good idea, though we'll have to be careful with it. In particular, in
rollingwe allow ABI breaks at any time, while the released distributions don't allow ABI breaks. We'll have to have configuration for that.In addition, we have some ABI testing already available on the ROS buildfarm, though we haven't tested or enabled it since Galactic. In particular, on your rosdistro repositories, you can add
test_abi: true, which will do...something (see https://github.com/ros/rosdistro/blob/73d2581901d80429f1c9e371d2bf5de500d1d7dd/foxy/distribution.yaml#L4628). So I think we should start by seeing what happens if we enable that (also, maybe @j-rivero , @nuclearsandwich , or @cottsay can shed some light on what that does, if anything).fujitatomoya commentedon May 29, 2026
https://github.com/ros-industrial/industrial_ci/tree/masterv and https://github.com/osrf/auto-abi-checker/tree/master are similar approach against this issue, but they use https://github.com/lvc/abi-compliance-checker that is out dated for a long time. i would suggest we can rely on https://sourceware.org/libabigail/ that looks well maintained and supported.
fujitatomoya commentedon Aug 16, 2026
i have developed PoC actions,
see how it works,
more verification is required.
Add backport candidate labels from the ABI verdict (#2555)
fujitatomoya commentedon Oct 14, 2026
development log.
the abi compliance checker is now online for rolling, the followings are the related PRs.
Note
if we want to backport the action to detect ABI compliance, we need to backport the above PR except tagging the backport labeling.
Add backport candidate labels from the ABI verdict (#2555)
Add backport candidate labels from the ABI verdict (#2555) (#3341)