Déployer depuis votre dépôt Git

Déployer ici, ce n'est pas redémarrer un serveur avec de nouveaux fichiers dessus. Chaque déploiement construit une image à partir d'un commit précis, puis fait tourner cette image. Ce seul point explique presque tout ce que vous verrez : pourquoi un déploiement prend des minutes et non des secondes, pourquoi la version en service peut toujours être nommée, et pourquoi revenir en arrière est instantané.

Ce qu'il vous faut

• Une instance avec au moins un environnement.
• La permission git.manage pour connecter un dépôt, et environments.deploy pour en déployer un.
• Un dépôt contenant des modules Odoo. Les dépôts privés exigent en plus l'autorisation du fournisseur décrite plus bas.

Connecter le dépôt

Ouvrez votre instance, allez dans l'onglet Intégration Git et choisissez Connecter un dépôt. Vous pouvez connecter un dépôt existant ou en créer un.

Connecter un dépôt public en lecture seule fonctionne immédiatement. Tout le reste — dépôt privé, webhooks, déploiement auto, création de branches — exige d'abord l'Autorisation du fournisseur, via Connecter le fournisseur. Si le client OAuth n'est pas encore configuré pour votre fournisseur, l'interface le dit au lieu d'échouer à mi-parcours.

Autoriser vous emmène chez le fournisseur et vous ramène avec le compte listé sous Compte autorisé. Sur GitHub, la plateforme fonctionne comme une application que l'on installe, et deux situations au retour ne sont pas des échecs. L'installer sur une organisation peut exiger qu'un propriétaire de cette organisation l'approuve d'abord : l'écran le dit, et le compte apparaît une fois l'approbation donnée. Et si votre compte est autorisé mais que l'application n'est installée nulle part, aucun dépôt n'est accessible — relancez la connexion, elle propose l'installation. Un dépôt attendu et introuvable est en général un dépôt auquel l'installation n'a pas reçu l'accès ; corrigez cela chez le fournisseur, puis Actualiser les dépôts.

L'identifiant stocké pour le dépôt est chiffré au repos et ne sert qu'à lire la branche construite, et à y écrire uniquement lorsque vous demandez explicitement un commit.

Ce qu'un déploiement fait réellement

Quand vous déployez une branche, quatre choses se produisent dans cet ordre :

1. Le commit en tête de branche est résolu et figé. À partir de là, le déploiement se réfère à ce commit, plus à la branche.
2. Un job de build produit une image contenant vos modules par-dessus l'image de base de l'environnement.
3. L'image est poussée au registre sous une étiquette dérivée du commit.
4. L'environnement bascule sur cette image. Cette étape ne migre pas la base : Mettre à jour les modules, dans l'onglet Modules, l'aligne sur le nouveau code.

La conséquence à retenir : ce qui tourne est toujours une version nommée. Pas « le dernier état de la branche » — une image précise, construite depuis un commit précis, redéployable telle quelle.

Le déploiement auto au push

Activez Déploiement auto au push et chaque push sur la branche connectée déclenche la même séquence.

Cela passe par un webhook, et ce webhook est vérifié avec un secret propre à ce dépôt, pas un secret global. Si le secret ne correspond pas, le push est rejeté silencieusement à la porte — pas de build, pas de déploiement, aucune erreur sur votre écran, puisque du point de vue de la plateforme rien n'a été poussé.

Cette même porte commande la synchronisation des modules. Donc si vous poussez et qu'il ne se passe absolument rien — ni déploiement, ni liste de modules à jour — vérifiez le secret du webhook avant toute autre chose. C'est de loin la cause la plus probable, et elle ne produit aucune erreur visible.

Deux interrupteurs doivent être allumés : Déploiement auto au push sur la carte du dépôt, et celui de l'environnement lui-même. Allumer celui de l'environnement allume aussi celui du dépôt, avec la même règle de forfait ; s'il est coupé pour le dépôt, l'environnement l'indique et propose de le rallumer. Un push déploie chaque environnement qui suit la branche poussée, y compris un environnement créé sur une autre branche du même dépôt.

Un push qui arrive pendant que l'environnement met encore en ligne le précédent n'est pas perdu : il attend dans la liste des déploiements et démarre dès que l'environnement est disponible. Si plusieurs pushes attendent ainsi, seul le plus récent part ; les autres sont annulés avec la mention « Superseded by a newer push ».

Un environnement dont le dernier déploiement n'a pas démarré se redéploie, sur un push comme avec le bouton Déployer : c'est ainsi qu'un correctif le relance. Un environnement qui n'a jamais fini sa création se relance depuis sa page, avec Réessayer. Un environnement arrêté ne se redéploie pas sur un push.

Le bouton Déployer d'un environnement déploie toujours la tête de sa branche au moment du clic, même si la page est ouverte depuis longtemps : inutile de synchroniser avant.

D'où viennent les addons

L'arborescence de votre dépôt n'est pas aplatie. Chaque répertoire contenant des modules Odoo devient sa propre entrée dans addons_path. Un dépôt organisé ainsi :

repo/
  addons/          -> une racine d'addons
  enterprise_ext/  -> une autre racine d'addons
  tools/           -> pas un répertoire de modules, ignoré

donne à Odoo deux racines d'addons plutôt qu'un dossier fusionné, dans l'ordre où elles apparaissent. Si deux racines contiennent un module de même nom, Odoo ne charge que le premier — le journal du build nomme chacun de ces doublons : regardez-le quand la modification d'un module semble sans effet.

Si votre environnement tourne sur une image de base sans build, Odoo n'a aucun /mnt/extra-addons à lire et vos modules n'apparaîtront pas. La page de l'environnement propose alors une action Build & déployer les modules de la branche : c'est elle qui transforme le dépôt en image.

Quand un build échoue ou expire

Deux limites distinctes s'appliquent, et savoir laquelle vous avez atteinte fait gagner du temps :

Un build long n'est pas forcément bloqué. Les parties lentes sont l'installation des dépendances Python et le push de l'image, et toutes deux croissent avec vos dépendances. Un build peut aussi attendre d'abord une place libre — chaque équipe ne fait tourner qu'un nombre limité de builds à la fois — et cette attente compte dans la patience du déploiement. Si un build expire de façon reproductible, c'est la limite qu'il faut relever, pas votre code.

Certains builds s'arrêtent volontairement, et le journal en donne la raison en clair :

• Des secrets possibles dans le source. Les modules qui entrent dans l'image sont analysés, et un identifiant qui s'y retrouverait arrête le build. Le reste du dépôt (documentation, fichiers de CI, dossiers d'éditeur), les dossiers tests/ et les valeurs d'exemple comme "your-key" ou "${API_KEY}" ne le sont pas.
• Aucun module trouvé, ou la racine du dépôt est elle-même un module. Les modules doivent se trouver dans des répertoires, pas à la racine du dépôt.
• Des sous-modules Git. Le source que reçoit un build ne les contient pas : les addons qui vivent dans un sous-module ne sont tout simplement pas là.
• Une dépendance tirée d'une URL dans un requirements.txt. Seuls les paquets de PyPI sont acceptés.
• Trop de modules, ou des addons trop volumineux. Le journal affiche le nombre et la taille face à leurs limites, et prévient avant que vous ne les atteigniez.

Les paquets Python viennent des fichiers requirements.txt, à la racine du dépôt ou à côté d'un module. Les external_dependencies d'un manifeste ne sont pas installées pour vous : elles font seulement refuser le module par Odoo quand l'import échoue.

Revenir à une version précédente

Déployer une ancienne version remet un build antérieur en service. Elle redéploie l'image exacte, telle qu'elle a été construite — rien n'est reconstruit, donc c'est rapide et il n'y a aucun risque d'obtenir un résultat différent.

Une chose qu'elle ne fait pas : elle ne migre pas les bases en arrière. Le code revient à la version antérieure ; la base reste là où la dernière migration l'a laissée. Pour un changement de schéma, c'est généralement acceptable sur un retour arrière court, et ce n'est pas un moyen d'annuler une migration. Si vous avez besoin des données telles qu'elles étaient, restaurez plutôt une sauvegarde — c'est une autre opération, et elle existe en deux formes : Restaurer écrase cet environnement (une sauvegarde de sécurité est prise avant, et l'environnement redémarre), Cloner vers un nouvel environnement laisse celui-ci intact. Le guide Dupliquer la production pour tester détaille les deux.