The current output is like this. printing the output of the yaml is only one solution, properly not the best.
output for one library. For better unterstanding how output looks like:
INFO:root:Do an ABI check for KF5MessageCore INFO:root:Found tag 18.12.0(5502593170fe472b9b6d65fc39102d7df6da32bc) to check against. INFO:root:check 5502593170fe472b9b6d65fc39102d7df6da32bc(old) -> 7d2469af386e084d38748b8223289daa62e92125(new) DEBUG:root:abi-compliance-checker -report-path compat_reports/KF5MessageCore_compat_report.html -l KF5MessageCore --old /mnt/archives/production/ABIReference/KF5MessageCore_5502593170fe472b9b6d65fc39 102d7df6da32bc_SUSEQt5.10.abidump --new /mnt/archives/production/ABIReference/KF5MessageCore_7d2469af386e084d38748b8223289daa62e92125_SUSEQt5.10.abidump WARNING:root:abi-compliance-checker exited with 1: Preparing, please wait ... Comparing ABIs ... Comparing APIs ... Creating compatibility report ... Binary compatibility: 100% Source compatibility: 100% Total binary compatibility problems: 0, warnings: 0 Total source compatibility problems: 0, warnings: 0 Report: compat_reports/KF5MessageComposer_compat_report.html ---YAML START--- binaryCompability: 99.8 compability: false error: 1 libname: KF5MessageCore otherCommit: 5502593170fe472b9b6d65fc39102d7df6da32bc reportPath: compat_reports/KF5MessageCore_compat_report.html sourceCompability: 99.97 tag: 18.12.0 ---YAML END---
See above comments. One thing I'm not sure of is where you're intending to use the YAML output?
Which programs output are we parsing here?
Some comments indicating what details we're going to extract from the output would also be nice for future reference.
Code Style: 'binaryCompatibility' should start on it's own line (so it lines up with sourceCompatibility)
Code Style: Same as above.
Well programmers want to use the YAML output to look if their libraries are compatibile or not within the new version. Me personally as pim release manager it is the way for me to see, what libraries I should bump.
The printout into stdout was the easiest solution for me to consume the data, but it is definitively not the way to go. Publish it at build-artifacts seems a good idea for me, but build-artifacts, but updating the metadata for the package is not possible, right? So we would need another directory. Or we attach this yml as artifacts attached to the build.
Yes, updating the metadata for a package that has been uploaded already to build-artifacts.kde.org is not possible.
In this case, capturing the YAML file (with an appropriate name, like abi-compatibility-results.yaml perhaps) as a build artifact is probably the best solution.