CI pipeline for packages
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.
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:
- A user creates an MR for the source code of a package
- MR merged, master is updated
- Project owner creates a new version and kicks a new CI pipeline
- 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.
- This in turn will kick a second CI pipeline (on the package artifact).
- Once this second CI pipeline is
💚, the package is available for pulling.
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.