Ramuri

Vizualizarea Ramuri oferă o prezentare generală a diferitelor ramuri din repository-ul dvs.

Etape

Odoo.sh oferă trei etape diferite de ramură:

Puteți schimba etapa unei ramuri trăgând și plasând-o sub etapa dorită.

Schimbarea etapei unei ramuri

Notă

  • Ramurile de dezvoltare pot fi mutate sub Pregătire. Dacă încercați să mutați o ramură de dezvoltare sub Producție, va fi afișat un mesaj de avertizare care explică faptul că puteți avea doar o singură ramură de producție per proiect.

  • Ramurile de pregătire pot fi mutate sub Dezvoltare, dar nu este posibil să le mutați sub Producție.

  • Ramura de producție poate fi mutată doar sub Dezvoltare. Dacă încercați să o mutați sub Pregătire, puteți efectua doar o îmbinare. Consultați secțiunea îmbinare pentru o explicație detaliată a acestui proces.

Producție

Ramura de producție conține codul utilizat pentru a rula baza de date de producție. Poate exista doar o singură ramură de producție.

Când trimiteți o nouă confirmare către această ramură, serverul de producție este actualizat cu codul revizuit și repornit.

Dacă modificările necesită o actualizare de modul, cum ar fi modificarea unei vizualizări de formular, și doriți ca actualizarea să fie efectuată automat, puteți crește numărul versiunii modulului în fișierul său manifest (__manifest__.py). Platforma efectuează apoi actualizarea, în timpul căreia instanța va fi temporar indisponibilă din motive de întreținere.

Această metodă este echivalentă cu actualizarea modulului folosind meniul Aplicații sau comutatorul -u în linia de comandă.

Notă

  • Dacă modificările împiedică repornirea serverului sau dacă actualizarea modulului eșuează, serverul este automat revertat la revizia de cod reușită anterioară, iar baza de date este restaurată la starea sa anterioară. Accesați jurnalul actualizării eșuate pentru a depana problema.

  • Datele demo nu sunt încărcate, deoarece nu sunt destinate utilizării pe o bază de date de producție. Testele unitare nu sunt efectuate, deoarece ar crește timpul de indisponibilitate al bazei de date de producție în timpul actualizării.

Odoo.sh realizează automat copii de siguranță ale bazei de date de producție. Păstrează șapte copii zilnice, patru săptămânale și trei lunare. Fiecare copie de siguranță include dumping-ul bazei de date, stocarea fișierelor (atașamente și câmpuri binare), jurnale și sesiuni.

Atenționare

Când folosiți proiecte de probă, ramura de producție și toate ramurile de pregătire sunt automat setate înapoi la etapa de dezvoltare după 30 de zile.

Stagiu

Ramurile de pregătire sunt destinate testării noilor funcționalități folosind date de producție fără a compromite baza de date de producție reală cu înregistrări de test. Acestea creează duplicate neutralizate ale bazei de date de producție.

Neutralizarea dezactivează:

  • Acțiuni planificate

    Notă

    Pentru a le testa, declanșați-le manual sau reactivați-le. Rețineți că platforma le va declanșa mai rar dacă nimeni nu folosește baza de date, pentru a economisi resurse.

  • E-mailuri trimise

    Notă

    Acestea sunt interceptate folosind un captator de e-mailuri. O interfață pentru vizualizarea e-mailurilor trimise de baza de date este furnizată în proiectul dvs. Odoo.sh. Astfel, niciun e-mail nu este trimis contactelor dvs.

  • Servicii IAP

  • Furnizori de plăți și conectori de livrare

    Notă

    Acestea sunt puse în modul de testare.

Dacă configurați sau vizualizați modificări într-o bază de date de testare, asigurați-vă că le înregistrați (notându-le pas cu pas, reproducându-le în producție etc.) sau scrieți-le direct în modulele ramurii, folosind fișiere de date XML pentru a suprascrie configurația sau vizualizările implicite. Consultați documentația primului modul pentru a vedea exemple.

Notă

Testele unitare nu sunt efectuate. Acestea se bazează pe date demonstrative, care nu sunt încărcate în bazele de date de producție și de testare. Dacă Odoo va suporta rularea unităților fără date demonstrative, Odoo.sh va lua în considerare rularea testelor pe bazele de date de testare.

Bazele de date de testare nu sunt salvate automat. Cu toate acestea, puteți restaura o copie de rezervă a bazei de date de producție într-o ramură de testare în scopuri de testare sau pentru a recupera manual datele care au fost șterse accidental din baza de date de producție. Este posibilă crearea de copii de rezervă manuale ale bazelor de date de testare.

Atenționare

Bazele de date create pentru ramurile de testare sunt șterse automat după o lună. Pentru a folosi din nou ramura, trebuie să o reconstruiți.

Dezvoltare

Ramurile de dezvoltare creează baze de date noi folosind date demonstrative pentru a rula testele unitare. Modulele instalate sunt cele incluse în ramură. Puteți modifica această listă de module de instalat în setările proiectului.

Când trimiteți o commit către o ramură de dezvoltare, este pornit un nou server, cu o bază de date creată de la zero, și ramura este actualizată. Datele demonstrative sunt încărcate, iar testele unitare sunt efectuate implicit pentru a verifica că modificările nu afectează niciuna dintre funcționalitățile testate. Puteți dezactiva testele sau permite rularea anumitor teste cu etichete personalizate accesând setările ramurii.

Similar cu ramurile de testare, e-mailurile nu sunt trimise, ci sunt interceptate de un captator de e-mailuri, iar acțiunile programate nu sunt declanșate atâta timp cât baza de date nu este utilizată.

Bazele de date de dezvoltare nu sunt salvate automat, iar copiile de rezervă manuale nu sunt posibile.

Atenționare

Bazele de date create pentru ramurile de dezvoltare sunt destinate să dureze aproximativ trei zile. După aceea, pot fi colectate automat ca gunoi pentru a face loc noilor baze de date, fără notificare prealabilă.

Îmbinarea ramurilor

Puteți îmbina ramurile trăgându-le și plasându-le una în alta.

Îmbinarea ramurilor una în alta

Pentru a testa modificările ramurilor de dezvoltare cu datele de producție, puteți fie:

  • Îmbina ramura de dezvoltare într-o ramură de testare trăgând-o și plasând-o pe ramura dorită; sau

    Fuzionarea unei ramuri de dezvoltare într-o ramură de staging
  • Trageți și plasați ramura de dezvoltare sub secțiunea Staging pentru a o transforma într-o ramură de staging.

    Mutarea unei ramuri de dezvoltare sub staging

Când modificările sunt gata pentru producție, trageți și plasați ramura de staging în ramura de producție pentru a le fuziona și implementa.

Notă

  • Puteți fuziona ramurile de dezvoltare direct în ramura de producție. Cu toate acestea, modificările nu vor fi validate în raport cu datele de producție printr-o ramură de staging, astfel încât există un risc mai mare de a întâmpina probleme în baza de date de producție.

  • Puteți fuziona ramurile de dezvoltare între ele și ramurile de staging între ele.

  • De asemenea, puteți folosi git merge direct pe stația dvs. de lucru pentru a fuziona ramurile. Odoo.sh este notificat când sunt trimise revizii noi către ramurile dvs.

Fuzionarea unei ramuri de staging în ramura de producție fuzionează doar codul sursă. Orice modificări efectuate în baza de date de staging nu sunt transferate în baza de date de producție. Cu toate acestea, dacă modificați codul din depozit, acesta va fi transferat în ramura de producție la fuzionare.

Dacă testați modificări de configurație în ramurile de staging și doriți ca acestea să fie aplicate ramurii de producție, trebuie să:

  • Scrieți modificările de configurație în fișiere de date XML pentru a suprascrie configurația implicită sau vizualizările din ramură, apoi creșteți versiunea modulului în manifestul său (__manifest__.py) pentru a declanșa actualizarea modulului la fuzionarea ramurii de staging în ramura de producție.

    Notă

    Această metodă este recomandată pentru o mai bună scalabilitate a dezvoltărilor dvs., deoarece veți folosi funcțiile de versionare Git pentru toate modificările de configurație, asigurând astfel trasabilitatea modificărilor dvs.

  • Le transferați manual din baza de date de staging în cea de producție prin copiere și lipire.

Tab-uri

Istoric

Fila History oferă o prezentare generală a istoricului ramurii:

  • Mesajele de commit și autorii lor

  • Diversele evenimente legate de platformă, cum ar fi schimbările de etapă, importurile de baze de date și restaurările de copii de siguranță

Fila de istoric a ramurilor

Un status în colțul din dreapta sus al fiecărui eveniment indică operațiunea curentă pe baza de date (de ex., instalare, actualizare, import de copie de siguranță) sau rezultatul acesteia (de ex., feedback de testare, import de copie de siguranță reușit). Dacă o operațiune reușește, apare un buton Connect, permițându-vă să accesați baza de date.

Mail-uri

Fila Mails conține captorul de e-mailuri, care oferă o prezentare generală a e-mailurilor trimise de baza de date.

Notă

Captorul de e-mailuri este disponibil pentru ramurile de dezvoltare și staging. E-mailurile din baza de date de producție sunt efectiv trimise și nu sunt interceptate de captorul de e-mailuri.

Fila de e-mailuri a ramurilor

Shell

Shell oferă acces shell la container.

Clic pe Shell deschide o filă nouă de browser unde puteți rula comenzi Linux de bază (ls, top). Puteți deschide un shell pe baza de date rulând psql.

Fila shell a ramurilor

Sfat

Puteți deschide mai multe file shell simultan și le puteți aranja dispunerea prin glisare și plasare.

Notă

  • Shell-urile instanțelor de producție sunt evidențiate în roșu pentru a sublinia pericolul manipulării directe a instanțelor de producție, în timp ce shell-urile instanțelor de staging/dezvoltare sunt evidențiate în galben.

  • Instanțele shell care rulează mult timp/sesiunile shell inactive pot fi terminate oricând pentru a elibera resurse.

Comenzi

Iată o prezentare generală a comenzilor utile pe care le puteți rula într-un terminal de bază de date Odoo.sh:

  • odoo-bin shell: pentru a deschide un shell Odoo

  • odoo-update: pentru a actualiza modulele din baza de date

  • odoosh-restart: pentru a reporni serviciile Odoo.sh (http sau cron)

  • odoosh-storage: pentru a verifica utilizarea spațiului de stocare al sistemului de fișiere al containerului instanței

  • psql: pentru a deschide un shell de bază de date

  • mutt: pentru a verifica cum apar e-mailurile pe clienții text (instanțe de staging și dezvoltare)

  • lnav ~/logs/odoo.log: pentru a naviga în fișierul odoo.log al instanței

  • ncdu: pentru a lansa analizatorul de utilizare a discului cu o interfață interactivă

  • grep: pentru a filtra și găsi informații în fișierele jurnal sau de configurare

Editor

Clic pe Editor deschide o filă nouă de browser pentru a accesa un mediu de dezvoltare integrat (IDE) online pentru a edita codul sursă. Puteți deschide, de asemenea, terminale, console Python și console shell Odoo.

Fila editor a ramurilor

Puteți deschide mai multe file și le puteți glisa și plasa pentru a aranja dispunerea după cum doriți.

Monitor

Fila Monitor afișează diverse valori de monitorizare a performanței pentru versiunea curentă.

Măriți cu cursorul pentru a ajusta intervalul de timp sau selectați-l manual din selectorul de interval de timp. Este posibil și să schimbați fusul orar.

Selectorul de interval de timp din fila de monitorizare a ramurilor

Notă

  • Jurnalele tehnice utilizează întotdeauna UTC. Pentru a analiza aceste jurnale împreună cu valorile de monitorizare, asigurați-vă că UTC este selectat în instrumentul de monitorizare.

  • Similar, atunci când trimiteți un tichet de asistență, asigurați-vă că informațiile pe care le partajați se bazează pe UTC, deoarece Odoo utilizează acest fus orar pentru a investiga problemele de performanță.

Informațiile sunt agregate periodic. Când acesta este cazul, se afișează o linie punctată albastră, împreună cu eticheta Aggregate Date. Aceasta înseamnă că datele anterioare acestei date vor apărea aplatizate în comparație cu datele de după această dată. Prin urmare, atunci când utilizați instrumentul de monitorizare, se recomandă concentrarea pe evenimentele recente pentru a obține informațiile cât mai detaliate posibil.

Notă

Liniile punctate de alte culori vă ajută să identificați alte modificări ale versiunii (import de bază de date, git push etc.).

Date agregate de monitorizare CPU

Sfat

Pe fiecare grafic, o pictogramă 𝕚 (informații) este afișată în colțul din stânga sus. Treceți cu mouse-ul peste aceasta pentru a obține mai multe detalii despre ce reprezintă graficul.

Valori

Sistem

Graficul Memory afișează informații despre consumul de memorie:

  • Memory container reprezintă workerii Odoo și procesele containerului.

  • Memory postgresql reprezintă baza de date.

Graficul de memorie din fila de monitorizare

Graficul CPU afișează informații despre consumul de CPU:

  • CPU http reprezintă workerii Odoo.

  • CPU cron/mail reprezintă acțiunile programate și e-mailurile primite.

  • CPU postgresql (procese bază de date)

  • CPU other reprezintă webshells, editor etc.

Graficul cpu din fila monitor

Graficul Storage afișează informații despre spațiul de stocare utilizat:

  • Container reprezintă filestore, fișiere jurnal și fișiere utilizator.

  • Postgresql reprezintă baza de date și indexurile.

Graficul de stocare din fila monitor
HTTP

Graficul Requests afișează informații despre numărul de cereri HTTP pe secundă:

  • HTTP successes reprezintă cererile reușite.

  • HTTP errors reprezintă cererile eșuate (verificați odoo.log).

  • HTTP rate limited reprezintă cererile respinse, posibil din cauza lipsei de workers.

Graficul cererilor din fila monitor

Graficul Concurrent requests (max) afișează numărul maxim de cereri HTTP concurente pe secundă.

Graficul cererilor concurente din fila monitor

Notă

Workers-ii bazei de date determină numărul de cereri concurente care pot fi gestionate simultan. Este esențial să existe suficienți workers pentru a gestiona toate cererile primite pe măsură ce sosesc. Totuși, a avea mai mulți workers peste acest număr nu îmbunătățește viteza cu care sunt procesate cererile.

Graficul Average Response time afișează timpul mediu de răspuns la cererile HTTP (în milisecunde).

Graficul timpului mediu de răspuns din fila monitor
Mail-uri

Graficul Incoming afișează date despre numărul zilnic de e-mailuri primite:

  • Received Emails reprezintă e-mailurile primite cu succes.

  • E-mailuri primite returnate reprezintă e-mailurile primite fără succes.

Graficul de intrare în fila monitor

Graficul Ieșire afișează date despre numărul zilnic de e-mailuri trimise:

  • E-mailuri trimise reprezintă e-mailurile trimise cu succes.

  • E-mailuri trimise returnate reprezintă e-mailurile trimise fără succes.

Graficul de ieșire în fila monitor

Jurnale

Fila Jurnale oferă o vizualizare în timp real a jurnalelor serverului.

Fila jurnal ramuri

Sunt disponibile diferite jurnale:

  • pip.log: instalarea dependențelor Python

  • install.log: instalarea bazei de date (pentru ramurile de dezvoltare, sunt incluse teste)

  • odoosh-import-database.log: ultimul proces de import al dump-ului

  • odoo.log: serverul care rulează

  • update.log: actualizările bazei de date

  • pg_slow_queries.log: interogări psql care durează o perioadă neobișnuit de lungă

  • sh_webshell.log: acțiunile efectuate în webshell

  • sh_editor.log: acțiunile efectuate în editor

  • neutralize.log: neutralizarea bazei de date (numai staging)

Derulare automată a jurnalelor

Când sunt adăugate linii noi la jurnale, acestea sunt afișate automat. Dacă derulați până jos, browserul derulează automat de fiecare dată când este adăugată o linie nouă.

Puteți întrerupe procesul de preluare a jurnalelor făcând clic pe butonul (pauză) din colțul din dreapta sus. În caz contrar, procesul se oprește după cinci minute. Puteți reporni procesul făcând clic pe butonul (redare).

Copii de rezervă

Fila Backups listează copiile de siguranță disponibile pentru descărcare și restaurare, vă permite să efectuați o copie de siguranță manuală și să importați o bază de date.

Fila cu copii de siguranță ale ramurilor

Baza de date de producție este salvată automat zilnic. Sunt păstrate șapte copii de siguranță zilnice, patru săptămânale și trei lunare. Fiecare copie de siguranță include dump-ul bazei de date, filestore-ul (atașamente și câmpuri binare), jurnale și sesiuni.

Notă

Puteți consulta programarea estimată a copiilor de siguranță automate pentru a înțelege mai bine cum funcționează sistemul. Acest fișier este actualizat zilnic, luând ziua curentă ca punct de plecare.

Bazele de date de staging și dezvoltare nu sunt salvate automat. Totuși, puteți restaura o copie de siguranță a bazei de date de producție în ramurile dumneavoastră de staging, în scopuri de testare, sau puteți recupera manual datele care au fost șterse accidental din baza de date de producție.

Lista conține copiile de siguranță păstrate pe serverul bazei dumneavoastră de date de producție. Acest server păstrează doar o lună de copii de siguranță: șapte copii zilnice și patru săptămânale.

Serverele dedicate de backup păstrează aceleași copii de siguranță, precum și trei copii lunare suplimentare. Pentru a restaura sau descărca una dintre aceste copii de siguranță lunare, contactați Asistența Odoo.

La fuzionarea unui commit care actualizează versiunea unuia sau mai multor module (în __manifest__.py), sau a dependențelor Python asociate (în requirements.txt), Odoo.sh efectuează o copie de siguranță automată (marcată cu tipul Update în listă), deoarece fie containerul va fi modificat prin instalarea de noi pachete pip, fie baza de date însăși va fi modificată prin actualizarea modulului declanșată ulterior. În aceste două cazuri, o copie de siguranță este declanșată deoarece poate strica ceva.

Dacă commit-ul fuzionat nu actualizează versiunea unui modul sau dependențele asociate, atunci nicio copie de siguranță nu este declanșată de Odoo.sh, deoarece nici containerul, nici baza de date nu sunt modificate; prin urmare, platforma consideră că este suficient de sigur. Ca precauție suplimentară, puteți face o copie de siguranță manuală înainte de a modifica sursele de producție.

Scopul copiilor de siguranță manuale este de a crea un instantaneu specific al bazelor de date de producție sau staging (nu este disponibil pentru dezvoltare). Acestea rămân disponibile timp de șapte zile. Totuși, există o limită de cinci copii de siguranță manuale zilnice.

Etapă

Copie de siguranță automată

Copie de siguranță manuală

Producție

Da (până la 3 luni)

Da (3 zile)

Stagiu

Nu

Da (3 zile)

Dezvoltare

Nu

Nu

Funcția Import Database acceptă arhive de baze de date de la:

  • managerul standard de baze de date Odoo (disponibil pentru servere Odoo on-premise la /web/database/manager)

  • managerul de baze de date Odoo Online

  • fila Backups din Odoo.sh (utilizând butonul (Download Options))

  • vizualizarea Builds Odoo.sh (prin clic pe Download DB dump)

Actualizează

Fila Upgrade poate fi folosită pentru a actualiza ramurile de producție și staging ale proiectelor valide. Pentru mai multe informații despre procesul de actualizare, consultați documentația despre actualizare.

Fila de actualizare a ramurilor

Instrumente

Fila Tools conține profilerul de cod. Este folosită pentru a porni o sesiune de profilare, înregistrând activitățile lucrătorilor Odoo care rulează în instanță pentru maximum cinci minute. Puteți alege să terminați sesiunea mai devreme, deoarece rularea instrumentului pentru o durată mai scurtă reduce cantitatea de zgomot din raport.

Utilizarea profilerului de cod

După fiecare sesiune, este creat un grafic interactiv flame pentru a vă ajuta să vizualizați cum își alocă lucrătorii Odoo timpul.

Atenționare

Rularea profilerului consumă multe resurse ale serverului, așa că evitați să îl lăsați să ruleze prea mult timp. Scopul este de a înregistra o acțiune specifică în baza de date.

Setări

Fila Settings listează opțiunile de configurare disponibile pentru ramura selectată curent. Opțiunile variază pentru fiecare etapă.

Fila de setări a ramurilor

Comportament la primirea de noi commit-uri

Puteți schimba comportamentul ramurii la primirea unui nou commit pentru ramurile de dezvoltare și staging.

În mod implicit, o ramură de dezvoltare creează un build nou, iar o ramură de staging actualizează build-ul anterior. Acest lucru este util dacă funcționalitatea la care lucrați necesită o configurație specifică, deoarece nu va trebui să o configurați manual din nou după fiecare commit.

Dacă selectați New build pentru o ramură de staging, o copie nouă a build-ului de producție este creată de fiecare dată când este trimis un commit.

O ramură care este mutată din staging în dezvoltare este setată automat la Do nothing.

Instalarea modulelor

Puteți alege ce module ar trebui să fie instalate automat pentru ramurile de dezvoltare.

Instalarea modulelor în fila de setări

Pentru a schimba comportamentul implicit, debifați opțiunea Use Default de sub Development build behavior și selectați una dintre următoarele opțiuni de sub Module Installation:

  • Install only my modules (does not include submodules): instalează doar modulele ramurii, excluzând submodulele. Aceasta este opțiunea implicită.

  • Instalare completă (fără suită de teste): instalează modulele ramurii, submodulele și toate modulele standard Odoo. La rularea instalării complete, suita de teste este dezactivată.

  • Instalează o listă de module: instalează modulele specificate. Pentru aceasta, introdu numele lor tehnic și separă-le folosind virgule (de exemplu, sale_management,website,accountant).

Notă

Dacă suita de teste este activată, instalarea tuturor modulelor standard Odoo poate dura până la o oră.

Suită de teste

În mod implicit, suita de teste pentru ramurile de dezvoltare este activată. Poți restricționa testele care sunt rulate introducând etichete de test și separându-le folosind virgule (de exemplu, custom_tags,at_install,post_install).

Pentru a dezactiva complet suita de teste, debifează Validează suita de teste la noi versiuni.

Versiunea Odoo

Poți schimba versiunea Odoo pentru ramurile de dezvoltare, de exemplu, pentru a testa cod actualizat sau a dezvolta funcționalități în timp ce baza de date de producție este în curs de actualizare la o versiune mai nouă, selectând o altă Versiune.

În mod implicit, Cea mai recentă este selectată ca Revizie, iar sursele serverului Odoo sunt actualizate automat săptămânal pentru a beneficia de cele mai recente corecții de erori, securitate și performanță.

Pentru a alege o revizie specifică, selectează-o folosind câmpul Revizie.

Atenționare

Reviziile expiră după trei luni. Vei fi notificat prin e-mail când data de expirare a reviziei se apropie. Dacă nu ai luat nicio măsură când expiră, câmpul Revizie este resetat automat la Cea mai recentă.

Reviziile filei de setări

Domenii personalizate

Poți configura domenii <nume>.odoo.com suplimentare sau propriile tale domenii personalizate pentru toate tipurile de ramuri.

Pentru a folosi propriul domeniu personalizat, este necesar să:

  • Deții sau achiziționezi numele de domeniu.

  • Introdu numele de domeniu sub Domenii personalizate (de exemplu, www.mycompany.com), apoi dă clic pe Adaugă domeniu.

  • Configurează numele de domeniu (de exemplu, www.mycompany.com) folosind managerul de domenii al registratorului tău cu o valoare de înregistrare CNAME setată la numele de domeniu al bazei de date de producție (de exemplu, mycompany.odoo.com).

Important

Domeniile goale (de exemplu, mycompany.com) nu sunt acceptate. Acestea pot fi configurate doar folosind înregistrări A, care acceptă doar adrese IP ca valoare. Prin urmare, un domeniu gol ar putea înceta brusc să funcționeze, deoarece adresa IP a unei baze de date se poate schimba (de exemplu, în urma unei actualizări, a unei defecțiuni hardware, a unei schimbări a locației de găzduire a bazei de date).

Pentru ca atât domeniul gol (de exemplu, mycompany.com), cât și domeniul www (de exemplu, www.mycompany.com) să funcționeze, este necesar să redirectezi domeniul gol către domeniul www. Majoritatea managerilor de domenii oferă o modalitate de a configura această redirecționare, denumită în mod obișnuit redirecționare web.

HTTPS/SSL

Dacă redirecționarea este configurată corect, un certificat SSL este generat automat folosind Let’s Encrypt în decurs de o oră, ceea ce înseamnă că domeniul dvs. va fi accesibil prin HTTPS.

Conformitate SPF și DKIM

Dacă domeniul adreselor dvs. de e-mail folosește protocolul de autentificare SPF sau DKIM, este necesar să autorizați Odoo ca gazdă de trimitere în setările numelui de domeniu pentru a crește livrabilitatea e-mailurilor trimise. Pentru mai multe informații, consultați documentația Configurați înregistrările DNS pentru a trimite e-mailuri în Odoo.

Important

Dacă Odoo nu este autorizat ca gazdă de trimitere, e-mailurile dvs. trimise pot fi marcate ca spam.

Comenzi shell

În colțul din dreapta sus al vizualizării sunt afișate mai multe comenzi shell. Comenzile pot fi copiate folosind butonul clipboard și apoi folosite într-un terminal. În plus, unele dintre ele pot fi folosite direct din interfața Odoo.sh.

Comenzile rapide shell pentru ramuri

Clone

Comanda clone este folosită pentru a crea o copie locală a depozitului dvs. Git.

Example

git clone --recurse-submodules --branch development git@github.com:my-organization/my-repository.git
  • --recurse-submodules pentru a descărca submodulele depozitului dvs.

  • --branch main pentru a comuta la o ramură specifică a depozitului (de ex., development)

Notă

Butonul run nu este disponibil deoarece comanda este folosită pentru a crea o copie locală pe mașina dvs.

Fork

Comanda fork este folosită pentru a crea o ramură nouă bazată pe cea curentă.

Example

git checkout -b main-1 development && git push -u origin development-1
  • git checkout -b main-1 main o comandă pentru a crea o ramură nouă (de ex., development-1) bazată pe ramura curentă (de ex., development)

  • git push -u origin development-1 o comandă pentru a încărca ramura nouă (de ex., development-1) în depozitul la distanță

Îmbină

Comanda merge este folosită pentru a combina modificările dintr-o ramură în altă ramură.

Example

git merge staging-1 && git push -u origin staging
  • git merge staging-1 o comandă pentru a îmbina modificările ramurii curente într-o altă ramură (de ex., staging-1)

  • git push -u origin staging o comandă pentru a încărca modificările îmbinate în ramura depozitului la distanță (de ex., staging)

SSH

Comanda SSH este folosită pentru a se conecta la o compilare folosind SSH.

Pentru a folosi comanda SSH, este necesar să configurați mai întâi o cheie SSH. Pentru aceasta:

Example

ssh 25004381@my-user-my-repository-staging-25004381.dev.odoo.com
  • 25004381 ID-ul build-ului

  • my-user-my-repository-staging-25004381.dev.odoo.com domeniul folosit pentru conectarea la build

Cu condiția să ai drepturile de acces necesare pentru proiect, vei primi acces SSH la build.

Notă

Conexiunile SSH de lungă durată nu sunt garantate. Conexiunile inactive pot fi deconectate pentru a elibera resurse.

Submodul

Comanda submodule este folosită pentru a adăuga o ramură dintr-un alt depozit la ramura ta curentă ca submodul.

Example

git submodule add -b master <URL> <PATH> && git commit -a && git push -u origin staging
  • git submodule add -b master <URL> <PATH> o comandă pentru a adăuga o ramură specifică (de exemplu, master) dintr-un depozit (<URL>) ca submodul sub calea specificată (<PATH>) în ramura ta curentă.

  • git commit -a o comandă pentru a efectua commit tuturor modificărilor curente

  • git push -u origin staging o comandă pentru a încărca modificările ramurii curente (de exemplu, staging) în depozitul la distanță.

Șterge

Comanda delete este folosită pentru a șterge o ramură din depozitul tău.

Notă

Odată ce ștergi o ramură, nu există nicio modalitate de a o recupera decât dacă există o copie de siguranță. Ramurile staging nu sunt salvate automat, dar pot fi salvate manual. Ramurile development nu pot fi salvate.

Example

git push origin :staging && git branch -D staging
  • git push origin :staging o comandă pentru a șterge o ramură specifică (de exemplu, staging) din depozitul la distanță

  • git branch -D staging o comandă pentru a șterge ramura specifică din copia locală a depozitului

Atenționare

Înainte de a șterge o ramură, consultă secțiunea Copii de siguranță pentru a înțelege mai bine cum funcționează și când ar trebui să creezi o copie de siguranță manuală.