Aide › Dépôt et branches

Dépôt, hôte SSH et branches

Les vues d'héritage ne sont pas écrites dans votre instance : elles partent par git, dans votre dépôt, sur la branche que vous désignez. L'étape 2 demande donc où pousser, et sur quelles branches.

Les valeurs demandées

Champ	Ce qu'on attend
Hôte SSH	La partie utilisateur@hôte de la commande SSH que votre hébergement vous donne
Branche de staging	Le nom de la branche git, tel quel
Branche de production	Le nom de la branche git, tel quel — obligatoirement différent du précédent
Module du thème	Le nom du répertoire qui porte le __manifest__.py du thème

Le dépôt, dans Odoo.sh

Un projet Odoo.sh est adossé à un dépôt GitHub : c'est le seul fournisseur proposé à la création d'un projet. Odoo.sh y installe une clé de déploiement et un webhook. Vous poussez sur GitHub, Odoo.sh reçoit la notification et reconstruit la branche.

Conséquence pratique : la commande du plan git push odoo HEAD:<branche> vise le dépôt distant de votre copie locale. Si le vôtre s'appelle origin, écrivez origin. Le nom du remote est une affaire locale, pas un réglage d'Odoo.sh.

Les branches, et leurs trois étages

Sur l'écran du projet, les branches sont rangées par étage. Le nom d'une branche est son nom git : recopiez-le à l'identique.

Production — une seule par projet. Chaque commit reçu met à jour et redémarre le serveur de production. Odoo.sh met à jour automatiquement un module dont le numéro de version a été incrémenté dans son __manifest__.py.
Staging — reconstruite sur un duplicata neutralisé de la base de production : vos données, sans les actions planifiées ni les envois sortants. C'est ce qui en fait un essai crédible plutôt qu'une base de démonstration.
Development — le travail en cours, sur une base de démonstration.

Pour un chantier de maquette, créez une branche de staging dédiée — staging-maquette — plutôt que de réutiliser celle d'un autre chantier. Vous saurez ce que vous regardez.

Les deux branches doivent être distinctes claude2odoo refuse un passage en production quand la branche de production est la même que celle de staging : il n'y aurait aucune étape intermédiaire, donc rien à valider.

L'hôte SSH

Ouvrez la branche dans Odoo.sh.
Cherchez le raccourci SSH, en haut à droite : il affiche la commande de connexion complète.
Recopiez-en la partie utilisateur@hôte dans le champ « Hôte SSH » de l'étape 2.

Ne devinez pas cette valeur. Elle contient l'identifiant du build, elle n'est pas la même d'une branche à l'autre, et sa forme n'est pas garantie dans le temps. Ce qui est stable, c'est l'endroit où Odoo.sh l'affiche.

Deux prérequis pour que la connexion aboutisse : votre clé publique SSH doit être enregistrée dans votre profil GitHub, et votre rôle sur le projet doit vous donner accès à l'environnement visé — un rôle « Developer » n'ouvre pas la production.

À défaut de SSH, l'onglet Shell de la branche ouvre un terminal dans le navigateur : les commandes du plan s'y déroulent aussi.

Le module du thème

C'est le module dans lequel les vues d'héritage seront écrites, et celui que l'upgrade visera. Il doit exister dans le dépôt et être installé sur la base. Donnez son nom technique — le nom du répertoire, pas le libellé affiché dans Applications.

Une branche ne doit jamais supprimer un module Sur Odoo.sh, un module installé dont le répertoire disparaît fait échouer le chargement du registre : la base ne démarre plus. Ce n'est pas une fonctionnalité perdue, c'est une instance à l'arrêt. Avant de fusionner, vérifiez qu'aucun __manifest__.py ne part.

Le cas d'un Odoo auto-hébergé

Pas d'Odoo.sh, mais la même mécanique : un dépôt git, une machine qui exécute odoo-bin, et deux environnements.

Hôte SSH : le utilisateur@serveur avec lequel vous vous connectez déjà à la machine qui héberge Odoo.
Branches : les noms de vos branches git. Si vous n'en avez qu'une, créez-en une seconde. L'exigence de staging n'est pas une formalité d'Odoo.sh : elle protège de la même famille de pannes.
Staging : une copie récente de la base de production sur un serveur ou un port séparé. Une base de démonstration ne vaut pas un essai — la moitié des pannes viennent des données réelles.
Le plan reste le même : l'ordre des commandes ne dépend pas de l'hébergeur, il dépend de la façon dont Odoo charge et recopie les vues.

Une différence à connaître : sur Odoo.sh, un push déclenche la reconstruction. Chez vous, personne ne le fait à votre place — le git push ne suffit pas, il faut dérouler les commandes suivantes.

Le cas d'Odoo Online

On ne peut pas déployer de module sur Odoo Online La documentation d'Odoo est explicite : Odoo Online est incompatible avec les modules personnalisés et avec les modules de l'Odoo Apps Store. Il n'y a pas de dépôt, pas de branche, pas d'accès SSH, et donc nulle part où écrire une vue d'héritage.

Ce qui fonctionne quand même :

L'audit et la comparaison. Ils ne demandent que la lecture de l'instance : vous voyez ce qui diffère, les écritures qu'il faudrait poser, et les constats.
Le XML rendu vous sert alors de relevé de travaux : chaque xpath dit quel nœud viser et quoi y changer.

Ce qui ne fonctionne pas : l'étape 4. Trois issues, dans l'ordre de préférence :

Passer sur Odoo.sh ou en auto-hébergé. C'est la seule qui rende le chantier reproductible.
Reporter les changements à la main dans l'éditeur de site. Attention : l'éditeur crée une copie de la vue pour le site concerné. Cette copie masque la vue générique, et ce que vous corrigerez ensuite au niveau générique n'atteindra plus la page. C'est la panne que le constat B2 décrit.
S'en tenir à l'audit. Savoir ce qui diffère a une valeur, même sans écriture automatique.

Suite

Comprendre les constats Déployer Sommaire de l'aide