On 22/02/2021 14:37, Jan Beulich wrote: > On 22.02.2021 15:03, Andrew Cooper wrote: >> 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. > +1 for option 2, fwiw. > >> 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. > Is there a reason the normal build process can't be made fail in > case verification fails? Besides "make check" typically meaning to > invoke a functional testsuite rather than (just) some compatibility > checking, I'd also be worried of no-one (likely including me) to > remember to separately run "make check" at appropriate times.
As far as RPM is concerned, splitting the two is important, as %build and %check are explicitly separate steps. I have no idea what the deb policy/organisation is here. Merging some of check into build would be a layering violation, and even if we did so, where do you draw the line? ~Andrew
