We use abi-compliance-checker (acc) to create reports for the ABI compliance.
This scripts uses the current git hash and searches for the oldest
available library version with the same SONAME to check against.
acc creates reports at:
compat_reports/{libname}/{v1}_to_{v2}/compat_report.html
Details
- Reviewers
bcooksley - Maniphest Tasks
- T3689: Add abi compliance checker to CI
- Commits
- R857:ee33ecb40bf9: Add script to check the ABI of the created libraries.
Diff Detail
- Repository
- R857 CI System Tooling
- Lint
No Linters Available - Unit
No Unit Test Coverage - Build Status
Buildable 4584 Build 4602: arc lint + arc unit
helpers/check-abi.py | ||
---|---|---|
84 | That change has now been landed. |
- run for all libraries, do not stop at first failure.
- safe comapt_reports to a place where it is accessible by jenkins for artifacts.
- cleanup script.
helpers/check-abi.py | ||
---|---|---|
94 | https://build-artifacts.kde.org/production/ABIReference/ still has .tar files (not cleaned up), so I need still to create the the symlinks) |
than we have no blockers anymore.
@bcooksley: than you can review it more closely as it is ready from my side.
Sure thing.
Have you had any thoughts on how to best split by branch? The path of least resistance would be to use the branchGroup when storing and doing lookups.
helpers/check-abi.py | ||
---|---|---|
51 | This tool is designed to run after the ABI information capture script I assume? | |
57 | Any ideas on how to solve this issue? Wouldn't one possibility be to only capture ABI reference data from a special job that focuses on building the released version of software being tracked by this? | |
64 | whant -> want | |
66 | interessed -> interested | |
69 | Won't this cause a KeyError because while referenceLibraries[libname] will exist (due to the code on line 59, assuming I understand that correctly), the key underneath it doesn't seem to have been populated? (unless i'm missing something of course) |
After thinking more about it I implement the whole logic different.
The check-abi script searches for all included released versions ( git tag --contains $scmRevision) . The best candidate is the oldest released version of the library and falls back to the oldest commit.
The new class Versions helps sorting the versions correctly. If you know already available class I can switch to it.
For the version parser, could you comment the various functions to explain what the various bits of the functions are trying to accomplish?
(For easier reading later on)
helpers/check-abi.py | ||
---|---|---|
82 | Sorry, missed this on my earlier review - you can't rely on the output of git branch to tell you which branch we've checked out. You'll want to read the same branchGroup parameter the other scripts rely on. |
One last thing, otherwise this looks good to go to me.
helpers/check-abi.py | ||
---|---|---|
124 | I would suggest simply comparing arguments.branchGroup against the entry['branchGroup'] here in case we end up adding a third branch group at some point. |
helpers/check-abi.py | ||
---|---|---|
124 | You mean: if stableBuild and entry["branchGroup"] != arguments.branchGroup : |