A apărut versiunea 13.4 cu stocarea HashiCorp pentru variabile CI, Agent Kubernetes și un centru de securitate, precum și funcții activate/dezactivate în Starter
La GitLab, ne gândim mereu la cum să ajutăm utilizatorii să reducă riscurile, să crească eficiența și viteza livrării pe platforma lor preferată. În această lună, am adăugat o serie de noutăți utile care extind capacitățile de securitate, reduc numărul de vulnerabilități, îmbunătățesc eficiența, simplifică utilizarea GitLab și ajută echipa dvs. să livreze funcții și mai rapid. Sperăm că veți găsi utile caracteristicile principale ale versiunii. 53 de alte funcții noi, adăugate în această versiune.
Capacități extinse de securitate
Ne străduim să adăugăm câteva funcții noi la GitLab DevSecOps în fiecare lună, iar această versiune nu face excepție. în cadrul construirii și desfășurării. De asemenea, organizațiile care doresc să mențină separarea responsabilităților de desfășurare a codului pot acum . Acest rol respectă și va permite confirmarea cererilor de îmbinare și desfășurarea codului în medii protejate, fără a oferi acces la modificarea efectivă a codului.
Încă o modalitate de a reduce riscurile este utilizarea noului . Specialiștii în exploatare pot desfășura clustere Kubernetes din GitLab fără a fi necesar să deschidă accesul la clusterul lor pentru întreaga internet. De asemenea, introducem suport automat pentru controlul versiunilor pentru noi fișiere de stare Terraform cu pentru a sprijini conformitatea și ușurința în depanare. Și în cele din urmă, tabloul de bord de securitate din instanță a devenit un cu rapoarte despre vulnerabilități și setări de securitate.
Un mod mai convenabil și eficient de a lucra cu GitLab
Am îmbunătățit căutarea globală, adăugând , care permite trecerea ușoară la ultimele bilete, grupuri, proiecte, setări și secțiuni de ajutor. Suntem încântați să anunțăm că în GitLab Pages pentru a redirecționa pagini și directoare specifice în cadrul site-ului, ceea ce va permite utilizatorilor să își desfășoare mai eficient site-urile. Iar celor care doresc să primească informații extinse despre desfășurare, această versiune le permite !
Depozite cu sursă deschisă
Vă prezentăm , pe care l-a adăugat . Marcajele de acoperire a codului testat prin unități pentru codul modificat oferă dezvoltatorilor o imagine clară asupra acoperirii codului în timpul revizuirii; aceste informații ajută la accelerarea procesului de revizuire și la reducerea timpului necesar pentru fuziune și desfășurarea noului cod. De asemenea, am și planificăm .
Și aceasta este doar începutul!
Ca de obicei, în recenzia generală este prea puțin spațiu, iar funcțiile grozave din versiunea 13.4 sunt foarte multe. Iată câteva dintre ele:
- .
Dacă doriți să aflați din timp ce vă așteaptă în următoarea versiune, vizionați .
.
din această lună —
Fabio a adus o contribuție semnificativă în — o funcție pe care comunitatea GitLab o aștepta de foarte mult timp. Aceasta este o contribuție cu adevărat importantă, incluzând modificări non-triviale care au necesitat o colaborare constantă cu membrii echipei GitLab și au avut un impact asupra multor domenii ale proiectului, cum ar fi UX, frontend și backend.
Funcțiile principale ale versiunii GitLab 13.4
Utilizați cheile HashiCorp Vault în sarcinile CI
(PREMIUM, ULTIMATE, SILVER, GOLD)
În versiunea 12.10, GitLab a introdus posibilitatea de a obține și de a transmite chei în sarcinile CI folosind handler-ul de sarcini GitLab (GitLab runner). Acum extindem , adăugând o nouă sintaxă secrets în fișier .gitlab-ci.yml. Acest lucru va face mai ușoară configurarea și utilizarea depozitului HashiCorp cu GitLab.
și .
Prezentăm Agentul GitLab Kubernetes
(PREMIUM, ULTIMATE)
Integrarea GitLab cu Kubernetes permite de mult timp implementarea pe clustere Kubernetes fără a necesita configurări manuale. Mulți utilizatori apreciază ușurința de utilizare a acestei combinații, în timp ce alții s-au confruntat cu unele dificultăți. Pentru integrarea curentă, clusterul vostru trebuie să fie accesibil din internet, astfel încât GitLab să poată accesa. Pentru multe organizații, acest lucru nu este posibil, deoarece limitează accesul la clustere din motive de securitate, conformitate sau reglementare. Pentru a ocoli aceste restricții, utilizatorii au fost nevoiți să-și creeze propriile instrumente deasupra GitLab, altfel nu ar fi putut folosi această funcționalitate.
Astăzi prezentăm GitLab Kubernetes Agent — o nouă modalitate de a implementa pe clustere Kubernetes. Agentul funcționează în interiorul cluster-ului vostru, astfel încât nu va trebui să-l deschideți către întreg internetul. Agentul coordonează implementarea solicitând noi modificări de la GitLab, în loc ca GitLab să trimita actualizări pe cluster. Indiferent de metoda GitOps pe care o utilizați, GitLab este potrivit pentru voi.
Rețineți că acesta este primul release al agentului. În prezent, ne-am concentrat pe configurarea și gestionarea implementării prin cod pentru GitLab Kubernetes Agent. Unele funcții existente de integrare Kubernetes, cum ar fi tablourile de implementare și aplicațiile gestionate de GitLab, nu sunt încă suportate. , că aceste funcționalități vor fi adăugate agenților în viitoarele release-uri, precum și noi integrări axate pe securitate și conformitate.
și .
Oferiți utilizatorilor permisiuni de implementare fără acces la cod
(PREMIUM, ULTIMATE, SILVER, GOLD)
Anterior, sistemul de permisiuni în GitLab nu permitea o separare corespunzătoare a sarcinilor în echipa dvs. între cei care sunt responsabili de dezvoltare și cei care se ocupă de implementare. Odată cu lansarea GitLab 13.4, puteți oferi permisiuni de aprobat cereri de fuziune pentru implementare, precum și permisiunea efectivă de a implementa codul persoanelor care nu scriu cod, fără a le oferi drepturi de acces de mentenanță (în localizarea în limba română a GitLab, „întreținător”).
și .
Centrul de securitate
(ULTIMATE, GOLD)
Anterior, gestionarea vulnerabilităților la nivel de instanță era limitată atât în funcționalitate, cât și în flexibilitate. Interfața consta într-o singură pagină care combina detaliile vulnerabilităților, graficele metrice și setările. Nu exista mult spațiu pentru dezvoltarea acestor funcții sau utilizarea altor instrumente de securitate.
Am adus modificări esențiale în gestionarea securității și transparenței acesteia în GitLab. Panoul de securitate al instanței s-a transformat într-un adevărat centru de securitate. Cea mai mare schimbare este introducerea unei noi structuri de meniu: în loc de o singură pagină, acum vedeți separat panoul de control al securității, raportul de vulnerabilități și secțiunea de setări. Deși funcționalitatea nu s-a schimbat, fragmentarea va permite îmbunătățiri în acest domeniu, lucru care ar fi fost dificil altfel. Aceasta oferă, de asemenea, o bază pentru adăugarea în viitor a altor funcționalități legate de securitate.
Secțiunea specială pentru raportul de vulnerabilități are acum mai mult spațiu pentru a afișa detalii importante. Aici sunt adunate vulnerabilitățile care se află în prezent pe lista de vulnerabilități a proiectului. Mutarea widget-urilor cu metricele vulnerabilităților într-o secțiune separată creează un panou de control al securității convenabil. Acum este o pânză pentru vizualizările viitoare – nu doar pentru gestionarea vulnerabilităților, ci și pentru orice metrice legate de securitate. În cele din urmă, o zonă separată a setărilor creează un spațiu comun pentru toate setările de securitate la nivel de instanță, nu doar pentru gestionarea vulnerabilităților.
și .
Funcțiile activabile sunt acum în GitLab Starter
(STARTER, PREMIUM, ULTIMATE, BRONZE, SILVER, GOLD)
În GitLab 11.4 a fost lansată . În 12.2 am introdus strategii pentru acestea și , iar în 13.1 am adăugat și pentru medii diferite.
Anterior în acest an, GitLab s-a angajat în cod sursă deschis. În această versiune, am finalizat transferul funcțiilor activabile în planul Starter și vom continua transferul lor în Core cu . Suntem bucuroși să oferim această oportunitate unui număr mai mare de utilizatori și vrem să aflăm cum le veți utiliza.
și .
Navigare rapidă din bara de căutare
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Uneori, atunci când navigați în GitLab, doriți să accesați direct un anumit proiect, și nu pagina cu rezultatele căutării.
Cu ajutorul panoului de căutare globală, puteți accesa rapid ultimele tichete, grupuri, proiecte, setări și secțiuni de asistență. Puteți chiar folosi o combinație de taste /, pentru a muta cursorul pe panoul de căutare, pentru a naviga și mai eficient în GitLab!
și .
Afișarea acoperirii codului în difurile cererilor de îmbinare
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Atunci când revizuiți o cerere de îmbinare, poate fi greu să stabiliți dacă codul modificat este acoperit de teste unitare. În schimb, revizorii se pot baza pe acoperirea generală și pot solicita creșterea acesteia înainte de a confirma cererea de îmbinare. Acest lucru poate duce la o abordare haotică a scrierii testelor, care nu va îmbunătăți calitatea codului sau acoperirea acestuia de testare.
Acum, când vizualizați diful cererii de îmbinare, veți vedea o reprezentare vizuală a acoperirii codului. Noile marcaje vor permite o înțelegere rapidă a acoperirii codului modificat de testele unitare, ceea ce va ajuta la accelerarea revizuirii codului și a timpului de îmbinare și desfășurare a noului cod.
Mulțumesc și Siemens pentru această caracteristică!
și .
Mai multe medii și proiecte în panoul mediilor
(PREMIUM, ULTIMATE, SILVER, GOLD)
Din versiunea 12.5 a GitLab, cu ajutorul ați putut monitoriza starea mediilor, dar nu mai mult de șapte medii în trei proiecte. Am îmbunătățit acest panou în versiunea 13.4, împărțindu-l în pagini, pentru a vă ajuta să gestionați și să administrați mediile la scară mare. Acum puteți vedea mai multe medii în mai multe proiecte.
și .
GitLab a preluat gestionarea provider-ului GitLab Terraform
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Recent am și planificăm . În ultima lună, am acceptat 21 de cereri de îmbinare și am închis 31 de tichete, inclusiv unele erori vechi și funcții lipsă, cum ar fi . Puteți în documentația pentru Terraform.
și .
Testarea fuzzing a API-ului cu specificațiile OpenAPI sau cu un fișier HAR
(ULTIMATE, GOLD)
Testarea fuzzing a API-urilor este o modalitate excelentă de a căuta erori și vulnerabilități în aplicațiile web și API-urile dvs., pe care alte scannere și metode de testare le pot omite.
Testarea API-urilor fuzzing în GitLab permite furnizarea sau al aplicației dvs. și apoi generează automat date de intrare aleatorii, menite să verifice cazurile limită și să identifice erorile. Rezultatele sunt afișate imediat în cadrul pipeline-ului dvs.
Aceasta este prima noastră lansare a testării API-urilor fuzzing, iar noi am fi încântați să știm ce părere aveți. Pentru testarea fuzzing mai avem , pe care ne vom baza în urma lansării acestei funcționalități.
și .
Previzualizarea noilor grafice pe tabloul de bord de metrici
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
În trecut, crearea unui grafic pe tabloul de bord de metrici în GitLab era o sarcină dificilă. După ce ați creat o metrică în fișierul YAML al tabloului, modificați master, fără a avea posibilitatea de a verifica dacă graficul creat recent funcționează exact cum doriți. Începând cu această lansare, puteți previzualiza modificările pe măsură ce creați graficul, obținând o idee despre rezultat înainte de a trimite modificările în fișierul YAML al tabloului.
și .
Datele despre acoperirea codului prin teste pentru toate proiectele grupului
(PREMIUM, ULTIMATE, SILVER, GOLD)
Când gestionați un număr mare de proiecte în GitLab, aveți nevoie de o sursă unică de informații despre modul în care acoperirea codului se schimbă în timp pentru toate proiectele. Anterior, afișarea acestei informații necesita muncă manuală obositoare: trebuia să descărcați datele despre acoperirea codului prin teste din fiecare proiect și să le combinați într-un tabel.
În lansarea 13.4, a apărut posibilitatea de a aduna cu ușurință și rapid în .csv fișier toate datele despre acoperirea codului pentru toate proiectele grupului sau pentru un set selectat de proiecte. Această funcționalitate este MVC, iar ulterior va urma posibilitatea .
și .
Suport pentru noi limbaje pentru testarea fuzzing completă
(ULTIMATE, GOLD)
Această lansare prezintă suport pentru mai multe limbaje noi pentru testarea fuzzing direcționată spre acoperire completă.
Acum puteți evalua toate posibilitățile de testare prin fuzzing în aplicațiile dvs. pe Java, Rust și Swift și să găsiți erori și vulnerabilități pe care alte scanere și metode de testare le-ar putea rata.
și .
Alerte pe pagina principală a mediilor
(PREMIUM, ULTIMATE, SILVER, GOLD)
Pagina mediilor afișează starea generală a mediilor dvs. În această actualizare, am îmbunătățit această pagină adăugând afișarea alertelor. Alerta declanșată împreună cu starea mediilor dvs. vă vor ajuta să luați măsuri mai rapid pentru a rezolva problemele apărute.
și .
Pipeline-urile înlănțuite pot acum să își lanseze pipeline-urile înlănțuite
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Atunci când folosiți pipeline-uri înlănțuite, a devenit posibil să creați pipeline-uri noi în interiorul pipeline-urilor fiice. Un nivel suplimentar de adâncime poate fi util dacă aveți nevoie de flexibilitate pentru a genera un număr variabil de pipeline-uri.
Anterior, când se foloseau pipeline-uri înlănțuite, fiecare pipeline fiu avea nevoie de o sarcină-trigger, setată manual în pipeline-ul părinte. Acum puteți crea pipeline-uri înlănțuite care vor lansa dinamic orice număr de pipeline-uri noi. De exemplu, dacă aveți un monorepo, puteți genera dinamic primul pipeline înlănțuit care va crea singur numărul necesar de pipeline-uri noi, în funcție de modificările din ramură.
și .
Navigare îmbunătățită între pipeline-urile părinte și cele înlănțuite
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Aproape că era incomod să navighezi între pipeline-urile părinte și cele înlănțuite – trebuia să faci multe clicuri pentru a ajunge la pipeline-ul dorit. De asemenea, era greu să înțelegi care sarcină a declanșat acest pipeline. Acum va fi mult mai ușor să vezi legăturile între pipeline-urile părinte și cele înlănțuite.
și .
Sarcinile matriciale paralele afișează variabilele relevante în numele sarcinii
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Dacă ați folosit , ați putut observa că a fost greu de determinat ce variabilă matricială a fost folosită pentru o sarcină specifică, deoarece numele sarcinii arătau ca matrix 1/4În versiunea 13.4, veți vedea valorile relevante ale variabilelor utilizate în această sarcină, în locul denumirii generale a sarcinii. De exemplu, dacă obiectivul dumneavoastră este debugarea pentru arhitectura x86, atunci sarcina va fi denumită matrix: debug x86.
și .
Alte îmbunătățiri în GitLab 13.4
Conectarea contului Atlassian
(CORE, STARTER, PREMIUM, ULTIMATE)
Utilizatorii GitLab vor putea acum să-și conecteze conturile GitLab la contul Atlassian Cloud. Aceasta va permite autentificarea în GitLab cu acreditivele Atlassian și va pune bazele pentru viitoare îmbunătățiri ale integrării și cu alte produse din gama Atlassian.
și .
Exportul listei tuturor commiturilor de merge
(ULTIMATE, GOLD)
Organizațiile care urmăresc conformitatea au nevoie de un mod de a arăta auditorilor o imagine de ansamblu completă a componentelor legate de orice modificare specifică în producție. În cadrul GitLab, aceasta înseamnă că trebuie să adunați într-un singur loc tot: cererile de merge, tichetele, pipeline-urile, scanările de securitate și alte date despre commit. Până acum, a trebuit să adunați manual aceste informații în GitLab sau să configurați propriile instrumente pentru colectarea informațiilor, ceea ce nu era foarte eficient.
Acum puteți aduna și exporta programatic aceste date pentru a satisface cerințele de audit sau pentru a efectua alte analize. Pentru a exporta lista tuturor commiturilor de merge pentru grupul curent, trebuie să accesați și să faceți clic pe butonul Lista tuturor commiturilor de merge. Fișierul obținut va conține toate commiturile cererii de merge, autorul acestora, ID-ul cererii de merge asociate, grupul, proiectul, confirmările și alte informații.
și .
Ieșirea listei și gestionarea token-urilor de acces personale prin API
(ULTIMATE, GOLD)
Gestionarea accesului la spațiul de nume GitLab este o parte importantă a activităților de conformitate. De la principiile privilegiilor minime până la restricționarea accesului pe baza unui temporizator, pot exista mai multe cerințe legate de tokenurile personale de acces în GitLab. Pentru a facilita gestionarea și monitorizarea tuturor acestor credențiale de utilizator în cadrul spațiului dvs. de nume, am implementat o opțiune de a lista toate tokenurile personale de acces și opțional prin API.
Aceste îmbunătățiri ale API-ului GitLab permit utilizatorilor să listeze și să anuleze propriile tokenuri personale de acces, iar administratorii pot lista și anula tokenurile utilizatorilor lor. Acum, administratorilor le va fi mai ușor să vadă cine are acces la spațiul lor de nume, să ia decizii cu privire la acordarea accesului pe baza datelor utilizatorilor și să anuleze tokenurile personale de acces care ar fi putut fi compromise sau care ies din limitele politicilor companiei de gestionare a accesului.
și .
Bilete corelate și alte funcționalități acum în GitLab Core
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Cu câteva luni în urmă, am anunțat un plan pentru . Lucrând la îndeplinirea acestei promisiuni, am realizat , și (în localizarea în limba română a GitLab, «tabloul de discuții») disponibile în planul Core. Acest lucru se aplică doar relațiilor de tip „corelat cu”, relațiile de tip „blochează” și „este blocat” rămân în planurile plătite.
și .
Afișarea numelui ramurii originale în bara laterală a cererii de îmbinare
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Atunci când revizuim modificările de cod, discuțiile și commit-urile cererii de îmbinare, este adesea dorit să facem un checkout local al ramurii pentru o revizuire mai profundă. Cu toate acestea, găsirea numelui ramurii devine din ce în ce mai dificilă pe măsură ce descrierea cererii de îmbinare se încarcă cu mai mult conținut și se va necesita derularea paginii.
Am adăugat numele ramurii în bara laterală a cererii de îmbinare, făcându-l disponibil în orice moment și eliminând nevoia de a derula întreaga pagină. La fel ca și linkul către cererea de îmbinare, secțiunea cu ramura originală conține un buton convenabil „copiază”.
Mulțumesc pentru contribuția enormă la dezvoltarea acestei funcționalități!
și .
Indicația asupra prezenței fișierelor comprimate în diferențele cererii de îmbinare
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Cererile de îmbinare care adaugă modificări la mai multe fișiere, uneori, comprimă diferențele pentru fișierele mari, pentru a îmbunătăți performanța afișării. Când acest lucru se întâmplă, se poate întâmpla să lipsesc un fișier în timpul revizuirii, mai ales în cererile de îmbinare cu un număr mare de fișiere. Începând cu versiunea 13.4, cererile de îmbinare vor marca diferențele care conțin fișiere comprimate, astfel încât să nu ratați aceste fișiere în procesul de revizuire a codului. Pentru și mai multă claritate, plănuim să adăugăm evidențierea acestor fișiere într-o viitoare versiune. Urmăriți actualizările în .
și .
Avertisment despre prezența fișierelor comprimate în diferența cererii de îmbinare
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
În secțiunea cu diferențele cererilor de îmbinare, fișierele mari sunt comprimate pentru a crește performanța. Cu toate acestea, în timpul revizuirii codului, unele fișiere pot fi omise atunci când revizorul derulează lista fișierelor, deoarece toate fișierele mari sunt comprimate.
Am adăugat un avertisment vizibil în partea de sus a paginii de diferență a cererii de îmbinare, pentru a informa utilizatorii că în această secțiune există un fișier comprimat. Astfel, nu veți rata nici o modificare în cererea de îmbinare în timpul revizuirii.
și .
Restaurarea automată a depozitului clusterului Gitaly
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Anterior, atunci când nodul primar al clusterului Gitaly se deconecta, depozitele de pe acest nod erau marcate ca fiind disponibile doar pentru citire. Aceasta prevenea pierderile de date în situații în care pe nod erau modificări care nu fuseseră replicate încă. Când nodul se reconecta, GitLab nu se restaura automat, iar administratorii trebuiau să lanseze manual procesul de sincronizare sau să se împace cu pierderea de date. Alte situații, cum ar fi finalizarea eșuată a sarcinii de replicare pe nodul secundar, ar putea conduce de asemenea la apariția depozitelor învechite sau disponibile doar pentru citire. În acest caz, depozitul rămânea învechit până când se efectua următoarea operațiune de scriere care să inițieze sarcina de replicare.
Pentru a rezolva această problemă Acum, sistemul planifică o sarcină de replicare atunci când detectează un repository învechit pe un nod și cea mai recentă versiune a repository-ului pe alt nod. Această sarcină de replicare aduce repository-ul la zi automat, eliminând astfel necesitatea de a restaura datele manual. Restaurația automată asigură de asemenea o actualizare rapidă a nodurilor secundare, în cazul în care sarcina de replicare eșuează, în loc să aștepte următoarea operațiune de scriere. Având în vedere că multe clustere Gitaly stochează un număr mare de repository-uri, acest lucru scade semnificativ timpul pe care administratorii și inginerii de fiabilitate îl petrec cu recuperarea datelor după o eroare.
În plus, repararea automată inițiază replicarea repository-urilor pe orice nod nou Gitaly adăugat în cluster, eliminând astfel munca manuală atunci când se adaugă noduri noi.
și .
Marchează sarcina to-do ca fiind finalizată pe pagina de design
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
O comunicare eficientă în GitLab se bazează pe liste de sarcini to-do. Dacă ai fost menționat într-un comentariu, este esențial să poți accesa sarcina și fie să începi să lucrezi, fie să o marchezi ca fiind deja finalizată. De asemenea, este important să poți desemna o sarcină pentru tine când trebuie să lucrezi la ceva sau să reiei mai târziu.
Anterior, nu puteai adăuga sarcini sau să le marchezi ca finalizate când lucrai cu desene. Acest lucru a afectat semnificativ eficiența comunicării între echipele de produs, deoarece sarcinile to-do sunt un element critic al fluxului de lucru în GitLab.
În versiunea 13.4, desenele încep să țină pasul cu comentariile din tichete în utilizarea sarcinilor, ceea ce face lucrul cu acestea mai consecvent și eficient.
și .
Ghid îmbunătățit pentru depanarea CI/CD
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Am îmbunătățit ghidul de depanare pentru GitLab CI/CD, adăugând informații suplimentare despre problemele frecvente pe care le poți întâmpina. Sperăm că documentația îmbunătățită va fi o resursă valoroasă care te va ajuta să configurezi și să lansezi rapid și ușor GitLab CI/CD.
și .
Cererea de fuziune nu mai cade din coada de fuziune
(PREMIUM, ULTIMATE, SILVER, GOLD)
Anterior, cererile de fuziune puteau cădea din coada de fuziune din întâmplare din cauza comentariilor tardive. Dacă cererea de fuziune era deja în coadă și cineva adăuga un comentariu care crea o nouă discuție nerezolvată, cererea de fuziune era considerată inadecvată pentru fuziune și cădea din coadă. Acum, după ce cererea de fuziune este adăugată în coada de fuziune, pot fi adăugate comentarii noi fără teama de a afecta procesul de fuziune.
și .
Afișarea în cererea de fuziune a valorii acoperirii codului pentru sarcină
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Dezvoltatorii trebuie să aibă posibilitatea de a vedea valoarea acoperirii codului după finalizarea pipeline-ului — chiar și în scenarii complexe, cum ar fi funcționarea pipeline-ului cu mai multe sarcini care trebuie analizate pentru a calcula valoarea acoperirii. Anterior, widgetul cererii de fuziune arata doar media acestor valori, ceea ce însemna că trebuia să navigați la pagina sarcinii și înapoi la cererea de fuziune pentru a obține valorile intermediare ale acoperirii. Pentru a economisi timpul vostru și a vă scuti de acești pași inutili, am realizat în widget afișarea mediei valorii acoperirii, a modificării acesteia între ramurile țintă și de bază și un tooltip care arată valoarea acoperirii pentru fiecare sarcină, pe baza căreia a fost calculată media.
și .
Ștergerea pachetelor din registrul de pachete atunci când vizionați un grup
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Registrul de pachete GitLab este locul unde sunt stocate și distribuite pachetele în diferite formate. Când aveți multe pachete în proiectul sau grupul vostru, trebuie să identificați rapid pachetele neutilizate și să le ștergeți, astfel încât oamenii să nu le descarce. Puteți șterge pachete din registrul vostru prin sau prin interfața utilizatorului a registrului de pachete. Cu toate acestea, până acum nu ați putut șterge pachete atunci când vizionați un grup prin interfața utilizatorului. Drept urmare, trebuia să ștergeți pachetele inutile separat pentru fiecare proiect, ceea ce era ineficient.
Acum puteți șterge pachete atunci când vizionați registrul de pachete al grupului. Pur și simplu accesați pagina registrului de pachete al grupului, filtrați pachetele după nume și ștergeți tot ceea ce nu este necesar.
și .
Scalarea pachetelor Conan la nivel de proiect
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Puteți utiliza depozitul Conan în GitLab pentru publicarea și distribuirea dependențelor C/C++. Totuși, anterior, pachetele puteau fi scalate doar la nivel de instanță, deoarece numele pachetului Conan putea avea maximum 51 de caractere. Dacă doriți să publicați un pachet dintr-un subgrup, de exemplu gitlab-org/ci-cd/package-stage/feature-testing/conan, acest lucru era aproape imposibil de realizat.
Acum puteți scala pachetele Conan la nivel de proiect, ceea ce permite publicarea și distribuirea ușoară a dependențelor proiectelor dumneavoastră.
și .
Suport pentru noi manageri de pachete și limbaje pentru scanarea dependențelor
(ULTIMATE, GOLD)
Suntem încântați să adăugăm scanarea dependențelor pentru proiectele scrise în C, C++, C# și .Net, care utilizează NuGet 4.9+ sau manageri de pachete Conan, în lista noastră . Acum puteți include scanarea dependențelor ca parte a etapei Secure, pentru a verifica dependențele adăugate prin manageri de pachete pentru vulnerabilități cunoscute. Vulnerabilitățile găsite vor fi afișate în cererea dvs. de unire, împreună cu nivelul lor de pericol, astfel încât să știți, înainte de a efectua unirea, ce riscuri prezintă o nouă dependență. De asemenea, puteți configura proiectul astfel încât să necesite pentru dependențele cu vulnerabilități cu nivel de pericol critic (Critical), mare (High) sau necunoscut (Unknown).
și .
Notificări atunci când se modifică setarea cererii de unire la 'Fuzionează la finalizarea cu succes a pipeline-ului'
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Anterior, când se stabilea setarea cererii de unire Fuzionează când se termină pipeline-ul (Merge When Pipeline Succeeds, MWPS) nu se trimitea nicio notificare prin email. Trebuia să verificați manual starea sau să așteptați notificarea de finalizare a fuzionării. În această versiune suntem încântați să prezentăm contribuția utilizatorului , care a rezolvat această problemă, adăugând trimiterea automată a notificărilor tuturor celor care sunt abonați la cererea de unire, atunci când revizorul schimbă setarea fuzionării la MWPS.
și .
Crearea clusterelor EKS cu o versiune Kubernetes specificată de utilizator
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Utilizatorii GitLab pot acum să aleagă singuri versiunea Kubernetes care va fi furnizată de EKS; pot alege între versiunile 1.14–1.17.
și .
Crearea incidentelor ca tipuri de ticket
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Nu fiecare problemă raportată declanșează imediat trimiterea de notificări: utilizatorii semnalează defecțiuni, iar membrii echipei investighează problemele de performanță. Acum, incidentele sunt un tip de ticket, astfel încât echipele tale vor putea să le creeze rapid în cadrul fluxului de lucru obișnuit. Fă clic Sarcină nouă din orice loc din GitLab, iar în câmpul Tip alege Incident.
și .
Menționarea notificărilor GitLab în Markdown
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Am îmbunătățit notificările GitLab, adăugând un nou tip de mențiune special pentru acestea în Markdown-ul GitLab, ceea ce facilitează partajarea notificărilor și menționarea lor. Folosește ^alert#1234, pentru a menționa o notificare în orice câmp cu markup Markdown: în incidente, ticketuri sau cereri de îmbinare. Acest lucru te va ajuta de asemenea să identifici sarcinile create din notificări, nu din ticketuri sau cereri de îmbinare.
și .
Vizualizarea sarcinii de notificare a incidentelor
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Descrierea notificării conține informații critice pentru diagnosticarea defecțiunilor și recuperarea, iar aceste informații trebuie să fie ușor accesibile, pentru a nu fi necesară comutarea între instrumente sau tab-uri în timpul lucrului la rezolvarea incidentului. Incidentele create din notificări afișează descrierea completă a notificării în tab-ul Detalii Alertă.
Căutare avansată cu 75% mai rapidă
(STARTER, PREMIUM, ULTIMATE, BRONZE, SILVER, GOLD)
GitLab, ca aplicație unică, are ocazia unică de a face căutarea conținutului pe întreg fluxul de lucru DevOps rapid. În GitLab 13.4, căutarea avansată oferă rezultate cu 75% mai repede atunci când este , precum pe GitLab.com.
și .
Vizualizarea proiectelor șterse pentru administratori
(CORE, STARTER, PREMIUM, ULTIMATE)
Posibilitatea de a amâna ștergerea unui proiect a fost . Cu toate acestea, nu a fost posibil anterior să vezi într-un singur loc toate proiectele care așteaptă ștergerea. Acum, administratorii instanțelor de utilizator GitLab pot vizualiza toate proiectele care așteaptă ștergerea într-un singur loc — împreună cu butoanele pentru revenirea ușoară a acestor proiecte.
Această funcționalitate permite administratorilor să controleze mai bine ștergerea proiectelor, adunând toate informațiile necesare într-un singur loc și oferind posibilitatea de a anula acțiunile nedorite de ștergere.
Mulțumesc pentru această funcție!
și .
API-ul a adăugat suport pentru regulile de push pentru grupuri
(STARTER, PREMIUM, ULTIMATE, BRONZE, SILVER, GOLD)
Anterior, regulile de push pentru grupuri puteau fi configurate doar accesând fiecare grup în parte prin intermediul interfeței utilizatorului GitLab și aplicând aceste reguli. Acum puteți gestiona aceste reguli prin API pentru a sprijini instrumentele dvs. personalizate și automatizarea GitLab.
și .
Revocarea token-urilor de acces personale pentru stocarea automată a credentialelor
(ULTIMATE)
oferă administratorilor informațiile necesare pentru a gestiona credentialele utilizatorilor din instanța lor GitLab. Deoarece organizațiile orientate spre conformitate variază în strictețea regulilor lor de gestionare a credentialelor, am adăugat un buton care permite administratorilor să revoce, la dorință, token-ul de acces personal al utilizatorului (PAT). Acum, administratorii pot revoca cu ușurință PAT-uri potențial compromise. Această funcție este utilă pentru organizațiile care au nevoie de opțiuni mai flexibile pentru a asigura respectarea cerințelor pentru a minimiza distragerea atenției utilizatorilor lor.
și .
Fișierul de configurare pentru editorul de site-uri statice
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
În GitLab 13.4, prezentăm o nouă modalitate de configurare a editorului de site-uri statice. Deși fișierul de configurare nu salvează și nu primește nicio parametru în această versiune, punem bazele pentru viitoarea configurare a comportamentului editorului. În versiunile următoare, vom adăuga în fișier .gitlab/static-site-editor.yml parametrii pentru setarea , pe care , suprascrierea setărilor de sintaxă Markdown și a altor setări ale editorului.
și .
Editarea părții introductive a fișierului cu editorul de site-uri statice
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Partea introductivă (front matter) este o modalitate flexibilă și convenabilă de a defini variabilele paginii în fișierele de date destinate procesării de către generatorul de site-uri statice. De obicei, aceasta este utilizată pentru a seta titlul paginii, șablonul de layout sau autorul, dar poate fi folosită pentru a transmite orice tip de metadate generatorului în timpul redării paginii în HTML. Inclusă în partea de sus a fiecărui fișier de date, partea introductivă este de obicei formatată ca YAML sau JSON și necesită o sintaxă consistentă și precisă. Utilizatorii care nu sunt familiarizați cu regulile specifice de sintaxă pot introduce din greșeală markup invalid, ceea ce, la rândul său, poate provoca probleme de formatare sau chiar eșecuri în procesul de construire.
Modul de editare WYSIWYG al editorului de site-uri statice elimină deja partea introductivă din editor pentru a preveni aceste erori de formatare. Totuși, acest lucru nu vă permite să schimbați valorile stocate în această parte fără a reveni la editarea în modul de cod sursă. În GitLab 13.4, puteți accesa orice câmp și să-i editați valoarea într-o interfață familiară bazată pe formulare. Când faceți clic pe butonul Setări (Setări) se va deschide un panou pe care se afișează câte un câmp de formular pentru fiecare cheie definită la început. Câmpurile sunt completate cu valoarea curentă și este suficient să introduceți orice dintre ele într-un formular web pentru a le edita. Această editare a părții introductive ajută la evitarea complicațiilor de sintaxă și vă oferă control total asupra conținutului, asigurând totodată o formatare uniformă a rezultatului final.
și .
GitLab pentru Jira și DVCS Connector acum în Core
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Pentru utilizatorii Jira în GitLab: și permit afișarea informațiilor despre commit-uri și merge requests GitLab direct în Jira. Îmbinându-se cu integrarea noastră încorporată cu Jira, puteți naviga cu ușurință între cele două aplicații în timpul lucrului.
Aceste funcții au fost disponibile anterior doar în planul nostru Premium, dar acum sunt accesibile tuturor utilizatorilor!
și .
Votul prin majoritate pentru tranzacțiile din clusterul Gitaly (versiune beta)
(CORE, STARTER, PREMIUM, ULTIMATE)
Clusterul Gitaly permite replicarea repository-urilor Git pe mai multe noduri Gitaly "calde". Acest lucru îmbunătățește disponibilitatea prin eliminarea punctelor unice de eșec. , prezentate în GitLab 13.3, declanșează o transmitere extinsă a modificărilor către toate nodurile Gitaly din cluster, dar doar nodurile Gitaly care votează în acord cu nodul principal păstrează modificările pe disc. Dacă toate nodurile-replici nu ajung la un consens, doar o copie a modificării va fi păstrată pe disc, creând un punct unic de eșec până la finalizarea replicării asincrone.
Votul prin majoritate îmbunătățește disponibilitatea, solicitând consensul majorității nodurilor (nu al tuturor) înainte de a păstra modificările pe disc. Dacă această caracteristică activabilă este activată, scrierea ar trebui să reușească pe mai multe noduri. Nodurile nesusținute se sincronizează automat prin replicare asincronă cu nodurile care au format un consens.
și .
Suport pentru schemă personalizată pentru validarea JSON în Web IDE
(PREMIUM, ULTIMATE, SILVER, GOLD)
Proiectele unde oamenii scriu configurații în format JSON sau YAML sunt adesea supuse problemelor, deoarece este ușor să faci o greșeală de tipar și să strici ceva. Poți scrie instrumente de verificare care să prindă aceste probleme în pipeline-ul CI, dar utilizarea unui fișier de schemă JSON poate fi utilă pentru a oferi documentație și sugestii.
Participanții la proiect pot defini în repository-ul lor calea către schema personalizată în fișierul .gitlab/.gitlab-webide.yml, care indică schema și calea către fișierele pentru verificare. Atunci când se încarcă un anumit fișier în Web IDE, va fi vizibil un feedback suplimentar și o verificare care vor ajuta la crearea fișierului.
și .
Limita ramificării graficului orientat aciclic (DAG) a fost crescută la 50
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Dacă utilizezi pipeline-uri (Directed Acyclic Graph (DAG)), ai putea descoperi că limitarea de 10 sarcini pe care o sarcină o poate indica în needs:, prea sever. În 13.4, limita implicită a fost crescută de la 10 la 50 pentru a permite rețele mai complexe de relații între sarcinile din conductele dvs.
Dacă sunteți administratorul unei instanțe GitLab, puteți crește această limită și mai mult, configurând o caracteristică opțională, deși nu oferim suport oficial pentru aceasta.
și .
Îmbunătățirea comportamentului nevoilor pentru sarcinile omise
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
În unele cazuri, o sarcină omisă din conductă putea fi considerată eronat ca fiind reușită pentru dependențele specificate în nevoilor, ceea ce ducea la pornirea sarcinilor ulterioare, lucru care nu ar fi trebuit să se întâmple. Acest comportament a fost corectat în versiunea 13.4, iar nevoilor acum gestionează corect cazurile de sarcini omise.
și .
Blocați ultimul artefact al sarcinii pentru a preveni ștergerea sa
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
GitLab acum blochează automat ultimul artefact al unei sarcini și conducte pe orice ramură activă, cerere de îmbinare sau etichetă, pentru a preveni ștergerea sa după expirare. Devine mai ușor să stabiliți reguli de expirare mai agresive pentru a curăța artefactele mai vechi. Acest lucru ajută la reducerea consumului de spațiu pe disc și garantează că aveți întotdeauna o copie a ultimului artefact din conductă.
și .
Ghid pentru CI/CD pentru optimizarea conductei
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Optimizarea conductei CI/CD poate crește viteza de livrare și economisi bani. Am îmbunătățit documentația noastră, adăugând un ghid concis pentru a obține maximum de eficiență din optimizarea conductelor dvs.
și .
Raportul de testare este sortat după starea testului
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
— este un mod simplu de a vedea rezultatele tuturor testelor din pipeline. Totuși, cu un număr mare de teste, căutarea testelor eșuate poate dura mult timp. Alte probleme care pot face dificilă utilizarea raportului includ dificultățile de derulare a ieșirilor lungi de trasare și rotunjirea timpului la zero pentru testele executate în mai puțin de 1 secundă. Acum, implicit, raportul de testare sortează mai întâi testele eșuate, urmate de sortarea testelor după durata lor. Acest lucru simplifică găsirea defectelor și a testelor lungi. În plus, durata testelor este acum afișată în milisecunde sau secunde, așa că citirea lor a devenit mult mai rapidă, iar problemele anterioare de derulare au fost de asemenea rezolvate.
și .
Limitări privind dimensiunea fișierelor încărcate în registrul de pachete
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Acum există limitări pentru dimensiunea fișierelor pachetelor care pot fi încărcate în registrul de pachete GitLab. Limitările au fost adăugate pentru a optimiza performanța registrului de pachete și pentru a preveni abuzurile. Limitările depind de formatul pachetului. Pentru GitLab.com, dimensiunile maxime ale fișierelor sunt:
- Conan: 250MB
- Maven: 3GB
- NPM: 300MB
- NuGet: 250MB
- PyPI: 3GB
Pentru instanțele GitLab personalizate, valorile implicite sunt aceleași. Totuși, administratorul poate actualiza limitările prin .
și .
Folosește CI_JOB_TOKEN pentru a publica pachete PyPI
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Poți folosi registrul GitLab PyPI pentru a crea, publica și partaja pachete Python împreună cu codul sursă și pipeline-urile CI/CD. Totuși, anterior nu puteai să te autentifici în registru folosind o variabilă de mediu predefinită CI_JOB_TOKEN. Ca rezultat, trebuia să folosești acreditivele tale personale pentru a actualiza registrul PyPI, sau poate ai decis să nu folosești deloc registrul.
Acum este mai ușor să folosești GitLab CI/CD pentru a publica și instala pachete PyPI folosind o variabilă de mediu predefinită CI_JOB_TOKEN.
și .
Profiluri de scanner DAST la cerere
(ULTIMATE, GOLD)
Pentru scanările DAST la cerere, care au fost , au fost adăugate profilele scanner-ului DAST. Acestea extind posibilitățile de configurare a acestui tip de scanare, permițându-vă să creați rapid mai multe profile pentru a acoperi mai multe tipuri de scanări. În versiunea 13.4, profilul scanner-ului include inițial parametrul de timeout al crawler-ului, care stabilește cât timp ar trebui să funcționeze crawler-ul DAST în încercarea de a descoperi toate paginile site-ului scanat. Profilul include, de asemenea, parametrul de timeout al site-ului țintă, pentru a stabili cât timp ar trebui să aștepte scanner-ul înainte de a întrerupe scanarea, dacă site-ul nu răspunde cu un cod de stare 200 sau 300. Pe măsură ce vom îmbunătăți din nou această caracteristică în versiunile viitoare, profilul scanner-ului va include parametri suplimentari de configurare.
și .
Fișier simplu de configurare a redirecționărilor pentru GitLab Pages
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Dacă folosiți GitLab Pages și doriți să gestionați mai bine modificările URL-urilor, s-ar putea să fi observat că gestionarea redirecționărilor pe site-ul dumneavoastră GitLab Pages a fost imposibilă. GitLab permite acum să configurați reguli pentru redirecționarea unui URL către altul pentru site-ul dumneavoastră Pages, prin adăugarea unui fișier de configurare în depozit. Această caracteristică a fost posibilă datorită contribuției lui Kevin Barnett (), a lui Eric Eastwood () și echipei GitLab. Mulțumim tuturor pentru contribuțiile voastre.
și .
Starea Terraform gestionată de GitLab
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Accesul la versiunile anterioare ale stării Terraform este necesar atât pentru îndeplinirea cerințelor, cât și pentru depanare, atunci când este necesar. Suportul pentru gestionarea versiunilor stării Terraform gestionat de GitLab este disponibil începând cu GitLab 13.4. Gestionarea versiunilor este activată automat pentru noile fișiere de stare Terraform. Fișierele existente de stare Terraform vor într-o versiune ulterioară.
și .
Detalii importante privind notificarea incidentelor
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Atunci când gestionați incidente, trebuie să puteți determina cu ușurință cât timp a fost deschis un alertă și de câte ori s-a declanșat un eveniment. Aceste detalii sunt adesea cruciale pentru a evalua impactul asupra clientului și ceea ce echipa dumneavoastră ar trebui să abordeze în primul rând. Pe noua panea de detalii ale incidentului, afișăm timpul de început al alertării, numărul de evenimente și un link către alertarea originală. Aceste informații sunt disponibile pentru incidentele create din alerte.
și .
Setarea și editarea severității incidentului
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Setarea „severității incidentului” permite răspunzătorilor și părților interesate să determine impactul întreruperilor, precum și metodele și urgența răspunsului. Pe măsură ce echipa dumneavoastră împărtășește rezultatele în timpul soluționării incidentului și restabilește funcționarea, pot modifica această setare. Acum puteți edita severitatea incidentului în panoul din dreapta al paginii „Detalii incident” și gradul de severitate este afișat în lista incidentelor.
și .
Crearea, editarea și ștergerea regulilor de securitate a rețelei containerelor
(ULTIMATE, GOLD)
Această îmbunătățire a editorului de reguli de securitate a containerelor permite utilizatorilor să creeze, editeze și șteargă regulile lor direct din interfața utilizatorului GitLab. Funcționalitățile editorului includ modul .yaml pentru utilizatorii experimentați și un editor de reguli cu o interfață intuitivă pentru cei care nu sunt familiarizați cu regulile de rețea. Puteți găsi noi oportunități de gestionare a regulilor în secțiunea Securitate și Conformitate > Managementul amenințărilor > Politici (Security & Compliance > Threat Management > Policies).
și .
Suport pentru stocarea obiectelor blob Azure
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Atât GitLab, cât și GitLab Runner acum suportă , care simplifică desfășurarea serviciilor GitLab în Azure.
Instanțele GitLab suportă Azure pentru toate tipurile de stocare a obiectelor, inclusiv fișiere LFS, artefacte CI și . Pentru a configura stocarea obiectelor blob Azure, urmați instrucțiunile de instalare sau .
Handler-ii de lucru GitLab suportă, de asemenea, Azure pentru stocarea . Stocarea Azure poate fi configurată din secțiunea .
și .
Pachetele Omnibus ARM64 pentru Ubuntu și OpenSUSE
(CORE, STARTER, PREMIUM, ULTIMATE)
Ca răspuns la cererea în creștere pentru suportul lansării GitLab pe arhitectura ARM de 64 de biți, suntem bucuroși să anunțăm disponibilitatea oficială a pachetului ARM64 Ubuntu 20.04 Omnibus. O mare mulțumire lui Zitai Chen și Guillaume Gardet pentru contribuția imensă — cererile lor de unire au jucat un rol esențial în acest proces!
Pentru a descărca și instala pachetul pentru Ubuntu 20.04, vizitați și selectați Ubuntu.
și .
Suport pentru autentificarea cu carduri inteligente pentru GitLab Helm chart
(PREMIUM, ULTIMATE)
Cardurile inteligente, cum ar fi cardurile de acces comun (CAC), pot fi acum utilizate pentru autentificarea în instanța GitLab desfășurată prin Helm chart. Cardurile inteligente sunt autentificate în baza de date locală folosind certificate X.509. Astfel, suportul pentru cardurile inteligente în Helm chart este acum în conformitate cu suportul pentru cardurile inteligente disponibil în desfășurările Omnibus.
și .
Notele detaliate de lansare și instrucțiunile pentru actualizare/instalare pot fi citite în postarea originală în engleză: .
În traducerea din engleză au lucrat , , și .
Sursa: habr.com
