Kuunda Git (Git hébergé)
Kuunda Git héberge le dépôt Git de votre projet sur l’infrastructure Kuunda : clone et push en HTTPS avec un jeton du projet, sans service tiers et sans copie du code hors de la zone du projet.
Un dépôt par projet
Chaque projet Kuunda héberge son propre dépôt Git. Le premier git push crée le dépôt, avec le nom que vous choisissez : rien à déclarer à l’avance. Le dépôt vit avec le projet, dans sa zone de résidence.
- Un dépôt par application ou par service : le nom choisi devient le dernier segment de l’adresse Git.
- Le contenu des dépôts est compté dans la dotation du projet, avec un plafond par dépôt.
- Le code reste hors de la base du projet : il vit sur son propre espace, tandis que les droits, les quotas et les journaux restent gérés par la console.
- Le dépôt reste un dépôt Git standard : git clone --mirror vous en rend une copie complète, sans enfermement.
Jetons d’accès
Un dépôt ne s’ouvre pas avec votre mot de passe de compte : il faut un jeton, créé depuis le projet, dans Services → Kuunda Git.
- Portée lecture : clone et fetch — le bon choix pour un poste de travail.
- Portée écriture : clone, fetch et push — pour la machine qui publie (CI, agent).
- Un jeton ne donne accès qu’à ce projet, jusqu’à sa date d’expiration (de quelques jours à jamais).
- Sa valeur n’est affichée qu’une fois : copiez-la dans votre gestionnaire de secrets ou vos variables CI.
- Un jeton se révoque depuis la même page ; la révocation coupe l’accès sans toucher au dépôt.
Cloner et pousser
L’adresse affichée dans la console se colle telle quelle : git demande l’identifiant kuunda et le jeton. Le credential.helper évite de ressaisir le secret à chaque commande.
Terminal
git remote add kuunda <url>
git config credential.helper '!f() { echo username=kuunda; echo password=<token>; }; f'
git push kuunda mainRemplacez <url> par l’adresse affichée dans Services → Kuunda Git, et <token> par la valeur créée juste avant. La console propose le même bloc de commandes déjà rempli, à copier d’un clic.
Ce que le push déclenche
Un site du projet peut être branché sur un dépôt : le push devient alors un déploiement, sans étape manuelle.
- Le push est accepté avant le build : si le build échoue, le commit est conservé et la version publiée reste en ligne.
- Les journaux du build et la révision déployée restent consultables depuis la page du site.
- Un dépôt sans site branché sert de dépôt Git : rien n’est construit.
- Les issues, les pull requests et les revues sont dans le projet (mêmes rôles). Pas de wiki, pas de recherche de code, pas de runners publics.
Supprimer et restaurer
La suppression retire le dépôt de l’espace du projet, mais elle est réversible : une sauvegarde chiffrée est écrite et relue avant le retrait. La confirmation exige le nom exact du dépôt. Une restauration ne recrée jamais un dépôt existant : supprimez-le d’abord pour revenir à une sauvegarde antérieure.