Chaque projet pointe vers un dépôt unique. Les paramètres de ce dépôt déterminent la manière dont Coroid interagit avec votre modèle de branches.
Vous les trouverez dans les paramètres du projet.
Synchronisé ou local uniquement
Le mode du dépôt définit si Coroid peut écrire dans GitHub ou GitLab.
- Synchronisé (par défaut) : Coroid pousse la branche de chaque tâche et ouvre des demandes de fusion contre votre branche de base.
- Local uniquement: Coroid clone et récupère le contenu du dépôt mais n'y écrit jamais. Pas de push, pas de branches sur le dépôt distant, pas de demandes de fusion, de commentaires, d'avis, d'exécutions de vérification ou de webhooks, pas de fusion ni d'exécutions de pipeline. Les branches, commits, avis, contrôles qualité et prévisualisations se produisent tous à l'intérieur de Coroid.
Synchronisé
- Récupère les données depuis GitHub
- Envoie les branches et ouvre des demandes de fusion
Local uniquement
- Récupère les données depuis GitHub
- N'envoie jamais de données, ne laisse pas de commentaires ni n'ouvre de demandes de fusion
- Vous récupérez ses branches directement depuis le système Git de Coroid
Choisissez le mode lors de la création du projet, puis modifiez-le dans les paramètres du projet. Un projet local uniquement affiche Local uniquement à côté du nom du dépôt.
Le mode local uniquement constitue la façon la plus sûre d'essayer Coroid sur un vrai dépôt. Les tâches et plans sont exécutés jusqu'à l'étape d'avis. À la place de pull request, l'avis affiche Stocké dans Coroid et une action, Démarrer la synchronisation. L'approbation nécessite un projet synchronisé, car elle permet de fusionner dans votre branche de base ; au sein d'un plan, les tâches restent regroupées sur la branche du plan dans Coroid. La copie que Coroid conserve de votre branche de base reste identique à celle du dépôt distant, donc rien n'y accède sans qu'une pull request n'ait été ouverte.
Pour consulter le travail sur votre propre machine, ouvrez Cloner et exporter dans les paramètres du dépôt, créez un jeton d'accès, puis récupérez les branches de Coroid depuis son propre git :
git remote add coroid https://coroid@git.coroid.ai/git/<project-id>.git
git fetch coroidDémarrer la synchronisation passe le projet en mode Synchronisé. Dès lors, le nouveau travail est poussé et génère des demandes de fusion. Le travail déjà stocké dans Coroid reste à sa place : ouvrez sa pull request depuis la page d'avis (Créer pull request pour une tâche, Ouvrir pull request pour un plan). Revenir au mode Local uniquement prend effet immédiatement.
Rien dans le mode local uniquement ne dépend de la portée de votre jeton : Coroid refuse toute écriture dans le dépôt lui-même, quel que soit le pouvoir de la connexion. Ce mode suit les paramètres de branche du projet dans portabilité des paramètres.
Branche de base
Coroid se base sur votre branche de base pour ouvrir des demandes de fusion vers celle-ci. Par défaut, il s'agit de la branche par défaut du dépôt.
Modifiez-la si vous effectuez des fusions ailleurs : une develop branche, une ligne de publication ou une branche d'intégration à long terme. Une mauvaise configuration de ce paramètre constitue l'erreur la plus courante, ce qui entraîne des demandes de fusion ciblant une branche que personne ne revoit.
Lorsque la branche cible change
Un plan enregistre le commit de la branche de base à partir duquel il a été lancé. Si la branche de base change avant que la demande de fusion du pull request du plan ne soit traitée, Coroid suspend la fusion ; consultez Lorsque la branche de base évolue. Ce paramètre définit la suite à suivre :
- Suspendre pour révision (par défaut) — une personne examine les nouveaux commits, puis accepte ceux-ci ou demande à Coroid de les fusionner et de les soumettre à une nouvelle vérification.
- Fusionner et revérifier — Coroid fusionne les modifications dans la branche du plan et relance les tâches de développement, de contrôle qualité et de révision sans attendre l'intervention humaine. Cette opération consomme des heures d'agent. En cas d'échec de la fusion ou de la revérification, la décision revient à un être humain.
Dans tous les cas, aucune modification n'est fusionnée tant que le plan n'a pas été comparé à la branche de base actuelle ou qu'une personne n'a pas approuvé les différences. Ce paramètre fait partie des paramètres de branche du projet, donc il est transféré avec ceux-ci dans portabilité des paramètres.
Branches de travail
Chaque tâche s'exécute sur sa propre branche. Les branches sont créées pour chaque tâche et poussées vers le dépôt lorsque le travail est prêt (dans un projet en mode local uniquement, elles restent dans Coroid). Ainsi, deux tâches exécutées simultanément n'utilisent jamais la même branche et ne peuvent pas accéder au travail en cours de l'autre.
Aucun élément n'est jamais commité directement dans votre branche de base. Ce n'est pas un paramètre ; c'est une caractéristique inhérente au fonctionnement de Coroid.
Une branche par tâche. Deux tâches ne partagent jamais une branche.
Vos revues et vérifications obligatoires s'appliquent sans changement.
Vous fusionnez dans main
Protection des branches
Votre protection des branches existante reste inchangée. Coroid ouvre une demande de fusion ordinaire, de sorte que les revues requises, les vérifications d'état obligatoires et les restrictions sur les personnes pouvant fusionner fonctionnent exactement comme pour votre équipe.
Si vos règles de protection exigent un commit signé ou une vérification de statut spécifique que Coroid ne peut pas générer, l'pull request s'ouvrira puis restera non fusionnable — il s'agit là du bon fonctionnement de vos règles, et non d'une défaillance de Coroid.
Nettoyage
Les branches correspondant à des tâches terminées peuvent être supprimées une fois leur pull request fusionnée ou fermée . Si vous utilisez les noms de branches pour l’audit ou vos outils de gestion des versions, vérifiez ce point avant d’activer cette option.
Modifier la connexion
Si la connexion au dépôt sous-jacent change — rotation de jeton, réinstallation d'une application ou renommage du dépôt — le projet conserve son identité et son historique. Re-orientez-le vers la nouvelle connexion plutôt que de créer un nouveau projet afin de ne pas perdre le contexte, les paramètres et les travaux antérieurs.
Paramètres du pipeline de publication
La branche de base détermine l'emplacement où Coroid ouvre les demandes de fusion. Le déploiement utilise un projet séparé. Publication Configuration de la publication : un environnement, sa politique de prêt, et éventuellement une référence de pipeline GitLab ou des actions GitHub. La référence doit pointer vers le commit verrouillé de la version avant que Coroid ne lance l'exécution. Configurez une identité d'appel en scope d'environnement afin que le pipeline puisse signaler son résultat ; la simple connexion au dépôt ne suffit pas à prouver ce qui a été déployé. Les pipelines externes peuvent rapporter des événements sans autoriser l'envoi de requêtes depuis Coroid.