GitLab 11.10 cu conducte de tablou de bord, conducte de rezultate îmbinate și sugestii cu mai multe linii în solicitările de îmbinare.
Informații convenabile despre performanța conductelor în diferite proiecte
GitLab continuă să mărească vizibilitatea asupra ciclului de viață DevOps. În acest număr pe panoul de control a adăugat o prezentare generală a stării conductei.
Acest lucru este convenabil chiar dacă studiați conducta unui singur proiect, dar este util mai ales dacă mai multe proiecte, - și acest lucru se întâmplă de obicei dacă utilizați microservicii și doriți să rulați o conductă pentru testarea și livrarea codului din diferite depozite de proiecte. Acum puteți vedea imediat performanța conducte de pe panoul de control, oriunde sunt efectuate.
Rularea conductelor pentru rezultate îmbinate
De-a lungul timpului, ramurile sursă și țintă diferă și poate apărea o situație în care se descurcă separat, dar nu funcționează împreună. Acum poti rulați conducte pentru rezultatele îmbinate înainte de îmbinare. În acest fel, veți observa rapid erori care ar apărea doar dacă modificările au fost mutate frecvent între ramuri, ceea ce înseamnă că veți corecta erorile de conductă mult mai rapid și veți folosi GitLab Runner.
Optimizați în continuare colaborarea
GitLab 11.10 adaugă și mai multe funcții pentru o colaborare fără întreruperi și fluxuri de lucru simplificate. ÎN problema anterioară am introdus sugestii pentru solicitările de îmbinare, în care un examinator ar putea sugera o modificare a unui rând dintr-un comentariu la o solicitare de îmbinare și ar putea fi trimisă imediat direct din firul de comentarii. Utilizatorilor noștri le-a plăcut și au cerut să extindă această funcție. Acum poți oferi modificări pentru mai multe linii, indicând ce linii să eliminați și pe care să adăugați.
Cel mai valoros angajat din această lună (MVP) - Takuya Noguchi
Cel mai valoros angajat al acestei luni este Takuya Noguchi (Takuya Noguchi). Takuya a făcut o treabă bună pentru gloria GitLab: s-au remediat erori, s-au rezolvat deficiențele în backend și front-end și s-a îmbunătățit interfața cu utilizatorul. Mulțumesc!
Principalele caracteristici ale GitLab 11.10
Conducte pe panoul de control
PREMIUM, ULTIMATE, ARGINT, AUR
Tabloul de bord din GitLab afișează informații despre proiecte din întreaga instanță GitLab. Adăugați proiecte individuale pe rând și puteți alege care proiect vă interesează.
În această ediție, am adăugat informații despre stările conductelor în tabloul de bord. Acum dezvoltatorii văd funcționalitatea conductelor în toate proiectele necesare - într-o singură interfață.
Conducte pentru rezultate îmbinate
PREMIUM, ULTIMATE, ARGINT, AUR
Este obișnuit ca ramura sursă să divergă de la ramura țintă în timp, cu excepția cazului în care împingeți continuu modificări între ele. Drept urmare, conductele de ramuri sursă și țintă sunt „verzi” și nu există conflicte de îmbinare, dar îmbinarea eșuează din cauza modificărilor incompatibile.
Când conducta de solicitare de îmbinare creează automat o nouă legătură care conține rezultatul combinat al îmbinării ramurilor sursă și țintă, putem rula conducta pe legătura respectivă și ne asigurăm că rezultatul general funcționează.
Dacă utilizați conducte de solicitare de îmbinare (în orice calitate) și utilizați rulare GitLab private versiunea 11.8 sau mai veche, va trebui să le actualizați pentru a evita această problemă gitlab-ee#11122. Acest lucru nu afectează utilizatorii rulanților GitLab publici.
Când lucrați împreună la solicitări de fuziune, deseori identificați probleme și propuneți soluții. Începând cu GitLab 11.6, acceptăm propunere de modificari pentru o linie.
În versiunea 11.10, comentariile diferențelor cererii de îmbinare pot propune modificări la mai multe linii, iar apoi oricine are permisiuni de scriere în ramura originală le poate accepta cu un singur clic. Datorită noii caracteristici, puteți evita copy-paste, ca în versiunile anterioare.
Comenzi rapide într-o zonă
PREMIUM, ULTIMATE, ARGINT, AUR
Cu etichete în același domeniu, echipele pot aplica etichete care se exclud reciproc (în același domeniu) unei probleme, cereri de îmbinare sau epic în scenarii cu câmpuri personalizate sau stări personalizate ale fluxului de lucru. Acestea sunt configurate folosind o sintaxă specială de două puncte în titlul etichetei.
Să presupunem că aveți nevoie de un câmp personalizat în sarcini pentru a urmări sistemul de operare al platformei pe care o vizează funcțiile dvs. Fiecare sarcină trebuie să se refere la o singură platformă. Puteți crea comenzi rapide platform::iOS, platform::Android, platform::Linux și altele după cum este necesar. Dacă aplicați o astfel de comandă rapidă unei sarcini, aceasta va elimina automat o altă comandă rapidă existentă care începe cu platform::.
Să presupunem că aveți comenzi rapide workflow::development, workflow::review и workflow::deployed, indicând starea fluxului de lucru al echipei dvs. Dacă sarcina are deja o comandă rapidă workflow::development, iar dezvoltatorul dorește să mute sarcina în scenă workflow::review, se aplică doar noua comandă rapidă și cea veche (workflow::development) este ștearsă automat. Acest comportament există deja atunci când mutați sarcini între listele de comenzi rapide de pe panoul de activități care reprezintă fluxul de lucru al echipei dvs. Acum membrii echipei care nu lucrează direct cu panoul de activități pot schimba starea fluxului de lucru în sarcinile în sine.
Curățare mai minuțioasă a registrului containerelor
Când utilizați de obicei un registru de containere cu conducte CI, trimiteți mai multe modificări separate la o singură etichetă. Datorită implementării distribuției Docker, comportamentul implicit este de a salva toate modificările aduse sistemului, dar acestea ajung să ocupe multă memorie. Dacă utilizați parametrul -m с registry-garbage-collect, puteți șterge rapid toate modificările anterioare și puteți elibera spațiu prețios.
Achiziționarea de minute suplimentare CI Runner
BRONZ, ARGINT, AUR
Utilizatorii cu planuri GitLab.com plătite (aur, argint, bronz) pot acum achiziționa minute suplimentare CI Runner. Anterior, era necesară îndeplinirea cotei prevăzute în plan. Cu această îmbunătățire, puteți pre-achiziționa minute peste cotă pentru a evita întreruperile din cauza închiderii conductelor.
Acum 1000 de minute costă 8 USD și poți cumpăra câte dorești. Minutele suplimentare vor începe să fie utilizate când ați cheltuit întreaga cotă lunară, iar restul de minute suplimentare se vor transfera pentru luna următoare. ÎN lansare viitoare vrem să adăugăm această caracteristică și la planurile gratuite.
Cu Auto DevOps, echipele trec la practicile moderne DevOps aproape fără efort. Începând cu GitLab 11.10, fiecare job în Auto DevOps este furnizat ca șablon independent. Utilizatorii pot folosi функцию includes în GitLab CI pentru a activa etapele individuale ale Auto DevOps și, în același timp, pentru a utiliza fișierul personalizat gitlab-ci.yml. În acest fel, puteți activa doar lucrările de care aveți nevoie și puteți profita de actualizările din amonte.
Gestionați automat membrii grupului pe GitLab.com folosind SCIM
ARGINT, AUR
Anterior, trebuia să gestionați manual apartenența la grup pe GitLab.com. Acum puteți utiliza SAML SSO și gestionați calitatea de membru folosind SCIM pentru a crea, șterge și actualiza utilizatori pe GitLab.com.
Acest lucru este util în special pentru companiile cu un număr mare de utilizatori și furnizori centralizați de identitate. Acum puteți avea o singură sursă de adevăr, cum ar fi Azure Active Directory, iar utilizatorii vor fi creați și șterse automat prin furnizorul de identitate, mai degrabă decât manual.
Conectați-vă la GitLab.com prin intermediul furnizorului SAML
ARGINT, AUR
Anterior, când folosea SAML SSO pentru grupuri, utilizatorului i se cerea să se conecteze cu acreditările GitLab și un furnizor de identitate. Acum vă puteți conecta direct prin SSO ca utilizator GitLab asociat cu un grup configurat.
Utilizatorii nu vor trebui să se conecteze de două ori, ceea ce face mai ușor pentru companii să folosească SAML SSO pentru GitLab.com.
Alte îmbunătățiri în GitLab 11.10
Schema epică de copil
ULTIMATE, AUR
În versiunea anterioară, am adăugat epopee pentru copii (epopee de epopee) pentru a vă ajuta să vă gestionați structura de distribuție a locurilor de muncă. Epopeea copiilor apar pe pagina epicului părinte.
În această versiune, pagina epopee părinte afișează o schiță a epopeei copil, astfel încât echipele să poată vedea cronologia epopeilor copil și să poată gestiona dependențele de sincronizare.
În această versiune, introducem ecrane informative care apar atunci când treceți cu mouse-ul peste un link de solicitare de îmbinare. Anterior, arătăm doar titlul solicitării de îmbinare, dar acum arătăm și starea solicitării de îmbinare, starea conductei CI și adresa URL scurtă.
Fluxurile de lucru Git pentru lansarea sau livrarea de software implică adesea mai multe ramuri pe termen lung - pentru a face remedieri la versiunile anterioare (de ex. stable-11-9) sau trecerea de la testarea calității la producție (de ex. integration), dar nu este ușor să găsești cereri de îmbinare pentru aceste ramuri printre numeroasele cereri de îmbinare deschise.
Lista cererilor de îmbinare pentru proiecte și grupuri poate fi acum filtrată de ramura țintă a cererii de îmbinare pentru a facilita găsirea celei de care aveți nevoie.
Dacă folosim metoda de dezvoltare bazată pe Trunk, ar trebui să evităm ramurile cu viață lungă în favoarea ramurilor mici, temporare, cu un singur proprietar. Modificările mici sunt adesea împinse direct în ramura țintă, dar acest lucru riscă să rupă construcția.
Cu această ediție, GitLab acceptă noi opțiuni Git push pentru a deschide automat cererile de îmbinare, a seta ramura țintă și a impune o îmbinare pe o conductă de succes din linia de comandă în momentul trimiterii către ramură.
Integrare îmbunătățită cu tablouri de bord externe
GitLab poate accesa mai multe servere Prometheus (mediu, proiect și grupuri (așteptată)), dar având mai multe puncte finale poate adăuga complexitate sau poate să nu fie acceptat de tablourile de bord standard. Cu această versiune, echipele pot folosi un singur API Prometheus, facilitând mult integrarea cu servicii precum Grafana.
Într-un Wiki de proiect, echipele pot partaja documentație și alte informații importante, împreună cu codul sursă și sarcini. Cu această versiune, puteți sorta lista de pagini Wiki după data creării și titlu pentru a găsi rapid conținutul creat recent.
Monitorizarea resurselor solicitate de cluster
ULTIMATE, AUR
GitLab vă ajută să vă monitorizați clusterul Kubernetes pentru aplicații de dezvoltare și producție. Începând cu această ediție, monitorizați cererile CPU și memorie de la cluster pentru a identifica problemele potențiale înainte ca acestea să devină probleme.
Vedeți valorile Load Balancer în tabloul de bord Grafana
CORE, STARTER, PREMIUM, ULTIMATE
Este foarte important să monitorizați starea instanței dvs. GitLab. Anterior, am furnizat tablouri de bord implicite printr-o instanță Grafana încorporată. Începând cu această ediție, am inclus tablouri de bord suplimentare pentru monitorizarea echilibratorilor de încărcare NGINX.
SAST pentru Elixir
ULTIMATE, AUR
Continuăm să extindem suportul lingvistic și să aprofundăm verificările de securitate. În această ediție, am activat verificările de securitate pentru proiectele pe Elixir și proiectele create pe Platforma Phoenix.
Interogări multiple într-o singură diagramă
PREMIUM, ULTIMATE, ARGINT, AUR
În GitLab, puteți crea diagrame pentru a vizualiza valorile pe care le colectați. Adesea, de exemplu, dacă trebuie să vă uitați la valoarea maximă sau medie a unei valori, doriți să afișați mai multe valori pe un grafic. Începând cu această lansare, aveți această oportunitate.
Rezultatele DAST pe Tabloul de bord pentru securitatea grupului
Am adăugat rezultatele Testării dinamice de securitate a aplicațiilor (DAST) în tabloul de bord de securitate al echipei, pe lângă SAST, scanarea containerelor și scanarea dependențelor.
Adăugarea de metadate la un raport de scanare a containerului
ULTIMATE, AUR
În această versiune, Raportul de scanare a containerelor conține mai multe metadate - am adăugat componenta afectata (o caracteristică Clair) în metadatele existente: prioritate, identificator (cu referire la mitre.org) și nivelul afectat (de exemplu, debian:8).
Adăugarea unui tip de raport de valori la solicitările de îmbinare
PREMIUM, ULTIMATE, ARGINT, AUR
GitLab oferă deja mai multe tipuri de rapoarte care pot fi incluse direct în solicitările de îmbinare: de la rapoarte la calitatea codului и testarea unitară în etapa de verificare până la SAST и DAST în stadiul de protecţie.
Deși acestea sunt rapoarte importante, sunt necesare și informații de bază care se potrivesc diferitelor scenarii. În GitLab 11.10, oferim raportarea valorilor direct în cererea de îmbinare, care se așteaptă la o pereche cheie-valoare simplă. În acest fel, utilizatorii urmăresc modificările de-a lungul timpului, inclusiv valorile personalizate și modificările valorilor pentru o anumită solicitare de îmbinare. Utilizarea memoriei, testarea specializată a sarcinii de lucru și stările de sănătate pot fi convertite în valori simple care pot fi vizualizate direct în solicitările de îmbinare împreună cu alte rapoarte încorporate.
Suport pentru proiecte Maven cu mai multe module pentru scanarea dependențelor
ULTIMATE, AUR
Cu această versiune, proiectele Maven cu mai multe module acceptă scanarea dependenței GitLab. Anterior, dacă un submodul avea o dependență de un alt submodul de același nivel, nu putea permite încărcarea din depozitul central Maven. Acum este creat un proiect Maven cu mai multe module cu două module și o dependență între cele două module. Dependențele dintre modulele frate sunt acum disponibile în depozitul local Maven, astfel încât construcția să poată continua.
În mod implicit, GitLab Runner clonează proiectul într-o cale secundară unică în $CI_BUILDS_DIR. Dar pentru unele proiecte, cum ar fi Golang, codul trebuie să fie clonat într-un director specific pentru a fi construit.
În GitLab 11.10 am introdus variabila GIT_CLONE_PATH, care vă permite să specificați o cale specifică în care GitLab Runner clonează proiectul înainte de a executa sarcina.
Mascare simplă a variabilelor protejate în jurnale
GitLab oferă mai multe moduri защитить и limitează zona variabile în GitLab CI/CD. Dar variabilele pot ajunge în continuare în jurnalele de construcție, intenționat sau accidental.
GitLab ia în serios managementul riscurilor și auditul și continuă să adauge funcții de conformitate. În GitLab 11.10, am introdus capacitatea de a masca anumite tipuri de variabile în jurnalele de urmărire a joburilor, adăugând un nivel de protecție împotriva conținutului acestor variabile care sunt incluse accidental în jurnalele. Și acum GitLab automat măști multe variabile token încorporate.
Activați sau dezactivați Auto DevOps la nivel de echipă
Cu Auto DevOps pe un proiect GitLab.com, puteți prelua fluxurile de lucru DevOps moderne, de la compilare până la livrare, fără bătăi de cap.
Începând cu GitLab 11.10, puteți activa sau dezactiva Auto DevOps pentru toate proiectele din același grup.
Pagina de licență simplificată și îmbunătățită
STARTER, PREMIUM, ULTIMATE
Pentru a face gestionarea cheilor de licență mai convenabilă și mai simplă, am reproiectat pagina de licențe din panoul de administrare și am evidențiat cele mai importante elemente.
Actualizați selectorul de comenzi rapide pentru implementările Kubernetes
Panourile de implementare afișează informații despre toate implementările Kubernetes.
În această versiune, am schimbat modul în care mapăm comenzile rapide către implementări. Meciurile sunt acum disponibile de către app.example.com/app и app.example.com/env sau app. Acest lucru va evita conflictele de filtrare și riscul implementărilor incorecte asociate cu proiectul.
Integrarea Kubernetes cu GitLab vă permite să utilizați caracteristica RBAC folosind un cont de serviciu și un spațiu de nume dedicat pentru fiecare proiect GitLab. Începând cu această versiune, pentru o eficiență maximă, aceste resurse vor fi create numai atunci când sunt necesare pentru implementare.
La implementarea Kubernetes, GitLab CI va crea aceste resurse înainte de implementare.
Alergători de grup pentru grupuri la nivel de grup
Clusterele la nivel de grup acceptă acum instalarea GitLab Runner. Conducătorii Kubernetes la nivel de grup par proiectelor secundare ca alergători de grup etichetați cluster и kubernetes.
Caracteristici implementate cu GitLab fără server, arată acum numărul de apeluri primite pentru o anumită funcție. Pentru a face acest lucru, trebuie să instalați Prometheus pe cluster-ul în care este instalat Knative.
Controlul parametrilor git clean pentru joburi GitLab CI/CD
În mod implicit, GitLab Runner rulează git clean în timpul procesului de încărcare a codului la executarea unui job în GitLab CI/CD. Începând cu GitLab 11.10, utilizatorii pot controla parametrii trecuți unei echipe git clean. Acest lucru este util pentru echipele cu alergători dedicați, precum și pentru echipele care colectează proiecte din monorepozitive mari. Acum pot controla procesul de descărcare înainte de a executa scripturi. Variabilă nouă GIT_CLEAN_FLAGS valoarea implicită este -ffdx și acceptă toți parametrii de comandă posibili [git clean](https://git-scm.com/docs/git-clean).
Mediile securizate pot necesita o resursă suplimentară de autorizare externă pentru a accesa proiectul. Am adăugat suport pentru un nivel suplimentar de control al accesului în 10.6 și a primit multe solicitări de a deschide această funcționalitate în Core. Suntem încântați să introducem autorizarea externă și un nivel suplimentar de securitate pentru instanțele Core, deoarece această caracteristică este necesară participanților individuali.
Rolul de Dezvoltator poate crea proiecte în grupuri din versiunea 10.5, iar acum acest lucru este posibil în Core. Crearea proiectelor este o caracteristică cheie pentru productivitate în GitLab, iar prin includerea acestei caracteristici în Core, acum este mai ușor pentru membrii de exemplu să facă ceva nou.
Astăzi am lansat GitLab Runner 11.10! GitLab Runner este un proiect open source care este folosit pentru a rula joburi CI/CD și a trimite rezultatele înapoi la GitLab.
Lista completă a modificărilor poate fi găsită în jurnalul de modificări GitLab Runner: istoria schimbărilor.
Corectarea returnate project_id în API-ul de căutare blob din Elasticsearch
STARTER, PREMIUM, ULTIMATE
Am remediat o eroare în API-ul de căutare blob Elasticsearch care returna în mod eronat 0 pentru project_id. Va fi necesar reindexează Elasticsearchpentru a obține valorile corecte project_id după instalarea acestei versiuni de GitLab.
Îmbunătățiri Omnibus
CORE, STARTER, PREMIUM, ULTIMATE
Am adus următoarele îmbunătățiri la Omnibus în GitLab 11.10:
Este necesar GitLab Geo stocare hashed pentru a atenua concurența pe nodurile secundare. Acest lucru a fost notat în gitlab-ce#40970.
În GitLab 11.5 am adăugat această cerință la documentația Geo: gitlab-ee#8053.
În GitLab 11.6sudo gitlab-rake gitlab:geo:check verifică dacă stocarea hashing este activată și dacă toate proiectele sunt migrate. Cm. gitlab-ee#8289. Dacă utilizați Geo, vă rugăm să efectuați această verificare și să migrați cât mai curând posibil.
În GitLab 11.8 avertisment dezactivat permanent gitlab-ee!8433 va fi afișat pe pagină Zona de administrare > Geo > Nodurile, dacă verificările de mai sus nu sunt permise.
În GitLab 12.0 Geo va folosi cerințele de stocare prin hashing. Cm. gitlab-ee#8690.
Canonical a anunțat sfârșitul suportului standard pentru Ubuntu 14.04 Aprilie 2019. Vă sfătuim utilizatorii să facă upgrade la o versiune LTS acceptată: Ubuntu 16.04 sau Ubuntu 18.04.
Data ștergerii: 22 mai 2019 oraș
Limitarea numărului maxim de conducte create per trimitere
Anterior, GitLab a creat conducte pentru HEAD fiecare ramură din depunere. Acest lucru este convenabil pentru dezvoltatorii care fac mai multe modificări simultan (de exemplu, la o ramură de caracteristică și la o ramură develop).
Dar când împingeți un depozit mare cu multe ramuri active (de exemplu, mutare, oglindire sau ramificare), nu trebuie să creați o conductă pentru fiecare ramură. Începând cu GitLab 11.10, creăm maxim 4 conducte la trimitere.
Data ștergerii: 22 mai 2019 oraș
Căile vechi ale codului GitLab Runner învechite
Începând cu Gitlab 11.9, GitLab Runner folosește metoda noua clonarea/apelarea depozitului. În prezent, GitLab Runner va folosi metoda veche dacă cea nouă nu este acceptată. Vedeți mai multe detalii în aceasta sarcina.
În GitLab 11.0, am schimbat aspectul configurației serverului de metrici pentru GitLab Runner. metrics_server va fi înlăturat în favoarea listen_address în GitLab 12.0. Vedeți mai multe detalii în aceasta sarcina.
Aceste căi nu vor fi disponibile în GitLab 12.0. În calitate de utilizator, nu trebuie să modificați altceva decât să vă asigurați că instanța dvs. GitLab rulează versiunea 11.9+ atunci când faceți upgrade la GitLab Runner 12.0.
Data ștergerii: 22 iunie 2019 oraș
Parametru depreciat pentru caracteristica punct de intrare pentru GitLab Runner
În GitLab 12.0 vom trece la comportamentul corect ca și cum setarea caracteristicii ar fi dezactivată. Vedeți mai multe detalii în aceasta sarcina.
Data ștergerii: 22 iunie 2019 oraș
Suport depreciat pentru distribuția Linux care ajunge la EOL pentru GitLab Runner
Unele distribuții Linux pe care poate fi instalat GitLab Runner și-au îndeplinit scopul.
În GitLab 12.0, GitLab Runner nu va mai distribui pachete către astfel de distribuții Linux. O listă completă a distribuțiilor care nu mai sunt acceptate poate fi găsită în nostru documentație. Mulțumim lui Javier Ardo (Javier Jardon) per contribuția sa!
În GitLab 12.0, GitLab Runner este lansat folosind comenzi noi. Acest lucru se aplică numai utilizatorilor care suprascrie imaginea de ajutor. Vedeți mai multe detalii în aceasta sarcina.
Data ștergerii: 22 iunie 2019 oraș
Eliminarea mecanismului moștenit git clean din GitLab Runner
În GitLab Runner 11.10 oferim oportunitatea configurați modul în care Runner execută o comandă git clean. În plus, noua strategie de curățare elimină utilizarea git reset si pune comanda git clean după pasul de descărcare.
Deoarece această schimbare de comportament poate afecta unii utilizatori, am pregătit un parametru FF_USE_LEGACY_GIT_CLEAN_STRATEGY. Dacă setați valoarea true, va restabili strategia de curățare moștenită. Puteți găsi mai multe despre utilizarea parametrilor funcției în GitLab Runner în documentare.
În GitLab Runner 12.0, vom elimina suportul pentru strategia de curățare moștenită și capacitatea de a o restaura folosind un parametru de funcție. Vedeți mai multe detalii în aceasta sarcina.
Data ștergerii: 22 iunie 2019 oraș
Secțiunea Informații despre sistem din panoul de administrare
GitLab prezintă informații despre instanța dvs. GitLab în admin/system_info, dar este posibil ca aceste informații să nu fie exacte.
Gratuit: Arhive private nelimitate și număr nelimitat de colaboratori la proiect. Proiectele închise au acces la funcțiile de nivel GratuitAvea proiecte deschise au acces la funcțiile de nivel Aur.
Bronz: Pentru echipele care au nevoie de acces la funcții avansate de flux de lucru.
Silver: Pentru echipele care au nevoie de capabilități DevOps mai solide, conformitate și asistență mai rapidă.
Aur: Potrivit pentru multe lucrări CI/CD. Toate proiectele deschise pot folosi funcțiile Gold gratuit, indiferent de plan.