Orbit
Connexion d'un référentiel GitLab
GitLab connects to Orbit through OAuth rather than an installed app: you authorise Kapsule once, Orbit lists the projects your GitLab account can reach, and it registers a webhook per repository so…
GitLab se connecte à Orbit via OAuth plutôt que via une application installée : vous autorisez Kapsule une seule fois, Orbit affiche la liste des projets auxquels votre compte GitLab peut accéder, et il enregistre un webhook par référentiel pour que chaque push déclenche une compilation. Ce guide couvre la connexion, la sélection d'un référentiel, le verrouillage des déploiements sur votre pipeline GitLab, et les raisons habituelles pour lesquelles un référentiel n'apparaît pas.
Avant de commencer
Orbit ne peut voir que les projets GitLab auxquels votre propre compte peut accéder. Pour un projet appartenant à un groupe, vous avez besoin d'au moins un accès Développeur, et vous devez avoir suffisamment de permissions pour créer un webhook sur le référentiel. Si votre instance GitLab restreint les webhooks sortants, cette restriction s'applique ici aussi.
Étape 1 : Connecter GitLab
- Dans KPanel, cliquez sur Orbit dans la barre latérale gauche.
- Cliquez sur New project.
- Laissez le mode défini sur Import Git Repo.
- À l'étape 1, cliquez sur Connect GitLab.
Vous êtes envoyé vers GitLab pour autoriser l'application Kapsule Orbit. Approuvez les portées demandées et GitLab vous renvoie vers KPanel avec vos référentiels chargés. L'étape 1 affiche alors Just connected.
Si la connexion échoue, KPanel affiche l'erreur renvoyée par GitLab plutôt qu'un message générique. Lisez-la avant de réessayer : un refus de portée et une autorisation expirée nécessitent des correctifs différents.
Étape 2 : Sélectionner un référentiel
Vos référentiels accessibles apparaissent sous forme de liste. Cliquez sur Select à côté de celui que vous voulez. Les référentiels privés portent un badge Private ; Orbit déploie les référentiels publics et privés de la même manière.
Si un référentiel est manquant
- Vérifiez votre rôle sur le projet. Un accès Reporter n'est pas suffisant ; vous avez besoin d'au moins Developer.
- Si le projet appartient à un groupe, confirmez que votre adhésion est au groupe ou au projet lui-même, pas simplement à un groupe ancêtre avec un rôle restreint.
- Cliquez sur Reconnect GitLab à l'étape 1 pour relancer le flux OAuth. Cela actualise le jeton et relit votre liste de projets.
Si le panneau affiche No repos accessible, l'autorisation OAuth s'est déroulée mais n'a rien renvoyé. Reconnectez-vous et vérifiez que vous avez approuvé les portées de référentiel plutôt qu'un ensemble réduit.
Étape 3 : Configurer votre projet
| Champ | Ce qu'il fait |
|---|---|
| Project Name | Le nom d'affichage dans KPanel, par exemple my-app |
| Deploy URL | Le sous-domaine sous kaps.run, ainsi my-app devient my-app.kaps.run |
Cliquez sur Create project. Orbit clone le référentiel, met en file d'attente la première compilation, et vous mène à la vue d'ensemble du projet.
Le slug de l'URL de déploiement est fixé à la création et ne peut pas être modifié ultérieurement. Pour publier sous une adresse différente, attachez plutôt un domaine personnalisé. Voir Adding a Custom Domain to Your Project.
Déploiements automatiques
Orbit enregistre un webhook sur votre référentiel GitLab lors de la création du projet. Après cela :
- Une poussée vers votre branche de production met en file d'attente un déploiement en production.
- Une poussée vers une autre branche construit un aperçu isolé à
branch-<branch-name>.kaps.run, si Branch previews est activé dans Settings sous Runtime. Voir Branch Preview Deployments in Orbit. - La suppression d'une branche pause son environnement d'aperçu, et le stockage est récupéré en environ un jour.
Vous ne créez ou ne maintenez pas le webhook manuellement.
Attendre votre pipeline GitLab CI
Si vous exécutez des tests dans GitLab CI, Orbit peut tenir le déploiement jusqu'à ce que le pipeline réussisse.
- Ouvrez le projet, puis Settings.
- Trouvez CI required checks.
- Entrez une valeur non vide et enregistrez.
Sur GitLab, la valeur elle-même n'est pas comparée aux noms de tâches : toute valeur non vide indique à Orbit d'attendre que le pipeline complet réussisse. Un échec du pipeline annule automatiquement le déploiement Orbit. Cela s'applique uniquement aux déploiements déclenchés par une poussée sur la branche de production.
C'est là que les deux fournisseurs diffèrent. GitHub compare la valeur aux tâches Actions nommées ; GitLab traite toute valeur comme « attendre que l'ensemble du pipeline réussisse ». Si vous copiez des paramètres entre un projet GitHub et un projet GitLab, ne vous attendez pas à ce que le même champ se comporte de manière identique.
Reconnecter ou déconnecter GitLab
- Cliquez sur Orbit, puis sur New project.
- À l'étape 1, cliquez sur Reconnect pour relancer le flux OAuth, ou sur Disconnect pour supprimer le lien.
Reconnecter est le bon premier geste chaque fois que l'énumération des référentiels cesse de fonctionner : les jetons OAuth expirent, et la reconnexion en crée un nouveau.
La déconnexion conserve vos projets et leur historique de déploiement, et le déploiement en direct continue de servir le trafic. Ce qui s'arrête, c'est le déploiement déclenché par une poussée. Les crochets de déploiement cessent également de fonctionner, car un crochet doit lire la tête de branche via la connexion du fournisseur pour savoir quoi construire.
Lectures connexes
- Deploying Your Project pour le cycle de déploiement complet, les verrous de déploiement et les approbations
- Troubleshooting Failed Builds si la première compilation ne réussit pas
- Connecting a GitHub Repo et Connecting a Bitbucket Repo pour les autres fournisseurs