### Proposal When code is committed to an MR, a CI pipeline is fired. The idea is to follow the same logic but with packages: * When a package is pushed to a GitLab Package Registry, a CI pipeline is fired. * (option) The package is available for pulling only if the CI pipeline passed. * Users could add different type of jobs on the pipeline. * The first that comes to mind is https://gitlab.com/gitlab-com/gl-security/security-research/package-hunter The idea of having different jobs for checking and scanning the package is interesting. It could unlock some features such as: * Scan the package metadata history and hunt suspicious changes. * Others? What I like with this approach is that by re-using the CI pipeline "object" we got a lot of things (almost) for free: from UI widgets for the CI pipeline status to user notifications from the pipeline (eg. email sent in case of a pipeline failure). In the ideal situation, we should be able to link a pipeline to a package without needing a commit. I also like how it could cascade events: 1. A user creates an MR for the source code of a package 1. MR merged, master is updated 1. Project owner creates a new version and kicks a new CI pipeline 1. This CI pipeline (on the source code) can have a deploy phase that will build the package and push it to the GitLab package registry. 1. This in turn will kick a second CI pipeline (on the package artifact). 1. Once this second CI pipeline is :green_heart:, the package is available for pulling. <!-- 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.* ### Priorities In phase 1 we will tackle the below three formats first because we expect that working with formats that output only one file will be easier than working with formats with multiple files. Phase 1: 1. npm 2. generic packages 3. NuGet Phase 2: (formats with multiple files or other complicating factors) 1. Maven 2. PyPI 3. Terraform ## Owners * Team: [Package Registry](https://about.gitlab.com/handbook/engineering/development/ops/package/package-registry/) * Most appropriate slack channel to reach out to: `#g_package-registry` * Best individual to reach out to: @10io * PM: @trizzi * EM: @ckroutil <!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION -->