"bom map" only prints an error, but doesn't exit with failure on internal mapping issue

[gernot-h]

In one SW360 instance, we have a release with a somehow invalid version number "libffi 3.4.4._ME-1". This can't be parsed and leads to an error message during "bom map":

CaPyCli, 2.6.0 - Map a given SBOM to data on SW360

Loading SBOM file ../distro-clearing-alpine/issue193-bom.json
  Analyzing token...
  Token will expire on 2025-03-02 12:33:33
  Checking access to SW360...
No cached releases available!

Do mapping...
[...]
  libc-dev, 0.7.2-r5.alpine
    Found component 5ed9713fcf264070b9c5a0210cb56264 via purl
  libedit, 20230828.3.1-r3.alpine
    Found component bc75c910ca9866886cb4d7b3a30150aa via purl
  libffi, 3.4.4-r3.alpine
Unable to parse version 3.4.4._ME-1
    Error mapping SBOM item: AttributeError("'ComparableVersion' object has no attribute 'parts'")
  libgcrypt, 1.10.3-r0.alpine
    Found component 184653f661036675f8006a0d610027c8 via purl
  libgpg-error, 1.47-r2.alpine
    Found component 184653f661036675f8006a0d61003b73 via purl
[...]

Mapping result:
[...]
  Full match by id, libc-dev, 0.7.2-r5.alpine => Alpine libc-dev, 0.7.2-r5.alpine, 0d0917631bb2482ca430db5a2bcbf77a
  Full match by id, libedit, 20230828.3.1-r3.alpine => libedit, 20230828.3.1-r3.alpine, 452eee928932470cb47d8d960f45a9f6
  Full match by id, libgcrypt, 1.10.3-r0.alpine => libgcrypt, 1.10.3-r0.alpine, 50828e14cfba43f8b3052c88b576897e
  Full match by id, libgpg-error, 1.47-r2.alpine => libgpg-error, 1.47-r2.alpine, b1cd886da5fb4cf1b3dbc1db679664ea
[...]
Total releases    = 40
  Full matches    = 40
  Name matches    = 0
  Similar matches = 0
  No match        = 0

Writing updated SBOM to test-out.json

So the user is informed with a yellow "Error" message somewhere in the long output, but it's not mentioned in the summary at the end, CaPyCli will finish with exit code 0. And even worse, the component will be missing completely from test-out.json.

Basically, https://github.com/sw360/capycli/blob/v2.6.0/capycli/common/comparable_version.py#L33 will consume the exception, print the error and then forget about it.

As we often map large SBOMs in CI, this error in the longish output can easily go unnoticed (and did for us, for about 3 months, affecting a couple of projects).

This is not about just fixing the error in the version string parsing (I will create a separate issue/PR for this), but I'd like to improve the error handling here. Some ideas:

• Bail out with an error message immediately if we see an exception.
• Remember the error and set exit code at the end.
• At least assure that the component stays in the output BOM.

What do you think, @tngraf?

[tngraf]

I see the problem.

Feedback on you ideas:

• Bail out with an error message immediately if we see an exception.
  => not recommended: it is hard to predict what happens. There might be too many users and too many uses-cases,
  where the exception should not stop the whole process.
• Remember the error and set exit code at the end.
  => 👍
• At least assure that the component stays in the output BOM.
  => 👍

[tngraf]

@gernot-h I need more information to reproduce the issue...