fix: remove fallback logic for Source Code Download URL

[meAndreea]

• Remove incorrect fallback that used repository/website URLs as sourceCodeDownloadurl
• Add logic to update Component VCS field instead (commented pending SW360 Issue 1886)
• Add proper error handling with colored output
• Update tests: remove sourceCodeDownloadurl expectation, skip failing test

This prevents incorrect data in SW360 by keeping source download URLs
and VCS repository URLs separate.

Also, when the incorrect URL for downloading the source code is present in sw360 for a release the capycli findsources command will not try to correct it. Only checks if accessible. An output observed would be an inactive archive in attachments

[gernot-h]

@meAndreea, thanks for your contribution! As this is a rather big change, it's a bit hard to review, so please give us some time. What I don't understand yet, are all these changes intrinsically tied together? If not, I would prefer to have them in separate commits, but I'll try to have a look at it as-is.

[gernot-h]

please refer to the public issue here: eclipse-sw360/sw360-frontend#1357.

[meAndreea]

@gernot-h i removed this, not updating the vcs/repo of the corresponding Component for the sw360 Release that is preparing.

[gernot-h]

Same here, please refer to eclipse-sw360/sw360-frontend#1357.

[meAndreea]

@gernot-h i removed this as well

[gernot-h]

So, do I get your idea right, @meAndreea, that when creating a new release and we don't have a sourceCodeDownloadUrl, you didn't remove the fallback logic as your commit message suggests, but instead changed it to retrieve the component data from SW360 and use the website or VCS URL from there?

Can you please elaborate why you consider the existing fallback logic as "incorrect" and what's the advantage of your new code? I guess there's a concrete use case or scenario behind this change?

In future, if you plan such changes, it would probably be best you start by creating an issue and describe your idea so we can align on it before we dive into actual code.

Also, it seems you did a larger refactoring of existing test cases adding a new logging capture pattern which should definitely be split into a different commit (and for the future, ideally also a different issue or PR), but for now, can you also elaborate on this one here? Especially, I'm confused why the existing capsys capturing wasn't enough - note that we don't use logging but the existing messages just go to stdout/err.

[meAndreea]

@gernot-h the initial functionality, if there was no sourceDownloadURL in the input BOM file, then it was populating the value with a repository URL or website URL. These fallback values were not a URL to an actual archive containing sources for the release. Now with the changes from this PR, data["sourceCodeDownloadurl"] is not populated with values of repo, or website from the input BOM file.

The advantage of not populating the property is that, in case later, a findsources command is used, it will try to find a possible archive with sources for this release. In case there is already something set in the sourceDownloadURL it will skip this part completely and directly try to download the archive from the fallback url.

For example, a valid archive with sources could not be valid at the url below for a release version for aws-sdk-java-v2

In the given example, with the previous code the attachment looked like this:

[meAndreea]

I reverted the changes done in the test, maybe some other time and with a different PR as you suggested. I get it that is easier this way to analyze the changes. I will keep this in mind if there will be next contributions :)