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
Target audience
-
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
Further details
Proposal
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 )
Links / references
This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.