You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Chainloop control plane has a mechanism to forward received DSSE attestation envelopes or SBOMs to different backends, i.e OCI registry or Dependency-Track.
This means that conceptually both OCI registries and SBOM processors are at the same level, third party fan out integrations, but reality is that the implementation grew in a different manner.
Because of historical development reasons, currently, an OCI repository is mapped as its own identity in both the database and business logic.
while dependency track integration makes use of a generic "integration" model meant to encapsulate different processors.
This command will, however, update the Chainloop backend service database and may affect other users in the org/project. This may break some pipelines because if you have more than one org, you might accidentally update the OCI registry you did not intend.
Activity
danlishka commentedon May 11, 2023
+1 for moving OCI registries to integrations.
How we add or update the OCI registries today might be confusing. I will explain why.
There are two related commands in the CLI:
The config one is about the CLI setup, so as an end user, I assume this is only about local changes.
Now let's take a look at this example:
This command will, however, update the Chainloop backend service database and may affect other users in the org/project. This may break some pipelines because if you have more than one org, you might accidentally update the OCI registry you did not intend.
I think OCI registries belong to integrations.
migmartri commentedon Jun 15, 2023
This issue might not be needed in the end. A different approach is described here #179