Impostazioni

Panoramica

Le impostazioni consentono di gestire la configurazione del tuo progetto.

Nome progetto

Il nome del tuo progetto.

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.

There are three levels of users:

• Admin: has access to all features of an Odoo.sh project.

• Tester: has access to the Staging and Development databases and their tooling. This role is for users conducting User Acceptance Tests. Testers can work with copies of production data but cannot access the production database through the Odoo.sh tooling.

• Developer: has access only to the Development databases and their tooling. This role is for developers who propose code modifications but are not allowed to access production and staging databases through the Odoo.sh tooling.

		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

Those roles only apply to the usage of Odoo.sh. It is important to reflect the user roles attribution within the repository on GitHub. Please refer to the GitHub documentation section on Managing a branch protection rule for detailed guidance.

Accesso pubblico

Consenti l’accesso pubblico ai tuoi build di sviluppo.

If activated, this option exposes the Builds page publicly, allowing visitors to view logs of development builds.

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

GitHub commit statuses

This option enables Odoo.sh to push commit statuses to your GitHub repository when a build is created or updated. It requires a GitHub token with permissions to push commit statuses to the repository. Refer to GitHub’s documentation on personal access tokens for instructions to create yours.

Nota

GitHub’s fine-grained personal tokens have an expiration date and will be disabled if they fail to update the commit status. You can replace the token at any time on Odoo.sh.

The commit statuses pushed to GitHub can have the following contexts:

• ci/odoo.sh (dev): status of a development build

• ci/odoo.sh (staging): status of a staging build

• ci/odoo.sh (production): status of a production build

• ci/odoo.sh (test_ci): testing the token from the Settings page will push a test status on the last commit of your repository

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.

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.

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.

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.

Attivazione

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