Incorporating ABI compatibility checks in CI pipelines of core ROS 2 packages.
REP-0009 “ABI compatibility” requires that, on a “best effort” basis, ABI compatibility be maintained for even-cycle patch releases of the public facing API of a package.
While the PR review process, developer guide, and manual ABI compatibility checking cover most bases, I believe being able to automate this process provides ease-of-mind value to authors, maintainers, and reviewers of the C/C++ libraries within the ROS 2 core. Having ABI compatibility results between a suggested patch and its targeted base available in the CI pipeline could even help in discussing designs that are (more) easily backportable - an issue I’ve seen quite a few non-trivial PRs in
Also, why do the check yourself when a computer can do it instead!
Essentially, the package needs to be built twice, once with the changes in the current HEAD reference, and once with the base said PR is targeting. The two build artifacts representing the respective library ELF binaries can then be supplied to an ABI compatibility checker. One tool to facilitate this proposal would be RedHat’s
I recognize that this is not particularly high priority given the frequency of ABI compatibility issues within core ROS 2 packages, but I’d still like to hear others’ thoughts on augmenting the ROS 2 developer experience like this.
Are there any latent pros/cons of this proposal which weren’t considered here?
Is this something anyone has tried to do with their own ROS packages/libraries?
Is it worth the churn given that it isn’t a particularly low-hanging fruit?
(If this isn’t the right place to have this discussion, feel free to redirect!)