`SBOM` accessory that is replicated over from another registry is not deleted after triggering SBOM manual generation
zyyw opened this issue · comments
How to reproduce?
- deploy two harbor instances: harbor1 and harbor2
- push image1 to harbor1; generate SBOM for image1
- create a push-based replication from harbor1 to harbor2 to replicate image1 (located on harbor1) and its SBOM accessory to harbor2
- we can see that the image1 and its SBOM accessory are replicated to harbor2 (image1, sbom1 harbor1 -> image2, sbom2 harbor2). However, if we trigger a SBOM generate manually for the image2 (which is the image1 on harbor1 replicated to harbor2), we can see that in addition to sbom2 being associated to image2, a new SBOM (sbom3) is associated to image2. So there are in total of 2 SBOM accessories (sbom2 & sbom3) associated to image2. Should sbom2 be replace by sbom3?
![Screenshot 2024-05-28 at 3 00 43 PM](https://private-user-images.githubusercontent.com/6709992/334302432-f3153a09-877c-4d85-b81d-149920ab9f8b.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MjIwMjgyODcsIm5iZiI6MTcyMjAyNzk4NywicGF0aCI6Ii82NzA5OTkyLzMzNDMwMjQzMi1mMzE1M2EwOS04NzdjLTRkODUtYjgxZC0xNDk5MjBhYjlmOGIucG5nP1gtQW16LUFsZ29yaXRobT1BV1M0LUhNQUMtU0hBMjU2JlgtQW16LUNyZWRlbnRpYWw9QUtJQVZDT0RZTFNBNTNQUUs0WkElMkYyMDI0MDcyNiUyRnVzLWVhc3QtMSUyRnMzJTJGYXdzNF9yZXF1ZXN0JlgtQW16LURhdGU9MjAyNDA3MjZUMjEwNjI3WiZYLUFtei1FeHBpcmVzPTMwMCZYLUFtei1TaWduYXR1cmU9MTYzYTNkY2M4YThhOGRmNGFhNWFiOGI5ZTJkNzIwZjg3YjkxMjIwNDMzYzQzNWNhOGQ3NTY0MWZhYjZiNTIwZSZYLUFtei1TaWduZWRIZWFkZXJzPWhvc3QmYWN0b3JfaWQ9MCZrZXlfaWQ9MCZyZXBvX2lkPTAifQ.ChPZcJ7p8Ut0n-f2hxF2e5FbmCroFgplp1Fh283-UjE)
According to our discussion in design stage, Ui will Use the first item in the accessories list. i think the order of item in the list returned fro the backend does not correct. we should always put the latest one in the first item of the list.