GitLab 11.10 cu pipeline-uri în panoul de control, pipeline-uri pentru rezultate unite și propuneri pentru mai multe linii în merge request-uri.
Informații utile despre funcționalitatea pipeline-urilor în diferite proiecte
GitLab continuă să crească transparența ciclului de viață DevOps. În această versiune, pe a fost adăugat un rezumat al stării pipeline-urilor.
Este convenabil, chiar dacă studiați un pipeline al unui singur proiect, dar este cu atât mai util dacă , ceea ce este de obicei cazul atunci când folosiți microservicii și doriți să rulați un pipeline pentru testarea și livrarea codului din diferite repo-uri de proiecte. Acum puteți vedea imediat funcționalitatea , oriunde s-ar desfășura acestea.
Rularea pipeline-urilor pentru rezultate unite
Cu timpul, ramurile sursă și țintă se îndepărtează, iar poate apărea situația în care fiecare funcționează individual, dar împreună nu. Acum puteți Astfel, veți observa rapid erorile care s-ar fi manifestat doar prin mutarea frecventă a modificărilor între ramuri, ceea ce înseamnă că veți repara mai repede erorile pipeline-ului și veți folosi mai eficient .
Optimizarea ulterioară a colaborării
În GitLab 11.10 au apărut și mai multe oportunități pentru colaborare convenabilă și fluxuri de lucru simplificate. În am introdus propuneri pentru merge request-uri, atunci când recenzentul putea sugera o modificare a unei singure linii în comentariul la merge request, și aceasta putea fi direct comisă din firul de comentarii. Utilizatorii noștri au apreciat acest lucru, iar ei ne-au cerut să extindem această caracteristică. Acum puteți propune specificând ce linii să eliminați și care să adăugați.
Vă mulțumim pentru feedback-ul și sugestiile dvs.!
Și asta nu e tot…
În această versiune sunt atât de multe funcționalități uimitoare, de exemplu, o curățare mai atentă , și posibilitatea Mai jos se găsesc detalii despre fiecare dintre ele.
Angajatul lunii () — Takuya Noguchi
În această lună, angajatul lunii este Takuya Noguchi (). Takuya : am corectat bug-uri, am finalizat lucrări în backend și frontend și am îmbunătățit interfața utilizatorului. Mulțumesc!
Caracteristicile principale GitLab 11.10
Pipelines pe panoul de control
PREMIUM, ULTIMATE, SILVER, GOLD
Pe panoul de control din GitLab sunt afișate informațiile despre proiectele din întreaga instanță GitLab. Adăugați proiecte individuale unul câte unul și puteți alege ce proiect vă interesează.
În această versiune, am adăugat informații despre statusurile pipeline-urilor pe panoul de control. Acum, dezvoltatorii pot vedea funcționalitatea pipeline-urilor în toate proiectele necesare - într-o singură interfață.
Pipelines pentru rezultate unificate
PREMIUM, ULTIMATE, SILVER, GOLD
De obicei, pe parcursul timpului, ramura sursă se abate de la ramura țintă, dacă nu faceți constant modificări între ele. Astfel, pipeline-urile ramurii sursă și ramurii țintă sunt 'verzi' și nu apar conflicte la îmbinare, dar la unificare apare o eroare din cauza incompatibilității modificărilor.
Când un pipeline de merge request creează automat un nou link care conține rezultatul unificat al îmbinării ramurii sursă și ramurii țintă, putem lansa pipeline-ul pe acest link și ne putem asigura că rezultatul comun va fi funcțional.
Dacă folosiți pipeline-uri de merge request (în orice calitate) și utilizați GitLab runners private versiunea 11.8 sau mai veche, acestea trebuie actualizate pentru a evita problemele. . Acest lucru nu afectează utilizatorii runners-urilor GitLab publice.
Propunerea de modificări în mai multe linii
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Atunci când lucrați împreună la merge requests, observați adesea probleme și propuneți soluții. Începând cu versiunea GitLab 11.6, susținem pentru o linie.
În versiunea 11.10, în comentariile de diffs ale merge request-ului se pot propune modificări pentru mai multe linii, iar apoi orice utilizator cu permisiuni de scriere în ramura sursă le poate accepta cu un singur clic. Datorită acestei noi caracteristici, se poate evita copierea și lipirea, ca în versiunile anterioare.
Etichete într-o singură zonă
PREMIUM, ULTIMATE, SILVER, GOLD
Cu etichete într-o singură zonă, echipele pot aplica etichete excludente (în aceeași zonă) pentru o sarcină, un merge request sau un epic în scenarii cu câmpuri personalizate sau stări personalizate ale fluxului de lucru. Acestea sunt configurate folosind o sintaxă specială cu 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 către care sunt destinate funcțiile dumneavoastră. Fiecare sarcină trebuie să se refere doar la o singură platformă. Puteți crea etichete platform::iOS, platform::Android, platform::Linux și altele, după cum este necesar. Dacă aplicați o astfel de etichetă la o sarcină, o etichetă existentă care începe cu platform::.
Să presupunem că aveți etichete workflow::development, workflow::review și workflow::deployed, care indică starea fluxului de lucru din echipa dumneavoastră. Dacă o sarcină are deja o etichetă workflow::development, iar dezvoltatorul dorește să treacă sarcina la etapa workflow::review, el aplică pur și simplu o etichetă nouă, iar cea veche (workflow::development) este ștearsă automat. Această comportare există deja atunci când mutați sarcinile între listele de etichete pe tabloul de sarcini, care reprezintă fluxul de lucru al echipei dumneavoastră. Acum, membrii echipei care nu lucrează direct cu tabloul de sarcini pot schimba starea fluxului de lucru în sarcini.
Curățare mai amănunțită a registrului containerelor
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
În utilizarea obișnuită a registrului containerelor cu pipeline-uri CI, trimiteți mai multe modificări separate într-un singur tag. Din cauza implementării distribuției Docker, comportamentul implicit este de a păstra toate modificările în sistem, dar în cele din urmă acestea ocupă multă memorie. Dacă folosiți parametrul -m de registry-garbage-collect, puteți șterge rapid toate modificările anterioare și eliberați spațiu prețios.
Achiziționarea de minute suplimentare pentru CI Runner
BRONZE, SILVER, GOLD
Utilizatorii cu planuri plătite GitLab.com (Gold, Silver, Bronze) pot acum achiziționa minute suplimentare pentru CI Runner. În trecut, trebuia să vă încadrați în cota prevăzută de plan. Datorită acestei îmbunătățiri, puteți achiziționa minute din avans peste cotă pentru a evita întreruperile în muncă din cauza opririi pipeline-urilor.
În prezent, 1000 de minute costă 8 dolari și le puteți achiziționa oricât doriți. Minutele suplimentare vor începe să se consume atunci când veți folosi întreaga cotă lunară, iar restul minutei suplimentare se transferă în luna următoare. În dorim să adăugăm această funcție și în planurile gratuite.
Auto DevOps compus
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Cu Auto DevOps, echipele adoptă practici moderne DevOps aproape fără efort. Începând cu GitLab 11.10, fiecare job din Auto DevOps este furnizat sub formă de . Utilizatorii pot folosi în GitLab CI pentru a include etape separate Auto DevOps și în același timp să folosească fișierul lor personalizat gitlab-ci.yml. Astfel, se pot activa doar job-urile necesare și se pot beneficia de actualizările din upstream.
Gestionarea automată a membrilor grupului pe GitLab.com cu ajutorul SCIM
SILVER, GOLD
Anterior, gestionarea membrilor în grupurile de pe GitLab.com se făcea manual. Acum se poate utiliza SAML SSO și se poate gestiona membrul cu SCIM pentru a crea, elimina și actualiza utilizatorii pe GitLab.com.
Acest lucru este deosebit de util pentru companiile cu un număr mare de utilizatori și furnizori de identitate centralizați. Acum puteți avea o sursă unică de adevăr, cum ar fi Azure Active Directory, iar utilizatorii vor fi creați și eliminați automat prin intermediul furnizorului de identitate, nu manual.
Autentificarea pe GitLab.com prin intermediul furnizorului SAML
SILVER, GOLD
Anterior, când se folosea SAML SSO pentru grupuri, utilizatorul trebuia să se conecteze cu acreditivele GitLab și cu furnizorul de identitate. Acum se poate autentifica direct prin SSO ca utilizator GitLab legat de grupul configurat.
Utilizatorii nu vor mai fi nevoiți să se conecteze de două ori, ceea ce face utilizarea SAML SSO pentru GitLab.com mai convenabilă pentru companii.
Alte îmbunătățiri în GitLab 11.10
Schema epicoarelor subordonate
ULTIMATE, GOLD
În versiunea anterioară am adăugat epicoare subordonate (epicoare ale epicoarelor) pentru a facilita gestionarea structurii de distribuție a sarcinilor. Epicoarele subordonate sunt afișate pe pagina epicolui părinte.
În această versiune, pe pagina epicolui părinte este afișată schema epicoarelor subordonate, astfel echipele pot vedea cronologia epicoarelor subordonate și pot gestiona dependențele temporale.
Ecrane pop-up pentru cererile de fuzionare
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
În această versiune, prezentăm ecrane informative care apar la trecerea cu mouse-ul peste linkul cererii de fuzionare. Anterior, afișam doar titlul cererii de fuzionare, iar acum afișăm și statusul cererii de fuzionare, statusul CI-pipeline-ului și un URL scurt.
În viitoarele versiuni, intenționăm să adăugăm mai multe informații importante, cum ar fi , și de asemenea, vom introduce ecrane pop-up pentru .
Filtrarea cererilor de fuzionare după ramurile țintă
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Procesele Git pentru lansarea sau livrarea software-ului sunt adesea legate de mai multe ramuri pe termen lung – pentru a aplica corecții în versiunile anterioare (de exemplu, stable-11-9) sau pentru a trece de la controlul calității la producție (de exemplu, integration), dar nu este atât de simplu să găsești cererile de combinare pentru aceste ramuri printre numeroasele cereri de combinare deschise.
Lista cererilor de combinare pentru proiecte și grupuri poate fi acum filtrată după ramura țintă a cererilor de combinare, pentru a fi mai ușor să găsești ceea ce ai nevoie.
Mulțumesc, Hiroyuki Sato ()!
Încărcarea și combinarea la un pipeline de succes
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Dacă folosim metoda de dezvoltare bazată pe ramura principală, trebuie să evităm ramurile pe termen lung în favoarea ramurilor temporare, mici, cu un singur proprietar. Schimbările minore sunt adesea trimise direct în ramura țintă, dar în acest caz riscăm să stricam compilarea.
În această versiune, GitLab suportă parametrii noi pentru încărcare în Git, pentru a deschide automat cererile de combinare, a seta ramura țintă și a asigura combinarea la un pipeline de succes din linia de comandă în timpul încărcării ramurii.
Integrare îmbunătățită cu panouri de monitorizare externe
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
GitLab poate accesa mai multe servere Prometheus (la nivel de mediu, proiect și ), dar având mai multe puncte finale poate complica sistemul sau nu este suportat de panourile de monitorizare standard. În această versiune, echipele pot utiliza un singur API Prometheus, ceea ce simplifică semnificativ integrarea cu astfel de servicii ca Grafana.
Sortarea paginilor Wiki după data creării
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
În Wiki-ul proiectului, echipele pot împărtăși documentația și alte informații importante alături de codul sursă și sarcini. În această versiune, lista paginilor din Wiki poate fi sortată după data creării și titlu, pentru a găsi rapid conținutul recent creat.
Monitorizarea resurselor solicitate de cluster
ULTIMATE, GOLD
GitLab ajută la monitorizarea clusterului Kubernetes pentru aplicațiile dezvoltate și în funcțiune. Începând din această versiune, urmăriți resursele solicitate de cluster, procesorul și memoria, pentru a observa posibilele dificultăți înainte ca acestea să devină probleme.
Vizualizarea metricilor de echilibrare a încărcării pe panoul de monitorizare Grafana
CORE, STARTER, PREMIUM, ULTIMATE
Este foarte important să urmăriți funcționarea instanței GitLab. Anterior, ofeream panouri de monitorizare prin intermediul instanței încorporate Grafana. Începând cu această versiune, am inclus panouri suplimentare pentru monitorizarea echilibratoarelor de încărcare NGINX.
SAST pentru Elixir
ULTIMATE, GOLD
Continuăm să extindem suportul pentru limbaje și să aprofundăm verificările de securitate. În această versiune, am inclus verificări de securitate pentru proiecte în și proiectele create pe .
Mai multe cereri într-un singur grafic
PREMIUM, ULTIMATE, SILVER, GOLD
În GitLab, puteți crea grafice pentru a vizualiza metricile colectate. Adesea — de exemplu, dacă este necesar să vizualizați valoarea maximă sau medie a unei metrici — doriți să afișați mai multe valori pe un singur grafic. Începând cu această versiune, aveți această posibilitate.
Rezultatele DAST pe panoul de securitate al grupului
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Am adăugat rezultatele testării de securitate dinamice a aplicațiilor (Dynamic Application Security Testing, DAST) pe panoul de securitate al grupului, pe lângă SAST, scanarea containerelor și scanarea dependențelor.
Adăugarea de metadate în raportul de scanare a containerelor
ULTIMATE, GOLD
În această versiune, raportul de scanare a containerelor conține mai multe metadate — am adăugat componenta afectată (funcția Clair) la metadatele existente: prioritate, identificator (cu referire la mitre.org) și nivelul afectat (de exemplu, debian:8).
Adăugarea tipului de raport pe metrici în cererile de fuzionare
PREMIUM, ULTIMATE, SILVER, GOLD
GitLab oferă deja mai multe tipuri de rapoarte care pot fi incluse direct în cererile de fuzionare: de la rapoarte despre și în etapa de revizuire până la și în etapa de protecție.
Și, deși acestea sunt rapoarte importante, informațiile de bază, care sunt utile pentru diferite scenarii, sunt, de asemenea, necesare. În GitLab 11.10, oferim rapoarte pe metrici direct în cererea de fuziune, care așteaptă o simplă pereche cheie-valoare. Astfel, utilizatorii pot urmări modificările în timp, inclusiv metricile personalizate, și modificările metricilor pentru o anumită cerere de fuziune. Utilizarea memoriei, testarea sarcinilor specializate și statusurile de funcționare pot fi transformate în metrice simple, care pot fi vizualizate direct în cererile de fuziune, alături de alte rapoarte încorporate.
Suport pentru proiectele multimodale Maven pentru scanarea dependențelor
ULTIMATE, GOLD
În această versiune, proiectele multimodale Maven susțin scanarea dependențelor GitLab. Anterior, dacă un submodul avea o dependență de un alt submodul de același nivel, nu putea rezolva descărcarea din depozitul central Maven. Acum, un proiect multimodal Maven este creat cu două module și o dependență între cele două module. Dependența dintre modulele de același nivel este acum disponibilă în depozitul local Maven, astfel încât construcția să poată continua.
Utilizatorii pot schimba calea pentru clonare în CI
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Implicit, GitLab Runner clonează proiectul într-o cale unică și înfășurată în $CI_BUILDS_DIR. Dar pentru unele proiecte, cum ar fi Golang, codul trebuie clonat într-un director specific pentru a putea fi construit.
În GitLab 11.10, am introdus o variabilă GIT_CLONE_PATH, care permite specificarea unei căi exacte unde GitLab Runner clonează proiectul înainte de a executa sarcina.
Mascare simplă a variabilelor protejate în jurnale
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
GitLab oferă mai multe metode și variabilelor în GitLab CI/CD. Totuși, variabilele pot ajunge intenționat sau accidental în jurnalele de construcție.
GitLab ia în serios gestionarea riscurilor și auditul și continuă să adauge funcții pentru a respecta cerințele. În GitLab 11.10, am introdus posibilitatea de a mascati anumite tipuri de variabile în jurnalele traseelor, adăugând un nivel de protecție împotriva apariției accidentale a conținutului acestor variabile în jurnale. De asemenea, GitLab acum multe variabile integrate de tip token.
Activarea și dezactivarea Auto DevOps la nivel de grup
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Cu Auto DevOps în proiectul GitLab.com, poți aborda fără efort fluxurile de lucru DevOps moderne — de la construcție la livrare.
Începând cu GitLab 11.10, poți activa și dezactiva Auto DevOps pentru toate proiectele dintr-un grup.
Pagină de licențe simplificată și îmbunătățită
STARTER, PREMIUM, ULTIMATE
Pentru a facilita gestionarea cheilor de licență, am modificat designul paginii de licențe din panoul de administrare și am evidențiat cele mai importante elemente.
Actualizarea selectorului de etichete pentru implementările Kubernetes
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Pe panourile de implementare sunt afișate informații despre toate implementările Kubernetes.
În această versiune, am schimbat modul de asociere a etichetelor cu implementările. Acum sunt disponibile corespondențe pe app.example.com/app și app.example.com/env sau app. Aceasta va evita conflictele la filtrare și riscurile de desfășurare greșită legate de proiect.
În plus, în versiunea GitLab 12.0 noi , iar potrivirea va fi posibilă doar pe app.example.com/app și app.example.com/env.
Crearea dinamică a resurselor Kubernetes
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Integrarea Kubernetes în GitLab permite utilizarea funcției RBAC prin intermediul unui cont de serviciu și a unui spațiu de nume dedicat fiecărui proiect GitLab. Începând cu această versiune, pentru o eficiență maximă, aceste resurse vor fi create doar atunci când sunt necesare pentru desfășurare.
La desfășurarea Kubernetes, GitLab CI va crea aceste resurse înainte de desfășurare.
Runners de grup pentru clustere la nivel de grup
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Clusterele la nivel de grup acum acceptă instalarea GitLab Runner. Runners Kubernetes la nivel de grup sunt afișați pentru proiectele derivate ca runners de grup, etichetați cu cluster și kubernetes.
Contor de apeluri pentru funcțiile Knative
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Funcțiile desfășurate cu , acum arată numărul apelurilor primite pentru fiecare funcție. Pentru aceasta, este necesară instalarea Prometheus în clusterul care găzduiește Knative.
Controlul parametrilor git clean pentru joburile GitLab CI/CD
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
În mod implicit, GitLab Runner execută git clean în procesul de descărcare a codului în timpul executării unui job în GitLab CI/CD. Începând cu GitLab 11.10, utilizatorii pot controla parametrii transmiși comenzii git clean. Aceasta este convenabilă pentru echipele cu runners dedicate, precum și pentru echipele care construiesc proiecte din monorepo-uri mari. Acum pot gestiona procesul de descărcare înainte de executarea scripturilor. Noua variabilă GIT_CLEAN_FLAGS are în mod implicit valoarea -ffdx și acceptă toate parametrii posibili ai comenzii [git clean](https://git-scm.com/docs/git-clean).
Autentificare externă în Core
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Mediile securizate pot solicita o resursă externă suplimentară de autentificare pentru accesul la proiect. Am adăugat suport pentru un nivel suplimentar de control al accesului în și am primit multe solicitări pentru a deschide această funcționalitate în Core. Suntem încântați să prezentăm autentificarea externă și un nivel suplimentar de securitate pentru instanțele Core, din moment ce această caracteristică este necesară pentru participanții separați.
Posibilitatea de a crea proiecte în grupuri în Core
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Rolul Developer poate crea proiecte în grupuri , iar acum este posibil și în Core. Crearea de proiecte este o funcționalitate cheie pentru o muncă productivă în GitLab, iar prin includerea acestei funcții în Core, participanții la instanță pot acum mai ușor să se apuce de ceva nou.
GitLab Runner 11.10
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Astăzi am lansat GitLab Runner 11.10! GitLab Runner este un proiect cu sursă deschisă care este utilizat pentru a rula sarcini CI/CD și a trimite rezultatele înapoi în GitLab.
Cele mai interesante modificări:
- .
- .
- .
- .
- .
Lista completă a modificărilor poate fi găsită în jurnalul de modificări GitLab Runner: .
Corectarea valorii returnate project_id în API-ul de căutare blob în Elasticsearch
STARTER, PREMIUM, ULTIMATE
Am corectat o eroare în API-ul de căutare blob în Elasticsearch care returna greșit 0 pentru project_id. Va trebui , pentru a obține valori corecte project_id după instalarea acestei versiuni GitLab.
Îmbunătățiri Omnibus
CORE, STARTER, PREMIUM, ULTIMATE
Am adus următoarele îmbunătățiri în Omnibus în GitLab 11.10:
- GitLab 11.10 include , , al cărei ultim release include un nou catalog de integrare pentru transferul ușor de date din Hipchat și multe altele. Această versiune include , și recomandăm să faceți upgrade.
- Noi , iar acum este foarte simplu să începeți monitorizarea instanței GitLab.
- Am adăugat suport pentru ștergerea imaginilor vechi ale containerelor din registrul Docker.
- Am actualizat ca-cert-urile la 2019-01-23.
Îmbunătățiri ale performanței
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Continuăm să îmbunătățim performanța GitLab la fiecare lansare pentru instanțele GitLab de orice dimensiune. Unele îmbunătățiri în GitLab 11.10:
- .
- .
- .
- .
- .
- .
- .
- .
Îmbunătățire pentru diagramele GitLab
CORE, STARTER, PREMIUM, ULTIMATE
Am adus următoarele îmbunătățiri pentru diagramele GitLab:
- .
Funcții învechite
GitLab Geo va asigura stocarea hash-ată în GitLab 12.0
GitLab Geo este necesar pentru a reduce concurența pe nodurile secundare. Acest lucru a fost menționat în .
În GitLab am adăugat această cerință în documentația Geo: .
În GitLab sudo gitlab-rake gitlab:geo:check verifică dacă stocarea hash-ată este activată și dacă toate proiectele sunt migrate. Vezi . Dacă folosești Geo, te rugăm să rulezi această verificare și să migrezi cât mai curând posibil.
În GitLab avis constant de deconectare va fi afisat pe pagina Zona de Administrare › Geo › Noduri, în cazul în care verificările menționate nu sunt permise.
În GitLab Geo va utiliza cerințele pentru stocarea hash-ată. Vezi .
Data eliminării: 22 iunie 2019.
Suport pentru Ubuntu 14.04
GitLab 11.10 va fi ultima versiune cu .
Canonical a anunțat încetarea suportului standard pentru Ubuntu 14.04 începând cu . Recomandăm utilizatorilor să treacă la o versiune LTS susținută: Ubuntu 16.04 sau Ubuntu 18.04.
Data eliminării: 22 mai 2019.
Limitarea numărului maxim de pipeline-uri create de o singură trimitere
Anterior, GitLab crea pipeline-uri pentru HEAD fiecare ramură din trimitere. Aceasta este convenabilă pentru dezvoltatori care trimit mai multe modificări deodată (de exemplu, în ramura de funcționalitate și în ramura develop).
Însă, atunci când se trimite un depozit mare, unde există multe ramuri active (de exemplu, pentru mutare, replicare sau ramificare), nu este necesar să se creeze un pipeline pentru fiecare ramură. Începând cu GitLab 11.10, creăm la trimitere.
Data eliminării: 22 mai 2019.
Cărți de cod legacy învechite ale GitLab Runner
Începând cu Gitlab 11.9, GitLab Runner folosește clonării/apelării repository-ului. În prezent, GitLab Runner va utiliza vechea metodă, dacă noua nu este suportată. Aflați mai multe în .
În GitLab 11.0 am modificat structura de configurare a serverului de metrici pentru GitLab Runner. metrics_server va fi eliminat în favoarea listen_address în GitLab 12.0. Aflați mai multe în .
În versiunea 11.3, GitLab Runner a început să suporte ; ceea ce a dus la noi setări pentru . În , aici este un tabel cu modificările și instrucțiunile pentru trecerea la noua configurație. Aflați mai multe în .
Aceste căi nu vor fi disponibile în GitLab 12.0. Ca utilizator, nu trebuie să schimbați nimic, doar asigurați-vă că instanța GitLab funcționează cu versiunea 11.9+ atunci când faceți upgrade la GitLab Runner 12.0.
Data eliminării: 22 iunie 2019.
Parametrul învechit pentru funcția de punct de intrare pentru GitLab Runner
În 11.4, GitLab Runner a introdus parametrul funcției pentru a remedia probleme precum și .
În GitLab 12.0, ne vom schimba comportamentul pentru a fi corect, ca și cum parametrul funcției ar fi dezactivat. Aflați mai multe în .
Data eliminării: 22 iunie 2019.
Suportul învechit pentru distribuțiile Linux care au ajuns la EOL pentru GitLab Runner
Unele distribuiti Linux în care poate fi instalat GitLab Runner și-au încheiat ciclul de viață.
În GitLab 12.0, GitLab Runner nu va mai distribui pachete pentru aceste distribuții Linux. Lista completă a distribuțiilor care nu mai sunt suportate poate fi găsită în . Mulțumim lui Javier Ardo () pentru !
Data eliminării: 22 iunie 2019.
Eliminarea comenzilor vechi GitLab Runner Helper
Ca parte a eforturilor de suport a fost necesar să renunțăm la unele comenzi vechi folosite pentru .
În GitLab 12.0, GitLab Runner se va lansa cu noi comenzi. Acest lucru se aplică doar utilizatorilor care . Aflați mai multe în .
Data eliminării: 22 iunie 2019.
Eliminarea mecanismului git clean legacy din GitLab Runner
În GitLab Runner 11.10 de a configura modul în care Runner execută comanda git clean. În plus, noua strategie de curățare elimină utilizarea git reset și plasează comanda git clean după etapa de descărcare.
Deoarece această schimbare de comportament poate afecta anumiți utilizatori, am pregătit parametrul FF_USE_LEGACY_GIT_CLEAN_STRATEGY. Dacă se setează valoarea true, va restaura strategia de curățare legacy. Mai multe informații despre utilizarea parametrilor de funcții în GitLab Runner pot fi găsite .
În GitLab Runner 12.0, vom elimina suportul pentru strategia de curățare legacy și posibilitatea de a o restaura cu ajutorul parametrului funcției. Aflați mai multe în .
Data eliminării: 22 iunie 2019.
Sectiunea Informații Sistem în panoul de administrare
GitLab afișează informațiile despre instanța dvs. GitLab în admin/system_info, dar aceste informații pot fi inexacte.
Noi a panoului de administrare în GitLab 12.0 și recomandăm utilizarea .
Data eliminării: 22 iunie 2019.
Jurnal de modificări
Căutați toate aceste modificări în jurnalul de modificări:
Instalare
Dacă configurați o nouă instalare GitLab, vizitați .
Actualizare
Vizitați .
Planurile de abonament GitLab
GitLab este disponibil în două variante: și .
: local sau pe platforma cloud preferată.
- Nucleu: pentru echipe mici, proiecte personale sau versiuni de încercare GitLab fără limită de timp.
- Starter: pentru echipe care lucrează într-un singur birou la mai multe proiecte care necesită suport profesional.
- Premium: pentru echipe distribuite care au nevoie de funcții avansate, disponibilitate ridicată și suport 24/7.
- Ultimate: pentru companii care necesită o strategie solidă și implementare cu securitate îmbunătățită și conformitate.
— GitLab.com: găzduit, administrat și administrat de GitLab în pentru dezvoltatori și echipe individuale.
- Gratuit: repo-uri private nelimitate și număr nelimitat de participanți la proiect. Proiectele închise au acces la funcții de nivel Gratuit, iar au acces la funcții de nivel Gold.
- Bronze: pentru echipe care necesită acces la funcții avansate de flux de lucru.
- Silver: pentru echipe care necesită capacități DevOps mai fiabile, conformitate și suport rapid.
- Gold: este potrivit pentru numeroase joburi CI/CD. Toate proiectele deschise pot utiliza gratuit funcțiile Gold, indiferent de plan.
Sursa: habr.com
