Artifact release meta-data
Problem to solve
A release often incorporates multiple underlying packages and services. These could be composed of upstream pipelines, which are publishing a particular package, library, or container. They could also be composed of other public dependencies, like: a base image, published packages, official container, a helm chart, etc.
When a final release is being evaluated, we should be able to present users with a few key data points:
- What underlying packages/containers the release incorporates and depends on
- The changelogs of each underlying dependency, if they are changing
- The security scan results of those dependencies
- The license compliance of those dependencies
This is important for a few reasons:
- To present a comprehensive Bill of Materials (BOM), which includes underlying components
- To assist reviewers of the final release to understand the impact across security, compliance, risk
Parker, Product Manager, https://design.gitlab.com/research/personas#persona-parker
Delaney, Development Team Lead, https://design.gitlab.com/research/personas#persona-delaney
Sasha, Software Developer, https://design.gitlab.com/research/personas#persona-sasha
Devon, DevOps Engineer, https://design.gitlab.com/research/personas#persona-devon
When a release is generated for a package or container, we should attach metadata to that release:
- The changelog to document what has changed
- The security posture (quantity of high/medium/low, etc.)
- The license compliance and type (e.g. Apache 2.0 but includes license violations)
- Any underlying dependencies that are included, and links to their metadata
This way when that artifact is consumed by a downstream project, the provenance and state is clear.
Then for a given release, we could show a view of what is contained within as well as generate a portion of the changelog. This is important for customers who may be doing frequent releases with upstream projects, to understand 'what is in this release`?
What does success look like, and how can we measure that?
What is the type of buyer?
(Which leads to: in which enterprise tier should this feature go see https://about.gitlab.com/handbook/product/pricing/#four-tiers )