Hello, Staging is now capable of writing out an ABI description when the appropriate tool (abi-dumper) is available.
We now have to possible courses of action for ABI checking in builds. 1) Publish the ABI descriptions on xenbits, update all downstream test systems to invoke abi-compliance-checker manually. 2) Commit/update the ABI descriptions when RELEASE-$X.$Y.0 is tagged, update the main build to use abi-compliance-checker when available. Pros/Cons: The ABI descriptions claim to be sensitive to toolchain in use. I don't know how true this is in practice. Publishing on xenbits involves obtaining even more misc artefacts during the build, which is going to be firm -2 from downstreams. Committing the ABI descriptions lets abi checking work in developer builds (with suitable tools installed). It also means we get checking "for free" in Gitlab CI and OSSTest without custom logic. Thoughts on which approach is better? I'm leaning in favour of option 2 because it allows for consumption by developers and test systems. If we do go with route 2, I was thinking of adding a `make check` hierarchy. Longer term, this can be used to queue up other unit tests which can be run from within the build tree. ~Andrew