### Release notes A GitLab Release is a snapshot of the source, build output, artifacts, and other metadata associated with a released version of your code. This has worked great for your source code and artifacts, but you've been manually adding your packages using the [Release Links API](https://docs.gitlab.com/ee/api/releases/links.html#create-a-link). At GitLab, we try to help you avoid repetitive, manual tasks. So, moving forward any packages in your registry that are tagged with a given Release will automatically be associated with that release. ### Problem to solve When you create a release: - GitLab automatically archives source code and associates it with the release. - GitLab automatically creates a JSON file that lists everything in the release, so you can compare and audit releases. This file is called release evidence. - You can add release notes and a message for the tag associated with the release. That's great, but packages are not automatically associated with a Release. This means that it has to be done manually or via a pipeline and using the [GitLab Release Links API](https://docs.gitlab.com/ee/api/releases/links.html#create-a-link). ### Proposal When Release evidence is generated, it should associate any packages tagged with a Release with that Release. They should be visible in both the UI or by using the Releases API to view release evidence. ### Documentation - https://docs.gitlab.com/ee/user/project/releases/index.html#release-evidence - https://docs.gitlab.com/ee/api/releases/index.html#collect-release-evidence - https://docs.gitlab.com/ee/api/releases/links.html#create-a-link ### Availability & Testing This section needs to be retained and filled in during the workflow planning breakdown phase of this feature proposal, if not earlier. What risks does this change pose to our availability? How might it affect the quality of the product? What additional test coverage or changes to tests will be needed? Will it require cross-browser testing? Please list the test areas (unit, integration and end-to-end) that needs to be added or updated to ensure that this feature will work as intended. Please use the list below as guidance. * Unit test changes * Integration test changes * End-to-end test change See the test engineering planning process and reach out to your counterpart Software Engineer in Test for assistance: https://about.gitlab.com/handbook/engineering/quality/test-engineering/#test-planning ### What does success look like, and how can we measure that? Success looks like the increased adoption of both the Package Registry and Releases. We can measure this by looking at: - The number of releases created - The number of releases with packages created - The number of packages published ### Is this a cross-stage feature? Yes. Release + Package <!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION --> *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.* <!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION -->