## Background The current CI Catalog is designed to work with component projects (including templates and steps) and the publishing process hooks into the release creation to extract metadata for each component. ## Opportunities We would like the CI Catalog to be a catalog of things in GitLab, supporting packages, container images, and even generic resources like services. The catalog can be the place where an organization can share any resources related to their DevSecOps lifecycle, as well as using and contributing to resources from the wider community. ## Requirements - We need to be able to display other types of resources in the catalog aside from the current component projects (e.g. container images). - Each resource type may have additional metadata (for example, inputs for each component in a component repo) that should be provided during the publishing process rather than collected server-side. The catalog lists resources. A resource is a publishable unit that is also versionable. Today we publish component projects in the catalog as the only resource type. We want to be able to support multiple types of resources: ```mermaid flowchart TD cr[Catalog] --shows--> cp[Components project] --contains--> tc[Template components] cp --contains--> sc[Step components] cr --shows--> ci[Container image] cr --shows--> p[Package] cr --shows--> mm[ML model] ``` ## Proposal * Change the publishing process not to be strictly coupled to the release creation process. First the user need to create the "publishable version" and then publish it in the catalog. * For component projects the release is created first (the publishable version) and then published to the catalog. * For container images the image is pushed to the container registry with a version (the publishable version) and then published to the catalog. * This allows users to choose what version to publish in the catalog. Users may not want to publish every version of a resource and choose to only publish the stable ones. * Also allows the user to know whether the specific publish action succeeded or failed. * Introduce an explicit `resource_type` to be able to distinguish between the various types (component project, container image, etc.). * Each type may have a schema that must be followed when providing parameters for publishing a new version. Example: component project can have multiple components each with their own metadata, inputs, etc. A package may contain other metadata. ## Iterations 1. Create a PoC with the goal of demonstrating how we could use the same method to publish component projects as well as container images. 2. Create a dedicated REST endpoint for publishing resources. 3. Create a client-side tool that facilitates the publishing process (glab command, step component, etc.) 1. For the existing component project we could also extend the `release-cli` to first create the release and then publish the version.