Merge OCI-repositories and Integration models

[migmartri]

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.

type Integration struct {
	ent.Schema
}

func (Integration) Fields() []ent.Field {
	return []ent.Field{
		field.UUID("id", uuid.UUID{}).Default(uuid.New).Unique().Immutable(),
		field.String("kind").Immutable(),
		field.String("secret_name").Immutable(),
		field.Time("created_at").
			Default(time.Now).
			Immutable().
			Annotations(&entsql.Annotation{Default: "CURRENT_TIMESTAMP"}),
		// kind specific config
		field.Bytes("config").GoType(&pb.IntegrationConfig{}),
		field.Time("deleted_at").Optional(),
	}
}

func (Integration) Edges() []ent.Edge {
	return []ent.Edge{
		edge.From("attachments", IntegrationAttachment.Type).Ref("integration"),
		edge.From("organization", Organization.Type).Ref("integrations").Unique().Required(),
	}
}

both of them belongs to an organization and get attached to different workflows. The only difference is that having a valid OCI registry is mandatory

This issue is about making the OCI repository feature part of the more generic "integrations" feature for consistency.

[danlishka]

+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:

  - config       Configure this client
  - integration  Third party integrations

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:

$ chainloop config set-oci-repo --username danlishka --password <secret> --repo ghcr.io/danlishka/chainloop-test-lab

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]

This issue might not be needed in the end. A different approach is described here #179