Fix: Component get deleted in update for Internal Vuln

[Gepardgame]

Description

Now you can update a internal Vulnerability without getting the affected components deleted.

Addressed Issue

Fixes #4175

Additional Details

N/A

Checklist

• I have read and understand the contributing guidelines
• This PR fixes a defect, and I have provided tests to verify that the fix is effective
  - [ ] This PR implements an enhancement, and I have provided tests to verify that it works as intended
  - [ ] This PR introduces changes to the database model, and I have added corresponding update logic
  - [ ] This PR introduces new or alters existing behavior, and I have updated the documentation accordingly

[Gepardgame]

Again only trivy tests failed.

Is there a way of caching the docker container on the machine which runs the workflow? This would help with not always pulling the image for every test run

[codacy-production]

Coverage summary from Codacy

See diff coverage on Codacy

Coverage variation	Diff coverage
Report missing for 8c7d5a91	✅ 100.00% (target: 70.00%)

Coverage variation details

	Coverable lines	Covered lines	Coverage
Common ancestor commit (8c7d5a9)	Report Missing	Report Missing	Report Missing
Head commit (95053f4)	22353	17668	79.04%

Coverage variation is the difference between the coverage for the head and common ancestor commits of the pull request branch: <coverage of head commit> - <coverage of common ancestor commit>

Diff coverage details

	Coverable lines	Covered lines	Diff coverage
Pull request (#4193)	2	2	100.00%

Diff coverage is the percentage of lines that are covered by tests out of the coverable lines that the pull request added or modified: <covered lines added or modified>/<coverable lines added or modified> * 100%

See your quality gate settings    Change summary preferences

_{Codacy stopped sending the deprecated coverage status on June 5th, 2024. Learn more}

Footnotes

1. Codacy didn't receive coverage data for the commit, or there was an error processing the received data. Check your integration for errors and validate that your coverage setup is correct. ↩

[nscuro]

Thanks @Gepardgame! Could you please add a test to VulnerabilityResourceTest that verifies the desired behavior?

[Gepardgame]

I am currently working on it, but have a issue, cause I cannot run the test, cause the Test class starts like this:
@RunWith(Suite.class) @SuiteClasses(VulnerabilityQueryManagerTest.SynchronizeVulnerabilityAliasTest.class) public class VulnerabilityQueryManagerTest extends PersistenceCapableTest {
I want to add this test normally to the class, but that doesn't work quit out. @nscuro Do you know how to fix that?

[nscuro]

I suggest adding a test to VulnerabilityResourceTest instead, because performing the update via REST API covers the entire use-case and thus gives more assurance than a narrowly-scoped unit test in VulnerabilityQueryManagerTest.

[Gepardgame]

I found a bug in my implementation, but I don't have time anymore today to fix it. I'm sorry, but will do it tomorrow.

[nscuro]

No problem @Gepardgame, we can release tomorrow, too.

Worst case I can pick it up, in that case please let me know what bug you found.

[Gepardgame]

The bug is that the affectedComponents get duplicated, but without the AffectedVersionAttribution. The original is the same with the AffectedVersionAttribution. In the gui you don't see it, cause it only shows, if there is a AffectedVersionAttribution, but in the spi directly you can see it.

[nscuro]

Thanks, I might take this over then later today. Thanks for working on it!

[Gepardgame]

Thanks. No Problem.

Should I upload the test? It does not work yet, but then you don't need to start from scratch for that.

[nscuro]

Superseded by #4208