Impostazioni

Panoramica

Le impostazioni consentono di gestire la configurazione del tuo progetto.

../../../_images/interface-settings.png

Nome progetto

Il nome del tuo progetto.

../../../_images/interface-settings-projectname.png

Definisce l’indirizzo che verrà utilizzato per accedere al database di produzione.

Gli indirizzi dei build di staging e di sviluppo derivano da questo nome e sono assegnati in modo automatico. Tuttavia, quando modifichi il nome del tuo progetto, solo i build futuri utilizzeranno il nuovo nome.

Collaboratori

Gestisci gli utenti Github che possono accedere al progetto.

../../../_images/interface-settings-collaborators.png

Esistono tre livelli di utenti:

  • Admin: ha accesso a tutte le funzionalità di un progetto Odoo.sh

  • Tester: ha accesso ai database di staging e sviluppo e ai rispettivi strumenti. Questo ruolo è per gli utenti che effettuano test di accettazione utenti. I tester possono lavorare con copie dei dati di produzione ma non possono accedere ai database di produzione attraverso gli strumenti di Odoo.sh.

  • Developer: ha accesso esclusivamente ai database di sviluppo e ai relativi strumenti. Questo ruolo è per sviluppatori che propongono modifiche del codice ma non possono accedere ai database di produzione e staging tramite Odoo.sh.

Sviluppatore

Tester

Amministratore

Sviluppo

Cronologia

Connessione 1 clic

Log

Shell/SSH

Email

Impostazioni

Staging

Cronologia

Connessione 1 clic

Log

Shell/SSH

Email

Monitoraggio

Backup

Aggiorna

Impostazioni

Produzione

Cronologia

Connessione 1 clic

Log

Shell/SSH

Email

Monitoraggio

Backup

Aggiorna

Impostazioni

Stato

Impostazioni

Avvertimento

I ruoli descritti si applicano solo all’utilizzo di Odoo.sh. È importante riportare l’attribuzione dei ruoli degli utenti all’interno del repository su GitHub. Per avere informazioni più dettagliate, consulta la sezione della documentazione di GitHub Gestire una regola di protezione di un ramo.

Accesso pubblico

Consenti l’accesso pubblico ai tuoi build di sviluppo.

../../../_images/interface-settings-public.png

Se attivata, l’opzione rende pubblica la pagina relativa ai build, permettendo ai visitatori di visualizzare i registri dei build di sviluppo.

I build di produzione e staging sono esclusi, i visitatori possono solo vederne lo stato.

Stati commit GitHub

Una volta attivata, l’opzione permette a Odoo.sh di inviare gli stati dei commit alla repository di GitHub quando un build viene creato o aggiornato. Per farlo, è necessario avere il token GitHub con i permessi adatti. Consulta la documentazione di GitHub sui token di accesso personale per scoprire come creare il tuo.

Nota

I token personali dettagliati di GitHub hanno una data di scadenza e verranno disattivati se l’aggiornamento allo stato del commit fallisce. Puoi sostituire il token in qualsiasi momento su Odoo.sh.

Gli stati dei commit inviati a GitHub possono avere i seguenti contesti:

  • ci/odoo.sh (dev): stato di un build di sviluppo

  • ci/odoo.sh (staging): stato di un build di staging

  • ci/odoo.sh (production): stato di un build di produzione

  • ci/odoo.sh (test_ci): se il token viene testato dalla pagina delle impostazioni, all’ultimo commit nella repository verrà inviato uno stato di test

Domini personalizzati

Per configurare domini aggiuntivi, fai riferimento alla scheda impostazioni del ramo corrispondente.

Moduli secondarii

Configura le chiavi di distribuzione per gli archivi privati che utilizzi come moduli secondari nei tuoi rami per consentire a Odoo.sh di scaricarli.

Avvertimento

Queste impostazioni sono richieste solo per archivi privati. Se sei alla ricerca di come configurare i moduli secondari, le istruzioni sono disponibili al capitolo Moduli secondari della documentazione.

../../../_images/interface-settings-submodules.png

Quando un archivio è privato, non è possibile scaricarne pubblicamente i rami e le revisioni. Per questo motivo, è necessario configurare una chiave di distribuzione per Odoo.sh, in modo che il server Git remoto permetta alla nostra piattorma di scaricare le revisioni dell’archivio privato.

La configurazione di una chiave di distribuzione per un archivio priviato avviene seguendo questi step:

  • nella casella di testo, incolla l’URL SSH del sub-archivio privato e fai clic su Add;

    • ad es. git@github.com:USERNAME/REPOSITORY.git;

    • può trattarsi di un server Git diverso da Github, come Bitbucket, Gitlab o anche il proprio server di host;

  • copia la chiave pubblica;

    • dovrebbe somigliare a ssh-rsa some…random…characters…here…==;

  • nelle impostazioni del sub-archivio privato, aggiungi la chiave pubblica tra le chiavi di distribuzione;

    • Github.com: Settings ‣ Deploy keys ‣ Add deploy key

    • Bitbucket.com: Settings ‣ Access keys ‣ Add key

    • Gitlab.com: Settings ‣ Repository ‣ Deploy Keys

    • self-hosted: aggiunge la chiave al file authorized_keys dell’utente git nella cartella .ssh corrispondente.

Dimensioni di archiviazione

La sezione illustra le dimensioni di archiviazione utilizzate dal tuo progetto.

../../../_images/interface-settings-storage.png

Le dimensioni di archiviazione sono calcolate come segue:

  • la dimensione del database PostgreSQL;

  • la dimensione dei file del disco disponibile nel contenitore: filestore del database, cartella archiviazione sessioni…

Avvertimento

In caso tu voglia analizzare l’utilizzo del disco, puoi utilizzare lo strumento ncdu  nella Web Shell.

Se le dimensioni del tuo database di produzione aumentano fino a superare quanto stabilito dall’abbonamento, la sincronizzazione sarà automatica.

Worker del database

Worker aggiuntivi per il database possono essere configurati qui. Un numero maggiore di worker aiuta ad aumentare il carico che il database di produzione può gestire. Se ne aggiungi altri, il tutto verrà automaticamente sincronizzato con l’abbonamento.

../../../_images/interface-settings-workers.png

Avvertimento

L’aggiunta di worker non risolverà magicamente i problemi di prestazione. Consente solo al servere di gestire più connessioni allo stesso tempo. Se alcune operazioni sono stranamente lente, è probabile che si tratti di un problema di codice, se non dipende dalle personalizzazioni puoi aprire un ticket qui.

Rami di staging

Rami di staging aggiuntivi permettono di sviluppare e testare più funzionalità allo stesso tempo. Se ne aggiungi uno, verrà sincronizzato automaticamente con l’abbonamento.

../../../_images/interface-settings-staging-branches.png

Attivazione

Mostra lo stato di attivazione del progetto. È possibile modificare il codice di attivazione del progetto se necessario.

../../../_images/interface-settings-activation.png