Rami

La vista Filiali fornisce una panoramica dei vari rami del tuo repository.

Fasi

Odoo.sh offre tre fasi diverse per i rami:

• Produzione

• Staging

• Sviluppo

È possibile modificare lo stato di un ramo trascinandolo e rilasciandolo sotto lo stato desiderato.

Nota

• I rami di sviluppo possono essere spostati sotto Staging. Se provi a spostare un ramo di sviluppo sotto Produzione, verrà visualizzato un avviso che spiega che è possibile avere un solo ramo di produzione per progetto.

• I rami di staging possono essere spostati sotto Sviluppo, ma non è possibile spostarli sotto Produzione.

• Il ramo di produzione può essere spostato solo sotto Sviluppo. Se provi a di spostarlo sotto Staging, è possibile eseguire solo un merge. Fai riferimento alla sezione unione per una spiegazione dettagliata di questo processo.

Produzione

Il ramo di produzione contiene il codice utilizzato per eseguire il database di produzione. Può esserci un solo ramo di produzione.

Quando invii un nuovo commit a questo ramo, il server di produzione viene aggiornato con il codice revisionato e riavviato.

Se le modifiche richiedono un aggiornamento del modulo, come la modifica della vista modulo, e desideri che l’aggiornamento venga eseguito automaticamente, è possibile aumentare il numero di versione del modulo nel suo file manifest (__manifest__.py). La piattaforma eseguirà quindi l’aggiornamento, durante il quale l’istanza sarà temporaneamente non disponibile per motivi di manutenzione.

Questo metodo equivale all’aggiornamento del modulo utilizzando il menu Applicazioni o l’opzione -u nella riga di comando.

Nota

• Se le modifiche impediscono il riavvio del server o se l’aggiornamento del modulo non riesce, il server viene automaticamente riportato alla revisione precedente del codice che ha funzionato correttamente e il database viene riportato allo stato precedente. Accedi al log dell’aggiornamento non riuscito per risolvere il problema.

• I dati demo non vengono caricati, poiché non sono destinati all’uso su un database di produzione. I test unitari non vengono eseguiti, poiché aumenterebbero il tempo di indisponibilità del database di produzione durante l’aggiornamento.

Odoo.sh esegue automaticamente il backup del database di produzione. Conserva sette backup giornalieri, quattro settimanali e tre mensili. Ogni backup include il dump del database, l’archivio file (allegati e campi binari), i log e le sessioni.

Avvertimento

Quando si utilizzano progetti di prova, il ramo di produzione e tutti i rami di staging vengono automaticamente riportati alla fase di sviluppo dopo 30 giorni.

Staging

I rami di staging servono a testare nuove funzionalità utilizzando i dati di produzione senza compromettere il database di produzione effettivo con record di test. Creano duplicati neutralizzati del database di produzione.

La neutralizzazione disattiva:

• Azioni programmate

  Nota

  Per testarli, attivarli manualmente o riattivarli. Tieni presente che la piattaforma li attiverà meno frequentemente se nessuno sta utilizzando il database, al fine di risparmiare risorse.

• E-mail in uscita

  Nota

  Vengono invece intercettate utilizzando un e-mail catcher. Nel progetto Odoo.sh è disponibile una interfaccia per visualizzare le e-mail inviate dal database. In questo modo, nessuna e-mail viene inviata ai tuoi contatti.

• Servizi IAP

• Fornitori di servizi di pagamento e vettori

  Nota

  Vengono messi in modalità test.

Se configuri o visualizzi modifiche in un database di staging, assicurati di registrarle (annotandole passo dopo passo, riproducendole in produzione, ecc.) o di scriverle direttamente nei moduli del ramo, utilizzando file di dati XML per sovrascrivere la configurazione o le viste predefinite. Consulta la documentazione sul primo modulo per vedere alcuni esempi.

Nota

I test unitari non vengono eseguiti. Si basano su dati demo, che non vengono caricati nei database di produzione e staging. Se Odoo inizierà a supportare l’esecuzione delle unità senza dati demo, Odoo.sh valuterà l’esecuzione dei test sui database di staging.

I database di staging non vengono sottoposti automaticamente a backup. Tuttavia, è possibile ripristinare un backup del database di produzione in un ramo di staging a scopo di test o per recuperare manualmente i dati che sono stati accidentalmente eliminati dal database di produzione. È possibile creare backup manuali dei database di staging.

Avvertimento

I database creati per i rami di staging sono destinati a durare fino a tre mesi. Trascorso tale periodo, possono essere bloccati automaticamente senza preavviso. Solo ricostruendo il ramo sarà possibile utilizzare nuovamente quel ramo specifico.

Sviluppo

I rami di sviluppo creano nuovi database utilizzando dati demo per eseguire i test unitari. I moduli installati sono quelli inclusi nel ramo. È possibile modificare questo elenco di moduli da installare nelle impostazioni del progetto.

Quando si invia un commit a un ramo di sviluppo, viene avviato un nuovo server con un database creato da zero e il ramo viene aggiornato. I dati demo vengono caricati e i test unitari vengono eseguiti per impostazione predefinita per verificare che le modifiche non compromettano nessuna delle funzionalità sottoposte a test. È possibile disabilitare i test o consentire l’esecuzione di test specifici con tag personalizzati andando sulle impostazioni del ramo.

Analogamente alle ramificazioni di staging, le e-mail non vengono inviate ma intercettate da un e-mail catcher e le azioni pianificate non vengono attivate finché il database non è in uso.

I database di sviluppo non vengono sottoposti automaticamente a backup e non è possibile eseguire backup manuali.

Avvertimento

I database creati per i rami di sviluppo hanno una durata prevista di circa tre giorni. Trascorso tale periodo, possono essere automaticamente eliminati per fare spazio a nuovi database senza preavviso.

Unire rami

È possibile unire i rami trascinandoli l’uno sull’altro.

Per testare le modifiche dei rami di sviluppo con i dati di produzione, è possibile:

• unire il ramo di sviluppo in un ramo di staging trascinandolo sul ramo desiderato; oppure

  

• trascinare e rilasciare il ramo di sviluppo nella sezione Staging per renderlo un ramo di staging.

  

Quando le modifiche sono pronte per la produzione, trascina il ramo di staging nel ramo di produzione per unirli e distribuirli.

Nota

• È possibile unire i rami di sviluppo direttamente nel ramo di produzione. Tuttavia, le modifiche non saranno convalidate rispetto ai dati di produzione attraverso un ramo di staging, quindi c’è un rischio maggiore di incontrare problemi nel database di produzione.

• Puoi unire i rami di sviluppo e i rami di staging tra loro.

• È anche possibile utilizzare git merge direttamente sulla propria workstation per unire i rami. Odoo.sh riceve una notifica quando vengono inviate nuove revisioni ai rami.

La fusione di un ramo di staging nel ramo di produzione comporta solo la fusione del codice sorgente. Eventuali modifiche apportate al database di staging non vengono trasferite al database di produzione. Tuttavia, se si modifica il codice nel repository, esso verrà trasferito al ramo di produzione durante la fusione.

Se le impostazioni del test cambiano nei rami di staging e vuoi che vengano applicate in produzione, devi:

• scrivere le modifiche di configurazione nei file di dati XML per sovrascrivere la configurazione o le viste predefinite nel ramo, quindi aumentare la versione del modulo nel suo manifesto (__manifest__.py) per attivare l’aggiornamento del modulo quando si unisce il ramo di staging nel ramo di produzione oppure

  Nota

  Questo metodo è consigliato per una migliore scalabilità dei tuoi sviluppi, poiché utilizzerai le funzionalità di versioning di Git per tutte le modifiche di configurazione, garantendo così la tracciabilità delle tue modifiche.

• trasferirle manualmente dal database di staging a quello di produzione copiandole e incollandole.

Schede

Cronologia

La scheda Cronologia offre una panoramica della cronologia del ramo:

• i messaggi di commit e i loro autori

• i vari eventi collegati alla piattaforma, come modifiche alle fasi, importazioni di database e ripristini di backup.

Uno stato nell’angolo in alto a destra di ogni evento indica l’operazione corrente sul database (ad esempio, installazione, aggiornamento, importazione di backup) o il suo esito (ad esempio, feedback del test, importazione di backup riuscita). Se un’operazione ha esito positivo, viene visualizzato il pulsante Connetti, che consente di accedere al database.

Email

La scheda E-mail contiene il mail catcher, che fornisce una panoramica delle e-mail inviate dal database.

Nota

Il mail catcher è disponibile per i rami di sviluppo e staging. Le e-mail provenienti dal database di produzione vengono effettivamente inviate e non vengono intercettate dal mail catcher.

Shell

La scheda Shell fornisce l’accesso alla shell del contenitore.

Facendo clic su Shell si apre una nuova scheda del browser in cui è possibile eseguire i comandi Linux di base (ls, top). È possibile aprire una shell sul database eseguendo psql.

Suggerimento

È possibile aprire più schede shell contemporaneamente e organizzarne il layout trascinandole.

Nota

• Le shell delle istanze di produzione sono evidenziate in rosso per sottolineare il pericolo di manipolare direttamente le istanze di produzione, mentre le shell delle istanze di staging/sviluppo sono evidenziate in giallo.

• Le istanze shell di lunga durata/sessioni shell inattive possono essere terminate in qualsiasi momento per liberare risorse.

Comandi

Ecco una panoramica dei comandi utili che è possibile eseguire in un terminale del database Odoo.sh:

• odoo-bin shell: per aprire una shell Odoo

• odoo-update: per aggiornare i moduli nel database

• odoosh-restart: per riavviare i servizi Odoo.sh (http o cron)

• odoosh-storage: per verificare l’utilizzo dell’archiviazione del file di sistema del contenitore della tua istanza

• psql: per aprire una shell di un database

• mutt: per verificare come vengono visualizzate le e-mail sui client di testo (istanze di staging e sviluppo)

• lnav ~/logs/odoo.log: per navigare nel file odoo.log della tua istanza

• ncdu: per lanciare l’analizzatore dell’utilizzo del disco con un’interfaccia interattiva

• grep: per filtrare e trovare informazioni nei file di log o configurazione.

Redattore

Facendo clic su Editor si apre una nuova scheda del browser per accedere a un ambiente di sviluppo integrato (IDE) online per modificare il codice sorgente. È anche possibile aprire terminali, console Python e console shell Odoo.

È possibile aprire più schede e trascinarle per organizzare il layout come desideri.

Vedi anche

Documentazione editor online.

Monitoraggio

La scheda Monitoraggio mostra varie metriche di monitoraggio delle prestazioni della build corrente.

Ingrandisci con il cursore per regolare l’intervallo di tempo o selezionalo manualmente dal selettore dell’intervallo di tempo. È anche possibile modificare il fuso orario.

Nota

• I log tecnici utilizzano sempre l’UTC. Per analizzare questi log insieme alle metriche di monitoraggio, assicurati che l’UTC sia selezionato nello strumento di monitoraggio.

• Allo stesso modo, quando invii un ticket di assistenza, assicurati che le informazioni che condividi siano basate su UTC, poiché Odoo utilizza questo fuso orario per indagare sui problemi di prestazione.

Le informazioni vengono aggregate periodicamente. In tal caso, viene visualizzata una linea blu tratteggiata, insieme al tag Data di aggregazione. Ciò significa che i dati precedenti a tale data appariranno appiattiti rispetto a quelli successivi. Pertanto, quando si utilizza lo strumento di monitoraggio, si consiglia di concentrarsi sugli eventi recenti per ottenere le informazioni più dettagliate possibili.

Nota

Le linee tratteggiate di altri colori ti aiutano a mettere in relazione altre modifiche alla build (importazione del database, git push, ecc.).

Suggerimento

Su ogni grafico, nell’angolo in alto a sinistra viene mostrata l’icona 𝕚 (informazioni). Passa il mouse su di essa per ottenere maggiori dettagli su ciò che rappresenta il grafico.

Metriche

Sistema

Il grafico Memoria mostra le informazioni sull’utilizzo della memoria:

• il contenitore memoria rappresenta i worker di Odoo e i processi del contenitore

• il postgresql della memoria rappresenta il database.

Il grafico CPU mostra le informazioni sull’utilizzo della CPU:

• CPU http rappresenta i worker di Odoo

• CPU cron/mail rappresenta le azioni programmate e le e-mail in arrivo

• CPU postgresql (processi database)

• CPU other rappresenta webshell, editor, ecc.

Il grafico :guilabel:`Archiviazione`mostra le informazioni sull’utilizzo dell’archiviazione:

• il contenitore rappresenta il filestore, i file di log e i file degli utenti

• Postgresql rappresenta il database e gli indici.

HTTP

Il grafico richieste mostra le informazioni sul numero di richieste HTTP per secondo:

• HTTP riuscite rappresenta le richieste avvenute con successo

• errori HTTP rappresenta le richieste non riuscite (consulta odoo.log)

• HTTP limitate per tasso rappresenta le richieste rifiutate, possibilmente a causa di mancanza di worker.

Il grafico richieste concomitanti (max) mostra il numero massimo di richieste HTTP concomitanti al secondo.

Nota

I worker del database determinano il numero di richieste concomitanti che possono essere gestite simultaneamente. È essenziale avere un numero di worker sufficiente per gestire tutte le richieste in entrata al momento dell’arrivo. Tuttavia, avere worker aggiuntivi non migliora la velocità di elaborazione delle richieste.

Il tempo medio di risposta mostra il tempo medio di risposta alle richieste HTTP (in millisecondi).

Email

Il grafico in entrata mostra i dati relativi al numero giornaliero di e-mail in arrivo:

• e-mail ricevute rappresenta le e-mail ricevute con successo

• e-mail ricevute respinte rappresenta le e-mail che non sono state ricevute con successo.

Il grafico in uscita mostra i dati relativi al numero giornaliero di e-mail in uscita:

• e-mail inviate rappresenta le e-mail inviate con successo

• e-mail inviate respinte rappresenta le e-mail inviate senza successo.

Log

La scheda Log offre una vista in tempo reale dei log del server.

Sono disponibili vari registri:

• pip.log: installazione delle dipendenze Python

• install.log: installazione del database (per rami di sviluppo, test inclusi)

• odoosh-import-database.log: ultimo processo di importazione del dump

• odoo.log: server in esecuzione

• update.log: aggiornamenti del database

• pg_slow_queries.log: query psql che richiedono più tempo del previsto

• sh_webshell.log: azioni realizzate nel webshell

• sh_editor.log: azioni realizzate nell’editor

• neutralize.log: neutralizzazione del database (solo staging)

Quando vengono aggiunte nuove righe ai log, queste vengono mostrate automaticamente. Se scorri in basso, il browser scorre automaticamente ogni volta che viene aggiunta una nuova riga.

È possibile mettere in pausa il processo di ottenimento dei log facendo clic sul pulsante (pause) nell’angolo in alto a destra. Al contrario, il processo si interromperà dopo cinque minuti. È possibile riavviarlo facendo clic sul pulsante (play).

Backup

La scheda Backup elenca i backup disponibili per il download e il ripristino e ti consente di eseguire il backup manuale e importare un database.

Il backup del database di produzione viene eseguito automaticamente ogni giorno. Vengono conservati 7 backup giornalieri, quattro settimanali e tre mensili. Ogni backup include il dump del database, il filestore (allegati e campi binari), log e sessioni.

Nota

Puoi consultare la programmazione stimata di backup automatici per capire meglio come funziona il sistema. Questo file viene aggiornato ogni giorno e considera il giorno corrente come punto di partenza.

Il backup dei database di staging e sviluppo non viene eseguito automaticamente. Tuttavia, è possibile ripristinare un backup di un database di produzione nei rami di staging per fare test o recuperare manualmente i dati che sono stati eliminati per errore dal database di produzione.

L’elenco contiene i backup conservati nel server del tuo database di produzione. Questo server conserva solo un mese di backup: sette giornalieri e quattro settimanali.

I server specifici conservano gli stessi backup, così come tre backup mensili aggiuntivi. Per ripristinare o scaricare uno di questi backup mensili, contatta il team di supporto Odoo.

Quando unisci un commit che aggiorna la versione di uno o vari moduli (in __manifest__.py), oppure le dipendenze Python collegate (in requirements.txt), Odoo.sh esegue un backup automatico (contrassegnato come Aggiornamento nell’elenco). Questo accade perché il contenitore viene modificato per l’installazione di nuovi pacchetti pip oppure perché il database cambia con l’aggiornamento del modulo che si attiva in seguito. In entrambi i casi, Odoo.sh crea una copia di sicurezza perché qualcosa potrebbe andare storto.

Se il commit unito non aggiorna la versione di un modulo o delle dipendenze collegate, Odoo.sh non genera nessun backup, perché né il contenitore né il database vengono modificati e la piattaforma considera l’azione sicura. Come precauzione, puoi effettuare un backup manuale prima di modificare il codice di produzione.

Lo scopo dei backup manuali è di creare un’istantanea precisa dei database di produzione o staging (non disponibile per lo sviluppo). Saranno disponibili per sette giorni. Tuttavia, esiste un limite di cinque backup manuali al giorno.

Fase	Backup automatico	Backup manuale
Produzione	Sì (fino a 3 mesi)	Sì (3 giorni)
Staging	No	Sì (3 giorni)
Sviluppo	No	No

La funzionalità Importa database accetta archivi del database da:

• il gestore di database standard id Odoo (disponibile per i server Odoo on-premise in /web/database/manager)

• il gestore di database di Odoo online

• la scheda Backup di Odoo.sh (con il pulsante (Opzioni download)

• la vista build di Odoo.sh (facendo clic su Scarica dump db).

Aggiornamento

La scheda Aggiornamento può essere utilizzata per aggiornare i rami di produzione e staging di progetti validi. Per avere più informazioni sul processo di aggiornamento, consulta la documentazione.

Utensili

La scheda Strumenti contiene il code profiler. Viene utilizzato per avviare una sessione di profiling che registra le attività dei worker di Odoo in esecuzione nell’istanza per un massimo di cinque minuti. Puoi scegliere di chiudere la sessione in anticipo, in quanto l’esecuzione dello strumento per una durata inferiore riduce il rumore nel resoconto.

Dopo ogni sessione, il sistema crea un grafico interattivo con fiamme che ti aiuta a visualizzare come i worker di Odoo assegnano il proprio tempo.

Avvertimento

L’esecuzione del profiler consuma un sacco di risorse del server quindi evita di lasciarlo attivo per molto tempo. L’obiettivo è di registrare un’azione specifica nel database.

Impostazioni

La scheda Impostazioni elenca le opzioni di configurazione disponibili per il ramo selezionato. Le opzioni variano a seconda della fase.

Comportamento alla ricezione di nuovi commit

È possibile modificare il comportamento di un ramo alla ricezione di un nuovo commit per i rami di sviluppo e staging.

Per impostazione predefinita, un rampo di sviluppo crea un nuovo build e un ramo di staging aggiorna il build precedente. Questo è utile se la funzione sulla quale stai lavorando richiede una configurazione specifica, in quanto non avresti bisogno di configurarla manulamente dopo ogni commit.

Se selezioni Nuova build per un ramo di staging, il sistema crea una nuova copia della build di produzione ogni volta che viene inviato un commit.

Un ramo spostato da staging a sviluppo viene configurato automaticamente su Non fare nulla.

Installazione del modulo

Puoi scegliere quali moduli installare automaticamente per i rami di sviluppo.

Per modificare il comportamento predefinito, deseleziona l’opzione Usa predefinito in Comportamento build di sviluppo e seleziona una delle seguenti opzioni in Installazione modulo:

• installa solo i miei moduli (non include moduli secondari): installa solamente i moduli del ramo ed esclude i moduli secondari. Si tratta dell’opzione predefinita

• installazione completa (no suite di prova): installa i moduli del ramo, i moduli secondari e tutti i moduli standard di Odoo. La suite di prova viene disattivata quando viene eseguita l’installazione completa

• installa un elenco di moduli: installa i moduli specificati. Per farlo, inserisci il nome tecnico e separali con virgole (ad es., sale_management,website,accountant).

Nota

Se la suite di prova è attivata, l’installazione di tutti i moduli standard di Odoo può impiegare fino a un’ora.

Suite di prova

La suite di prova per i rami di sviluppo viene attivata per impostazione predefinita. È possibile limitare i test da effettuare digitando tag di prova separati da virgole (ad es. custom_tags,at_install,post_install).

Per disattivare completamente la suite di prova, deseleziona l’opzione Convalida la suite di prova su nuove build.

Versione Odoo

È possibile modificare la versione di Odoo per i rami di sviluppo, ad esempio, per testare del codice aggiornato o sviluppare funzionalità mentre il database di produzione è in fase di aggiornamento a una nuova versione, selezionando un’altra Versione.

L’opzione Più recente è selezionata per impostazione predefinita per il campo Revisione e le fonti del tuo server Odoo vengono aggiornate automaticamente ogni settimana affinché beneficino delle correzioni più recenti di bug, problemi di sicurezza e di prestazione.

Per scegliere invece una revisione specifica, selezionala nel campo Revisione.

Avvertimento

Le revisioni scadono dopo tre mesi. Riceverai una notifica via e-mail quando la data di scadenza della revisione si avvicina. Se non sei ancora intervenuto al momento della scadenza, il campo Revisione torna automaticamente a Più recente.

Domini personalizzati

È possibile configurare domini <name>.odoo.com aggiuntivi oppure i tuoi domini personalizzati per tutti i tipi di rami.

Per utilizzare i tuoi domini personalizzati, è necessario:

• essere proprietario o acquistare il nome di dominio

• inserire il nome di dominio nel campo Domini personalizzati (ad es. www.mycompany.com) e poi fare clic su Aggiungi dominio

• configurare il nome di dominio (ad es. www.mycompany.com) utilizzando il gestore dei nomi di dominio del registratore con un valore record CNAME configurato per il nome di dominio del tuo database di produzione (ad es. mycompany.odoo.com).

Importante

I domini semplici (ad es. mycompany.com) non sono accettati. Possono essere configurati solo utilizzando record A, che accettano solo indirizzi IP come valori. Per questo motivo, un dominio semplice potrebbe smettere di funzionare all’improvviso, in quanto l’indirizzo IP di un database può cambiare (ad es. in seguito a un aggiornamento, al fallimento dell’hardware, alla modifica della posizione di hosting del database).

Per utilizzare il tuo dominio semplice (ad es. mycompany.com) e il dominio www (ad es. www.mycompany.com), è necessario reindirizzare il dominio semplice al dominio www. La maggior parte dei gestori di domini forniscono un modo per configurare il reindirizzamento conosciuto come reindirizzamento web.

HTTPS/SSL

Se il reindirizzamento viene configurato correttamente, un certificato SSL viene generato automaticamente utilizzando Let’s Encrypt in un’ora, il che significa che il dominio sarà accessibile tramite HTTPS.

Conformità SPF e DKIM

Se il dominio dei tuoi indirizzi e-mail usa il protocollo di autenticazione SPF o DKIM, è necessario autorizzare Odoo come host mittente nelle impostazioni del nome di dominio per aumentare il tasso di consegna delle e-mail in uscita. Per maggiori informazioni, consulta la sezione Configurare record DNS per inviare e-mail in Odoo.

Importante

Se Odoo non è autorizzato come host mittente, le e-mail in uscita potrebbero essere contrassegnate come spam.

Comandi shell

Nell’angolo in alto a destra della vista, vengono visualizzati vari comandi shell. I comandi possono essere copiati tramite il pulsante clipboard per poi essere utilizzati in un terminale. Inoltre, alcuni di essi possono essere usati direttamente dall’interfaccia di Odoo.sh.

Clonare

Il comando «clone» viene utilizzato per creare una copia locale del repository Git.

Example

git clone --recurse-submodules --branch development git@github.com:my-organization/my-repository.git

• --recurse-submodules per scaricare i moduli secondari del repository

• --branch main per modificare un ramo specifico del repository (ad es., development)

Nota

Il pulsante di esecuzione non è disponibile in quanto il comando crea una copia locale nella tua macchina.

Fork

Il comando «fork» viene utilizzato per creare un nuovo ramo in base a quello attuale.

Example

git checkout -b main-1 development && git push -u origin development-1

• git checkout -b main-1 main un comando per creare un nuovo ramo (ad es., development-1) in base al ramo corrente (ad es., development)

• git push -u origin development-1 un comando per caricare il nuovo ramo (ad es., development-1) nel repository remoto

Unisci

Il comando «merge» viene utilizzato per unire le modifiche di un branch in un altro.

Example

git merge staging-1 && git push -u origin staging

• git merge staging-1 un comando per unire le modifiche del ramo corrente a un altro ramo (ad es., staging-1)

• git push -u origin staging un comando per caricare le modifiche unite al ramo remoto del repository (ad es., staging)

SSH

Il comando SSH viene utilizzato per collegarsi a una build usando SSH.

Per utilizzare il comando SSH, è necessario prima configurare una chiave SSH. Per farlo:

• genera una nuova chiave SSH

• copia la chiave SSH negli appunti

• in Odoo.sh, fai clic sull’utente GitHub nell’angolo in alto a destra e seleziona Profilo.

  

• copia la chiave SSH nel campo Aggiungi chiave manualmente e fai clic su Aggiungi.

  

Example

ssh 25004381@my-user-my-repository-staging-25004381.dev.odoo.com

• 25004381 è l’ID della build

• my-user-my-repository-staging-25004381.dev.odoo.com è il dominio utilizzato per collegarsi alla build

Riceverai accesso SSH alla build una volta confermati i diritti di accesso necessari nel progetto.

Nota

Le connessioni SSH di lunga durata non sono garantite. Le connessioni non attive possono disconnettersi per liberare risorse.

Modulo secondario

Il comando «submodule» viene utilizzato per aggiungere un ramo da un altro repository al ramo corrente come modulo secondario.

Vedi anche

Documentazione moduli secondari

Example

git submodule add -b master <URL> <PATH> && git commit -a && git push -u origin staging

• git submodule add -b master <URL> <PATH> un comando per aggiungere un ramo specifico (ad es., master) di un repository (<URL>) come modulo secondario del percorso specificato (<PATH>) nel tuo ramo attuale.

• git commit -a un comando per eseguire il commit di tutte le modifiche correnti

• git push -u origin staging è un comando per inviare i cambi del ramo attuale (ad es., staging) al repository remoto.

Elimina

Il comando «delete» viene utilizzato per eliminare un ramo dal repository.

Nota

Una volta eliminato un ramo, non è possibile recuperarlo tranne se si dispone di un backup. Il backup dei rami di staging non viene effettuato automaticamente ma può essere eseguito manualmente. Non è possibile eseguire backup per i rami di sviluppo.

Example

git push origin :staging && git branch -D staging

• git push origin :staging un comando per eliminare un ramo specifico (e.g., staging) dal repository remoto

• git branch -D staging un comando per eliminare un ramo specifico dalla copia locale del repository

Avvertimento

Prima di eliminare un ramo, consulta la :ref:`sezione relativa ai backup <odoo-sh/branches/tabs/backups>`per capire meglio come funzionano e quando è necessario crearne uno manualmente.