Code, den mehrere Anwendungen gemeinsam nutzen, gehört nicht in eine App oder ein Backend, sondern in ein eigenes Package-Repository. Ein Projekt kann neben Apps, Homepages und Backends mehrere davon enthalten. Jedes Package-Repository kommt mit einer Pipeline, die das Paket versioniert und in die passende Registry deines GitLab veröffentlicht.
Paket-Typen und ihre Registries
Beim Anlegen eines Package-Repositories wählst du den Typ. Er bestimmt, wohin die Pipeline veröffentlicht:
| Typ | Registry |
|---|---|
| Flutter/Dart-Paket | GitLab Package Registry |
| npm-Paket | GitLab npm Registry |
| PyPI-Paket | GitLab PyPI Registry |
| Docker-Image | GitLab Container Registry |
| Go-Paket | direkt aus dem Repository über den GitLab Go Proxy |
| Terraform-Modul oder -Provider | GitLab Terraform Module bzw. Provider Registry |
| Composer-Paket | GitLab Composer Registry (folgt) |
| Maven-Paket | GitLab Maven Registry (folgt) |
Composer- und Maven-Pakete folgen. Der Assistent kennt außerdem Kotlin-Packages und VS-Code-Plugins als Package-Typ. Alle Registries gehören zur GitLab-Gruppe deines Projekts und bleiben privat, solange du sie nicht ausdrücklich öffnest.
Vom Repository in die Registry
- Lege das Package-Repository beim Erstellen oder Bearbeiten eines Projekts als Komponente Package an und wähle den Typ.
- Entwickle das Paket wie gewohnt. Die Pipeline ist bereits eingerichtet, und
.gitlab-ci.ymländerst du nicht von Hand. - Bei jedem Push auf
mainberechnet die Pipeline die Version aus den Commit-Nachrichten (feat:,fix:) und veröffentlicht das Paket in der Registry aus der Tabelle. - In deinen Apps und Backends bindest du das Paket über die private Registry ein.
Importierst du ein bestehendes Repository über die ap CLI oder den Agenten, erkennt die Plattform einen Ordner nur dann als Package, wenn er eindeutig eines ist; die Liste der erkannten Typen steht unter Bestehendes Repository importieren.