Dépôts & CI/CD

Connecter des dépôts et exécuter des pipelines sur les eQuantic Runners.

Connecter des dépôts#

Utilisez le GitHub App (recommandé) pour des permissions granulaires gérées par l'organisation, avec des tokens d'installation de courte durée. Azure DevOps est désormais pris en charge : connectez une organisation avec un Personal Access Token et choisissez les dépôts (org/project/repo) — les webhooks (Service Hooks) sont configurés automatiquement. GitLab est également disponible : connectez-le avec un Personal Access Token — gitlab.com ou votre propre instance auto-hébergée — et choisissez les projets (sous-groupes profondément imbriqués compris) ; les webhooks sont configurés automatiquement. Bitbucket est lui aussi un fournisseur de premier plan : connectez un workspace Bitbucket avec un app password ou un token d'API Atlassian (avec l'e-mail de votre compte) et choisissez les dépôts (workspace/repo) ; les webhooks sont configurés automatiquement. GitHub, GitLab, Bitbucket et Azure DevOps sont tous entièrement pris en charge.

Pipelines#

La plateforme interprète vos YAML GitHub Actions, Azure Pipelines (azure-pipelines.yml), GitLab CI (.gitlab-ci.yml) et Bitbucket Pipelines (bitbucket-pipelines.yml) et exécute les jobs sur les eQuantic Runners. Fonctionnalités :

• Graphe de jobs dérivé des dépendances needs:, avec les matrix builds qui se déploient en nœuds parallèles.
• Tasks Azure Pipelines réelles sur les steps task:, résolues depuis votre propre organisation (tasks du marketplace comprises) ; les tasks disponibles uniquement en PowerShell et les service connections ne sont pas encore prises en charge.
• Logs en direct par step, avec ré-exécution de tout / des échecs uniquement / d'un job individuel.
• Éditeur visuel de steps (glisser-déposer) et mode d'édition avancée du YAML.
• Approbation manuelle avant le déploiement en production (quorum N-sur-M) et environments protégés.
• Cache configurable et secrets/variables par dépôt, avec références aux variables de services.

Pull requests#

Une fois un dépôt connecté (GitHub, GitLab, Bitbucket ou Azure DevOps), vous pouvez choisir de gérer ses Pull Requests dans eQuantic plutôt que chez le fournisseur — un opt-in par dépôt. Le code reste toujours chez le fournisseur ; eQuantic n'assure jamais l'hébergement git.

• Opt-in dans l'onglet Pull requests — activez les PR gérées par eQuantic, ou continuez d'utiliser celles du fournisseur (par défaut).
• Création de PR — choisissez la branche source → cible, le titre et la description ; chaque PR reçoit une numérotation propre au dépôt.
• Liste avec états — open / draft / merged / closed, avec filtres.
• Vue du diff — eQuantic calcule elle-même le diff (three-dot, par rapport au merge-base, comme dans les interfaces des fournisseurs) et le stocke : l'écran de détail affiche un résumé (fichiers modifiés, +ajouts −suppressions) et des hunks unifiés par fichier, avec les numéros de ligne exacts. Les fichiers binaires et les diffs très volumineux sont signalés au lieu d'être affichés ; les nouveaux pushes sur la branche source rafraîchissent le diff automatiquement via le webhook du dépôt.
• Revue de code sur le diff — commentez n'importe quelle ligne du diff : les fils de discussion sont ancrés à la ligne exacte, avec réponses et résolution/réouverture. Quand de nouveaux commits arrivent, les fils existants ne sont jamais perdus — ils sont signalés comme obsolètes et regroupés par fichier.
• Commentaires bloquants — un commentaire de revue peut être marqué comme bloquant ; les commentaires bloquants non résolus sont mis en évidence sur la PR (bannière et indicateur dans la liste), et seul leur auteur peut les résoudre.
• Approbations et conversation — les relecteurs approuvent ou demandent des modifications (un seul verdict actif par relecteur ; l'auteur de la PR ne peut pas revoir sa propre PR), avec les compteurs approbations/modifications sur la PR et dans la liste — plus un fil de commentaires généraux sur la PR, en parallèle des fils de ligne.
• Protection de branche — dans les paramètres du dépôt, définissez des règles par motif de branche (main, release/*) : nombre minimal d'approbations, historique linéaire, branche à jour par rapport à la cible, rejet des approbations obsolètes à l'arrivée de nouveaux commits, veto ou non des commentaires bloquants non résolus — plus les stratégies de merge autorisées et celle par défaut.
• Merge dans eQuantic — quand toutes les conditions sont réunies (approbations, aucune demande de modifications, aucun commentaire bloquant non résolu, règles de protection), la PR peut être fusionnée en merge commit, squash ou rebase. eQuantic effectue le merge elle-même et pousse le résultat chez le fournisseur — jamais via l'API de merge du fournisseur, jamais en force-push. Tant que le merge est bloqué, la PR liste exactement ce qui manque ; une PR peut aussi être fermée sans merge.
• File d'attente de merge — plutôt que de fusionner directement, une PR peut rejoindre la file d'attente de sa branche cible. La file traite les entrées dans l'ordre : chacune est testée par rapport à l'état courant de la cible — une branche restée en retard n'a donc pas besoin d'être mise à jour manuellement, et rejoindre la file est permis même si la branche n'est pas à jour — et, si toutes les conditions sont encore réunies au moment du merge, eQuantic effectue le merge et pousse le résultat. Un conflit ou une condition non remplie retire l'entrée de la file avec le motif, et la suivante prend le relais ; les entrées en attente peuvent quitter la file, et le panneau de file d'attente de l'onglet Pull requests affiche les positions et le statut en direct.
• Checks CI — les exécutions de pipeline sur les commits de la PR remontent leur statut nativement sur la PR : un check par workflow et par commit — en attente, réussi ou échoué — affiché dans le panneau de merge. Une règle de protection de branche peut également exiger les checks : la PR ne peut être fusionnée que lorsque tous les checks remontés sont passés — un check échoué ou encore en cours bloque le merge, tout comme l'absence de tout check remonté (un check exigé ne passe jamais en silence). La même exigence s'applique aussi aux entrées de la file d'attente de merge.

Environnements de preview#

Chaque Pull Request ouverte peut recevoir un environnement de preview éphémère — un service isolé, construit à partir de la branche de la PR, avec sa propre URL (pr-N.preview.<domaine-de-déploiement>).

• Configuration par dépôt dans l'onglet Previews : le toggle d'auto-preview, le Space cible et un environnement de base optionnel dont les variables sont clonées dans chaque preview.
• Cycle de vie automatique — PR ouverte → environnement provisionné ; nouveaux pushes → redéploiement ; merge/fermeture → destruction. La carte affiche le statut en direct (building → ready / failed), l'URL, la branche/le commit et l'auteur.
• Mode manuel — l'onglet liste les PR ouvertes sans preview, avec création en un clic ; les previews existantes peuvent être reconstruites ou détruites depuis le menu de la carte.
• L'URL de la preview est publiée en commentaire sur la PR et maintenue à jour.