ProHoster > Blog > uprava > # GitLab 13.4 je objavljen s HashiCorp pohranom za CI varijable i Kubernetes Agentom
# GitLab 13.4 je objavljen s HashiCorp pohranom za CI varijable i Kubernetes Agentom
Izdanje 13.4 objavljeno je s HashiCorp pohranom za CI varijable, Kubernetes Agentom i sigurnosnim centrom, kao i promjenjivim značajkama u Starteru
U GitLabu uvijek razmišljamo o tome kako možemo pomoći korisnicima u smanjenju rizika, poboljšanju učinkovitosti i brzini isporuke na vašoj omiljenoj platformi. Ovaj smo mjesec dodali puno korisnih novih značajki koje proširuju sigurnosne mogućnosti, smanjuju broj ranjivosti, povećavaju učinkovitost, pojednostavljuju rad s GitLabom i pomažu vašem timu da još brže isporuči značajke. Nadamo se da će vam glavne značajke izdanja biti korisne 53 druge nove značajke, dodano u ovom izdanju.
Drugi način smanjenja rizika je korištenje novih GitLab Kubernetes agent. Operativni timovi mogu implementirati Kubernetes klastere iz GitLaba bez potrebe da svoj klaster izlažu cijelom internetu. Također predstavljamo podršku za automatsku kontrolu verzija za nove datoteke stanja Terraform Terraform stanje kojim upravlja GitLab za podršku usklađenosti i jednostavnosti otklanjanja pogrešaka. Konačno, postala je sigurnosna nadzorna ploča instance GitLab sigurnosni centar s izvješćima o ranjivostima i sigurnosnim postavkama.
Fabio je značajno pridonio doprinos в prikazivanje pokrivenosti koda u razlikama zahtjeva za spajanje - značajka koja se jako dugo čekala u GitLab zajednici. Ovo je uistinu važan doprinos s netrivijalnim promjenama koje su zahtijevale stalnu suradnju s članovima GitLab tima i utjecale na mnoga područja projekta kao što su UX, front-end i back-end.
U izdanju 12.10 GitLab je uveo mogućnost primanja i prijenosa ključeva za CI poslove pomoću GitLab rukovatelja poslovima (GitLab runner). Sada se širimo provjera autentičnosti pomoću JWT-a, dodajući novu sintaksu secrets podnijeti .gitlab-ci.yml. To će olakšati postavljanje i korištenje HashiCorp repozitorija s GitLabom.
GitLabova integracija s Kubernetesom odavno je omogućila implementaciju u Kubernetes klastere bez potrebe za ručnom konfiguracijom. Mnogim korisnicima se svidjela jednostavnost korištenja ovog paketa, dok su drugi naišli na neke poteškoće. Za trenutnu integraciju, vaš klaster mora biti dostupan s interneta kako bi mu GitLab mogao pristupiti. Za mnoge organizacije to nije moguće jer ograničavaju pristup klasterima zbog sigurnosti, usklađenosti ili regulatornih razloga. Kako bi zaobišli ta ograničenja, korisnici su morali izgraditi svoje alate na temelju GitLaba, inače ne bi mogli koristiti ovu značajku.
Danas predstavljamo GitLab Kubernetes Agent, novi način implementacije u Kubernetes klastere. Agent radi unutar vašeg klastera, tako da ga ne morate izlagati cijelom Internetu. Agent koordinira implementaciju zahtijevajući nove promjene od GitLaba, umjesto da GitLab gura ažuriranja u klaster. Bez obzira koju GitOps metodu koristite, GitLab vas pokriva.
Imajte na umu da je ovo prvo izdanje agenta. Naš trenutni fokus za GitLab Kubernetes Agent je konfiguracija i upravljanje implementacijama putem koda. Neke postojeće značajke integracije Kubernetesa, kao što su ploče za implementaciju i aplikacije kojima upravlja GitLab, još nisu podržane. Pretpostavljamoda će te mogućnosti biti dodane agentu u budućim izdanjima, kao i nove integracije usmjerene na sigurnost i usklađenost.
Prethodno je GitLabov sustav dopuštenja otežavao pravilnu podjelu odgovornosti unutar vašeg tima između onih odgovornih za razvoj i onih odgovornih za implementaciju. S izdanjem GitLaba 13.4, možete dati dopuštenje za odobravanje zahtjeva za spajanje za implementaciju, kao i za stvarno implementiranje koda osobama koje ne pišu kod, bez davanja prava pristupa održavatelja (u ruskoj lokalizaciji GitLaba "održavač" ).
Prethodno je upravljanje ranjivostima na razini instance bilo ograničeno u funkcionalnosti i fleksibilnosti. Sučelje je bila jedna stranica koja kombinira pojedinosti o ranjivostima, metričke grafikone i postavke. Nema puno prostora za razvoj ovih značajki ili korištenje drugih sigurnosnih značajki.
Napravili smo temeljne promjene u načinu na koji upravljamo sigurnošću i transparentnošću u GitLabu. Sigurnosna ploča instance pretvorena je u cijeli sigurnosni centar. Najveća promjena je uvođenje nove strukture izbornika: umjesto jedne stranice, sada zasebno vidite sigurnosnu nadzornu ploču, izvješće o ranjivosti i odjeljak postavki. Iako se funkcionalnost nije promijenila, rastavljanje na dijelove omogućit će poboljšanja ovog odjeljka koja bi inače bila teška. Ovo također postavlja temelje za dodavanje drugih sigurnosnih mogućnosti u budućnosti.
Namjenski odjeljak Izvješće o ranjivosti sada ima više prostora za prikaz važnih detalja. Ovdje su ranjivosti koje su trenutno na popisu ranjivosti projekta. Premještanje widgeta s metrikom ranjivosti u zaseban odjeljak stvara praktičnu sigurnosnu kontrolnu ploču. Sada je to platno za buduće vizualizacije—ne samo za upravljanje ranjivostima, već i za sve metrike povezane sa sigurnošću. Konačno, zasebno područje postavki stvara zajednički prostor za sve sigurnosne postavke na razini instance, a ne samo za upravljanje ranjivostima.
Ranije ove godine, GitLab se obvezao potez 18 značajke u otvoreni kod. U ovom smo izdanju dovršili migraciju promjenjivih značajki na početni plan i nastavit ćemo ih migrirati na Core s Git Lab 13.5. Uzbuđeni smo što ovu značajku možemo ponuditi većem broju korisnika i želimo čuti kako je koristite.
Ponekad prilikom navigacije GitLabom želite otići ravno na određeni projekt, a ne na stranicu s rezultatima pretraživanja.
Pomoću trake za globalno pretraživanje možete brzo doći do najnovijih ulaznica, grupa, projekata, postavki i tema pomoći. Možete čak koristiti i prečac /da pomaknete pokazivač na traku za pretraživanje kako biste još učinkovitije kretali GitLabom!
Prilikom pregledavanja zahtjeva za spajanje može biti teško utvrditi je li promijenjeni kod pokriven jediničnim testovima. Umjesto toga, recenzenti se mogu osloniti na ukupnu pokrivenost i zatražiti da se poveća prije nego što odobre zahtjev za spajanje. To može dovesti do slučajnog pristupa pisanju testova, koji zapravo neće poboljšati kvalitetu koda ili pokrivenost testa.
Sada, kada gledate razliku zahtjeva za spajanje, vidjet ćete vizualni prikaz pokrivenosti koda. Nove oznake omogućit će vam da brzo shvatite je li promijenjeni kod obuhvaćen testom jedinice, što će pomoći ubrzati pregled koda i vrijeme spajanja i implementacije novog koda.
Od izdanja GitLaba 12.5 koristi se okolišne ploče možete pratiti stanje okruženja, ali ne više od sedam okruženja u tri projekta. Poboljšali smo ovu ploču u izdanju 13.4 paginacijom kako bismo vam pomogli u održavanju i upravljanju vašim okruženjima na velikom broju. Sada možete vidjeti više okruženja u više projekata.
API fuzzing testiranje izvrstan je način za pronalaženje grešaka i ranjivosti u vašim web aplikacijama i API-jima koje bi drugi skeneri i metode testiranja mogli propustiti.
API fuzzing testiranje u GitLabu omogućuje vam pružanje OpenAPI v2 specifikacija ili HAR datoteka svoju aplikaciju, a zatim automatski generira nasumične ulazne podatke dizajnirane za testiranje rubnih slučajeva i pronalaženje grešaka. Rezultati su odmah vidljivi u vašem kanalu.
Ovo je naše prvo izdanje za testiranje fuzz API-ja i voljeli bismo čuti što mislite. Imamo više na zalihama za fuzz testiranje mnogo ideja, koji ćemo temeljiti na izdanju ove značajke.
Ranije stvaranje grafikona na nadzornoj ploči metrike u GitLabu nije bio lak zadatak. Nakon što ste stvorili metriku u YAML datoteci nadzorne ploče, izvršili ste promjene u master, bez mogućnosti provjere radi li novostvoreni grafikon točno onako kako vam je potrebno. Počevši od ovog izdanja, možete pregledati promjene dok stvarate grafikon, dobivajući predodžbu o rezultatu prije slanja promjena u YAML datoteku nadzorne ploče.
Kada upravljate velikim brojem projekata u GitLabu, potreban vam je jedan izvor informacija o tome kako se pokrivenost koda mijenja tijekom vremena u svim projektima. Prethodno je prikazivanje ovih informacija zahtijevalo naporan i dugotrajan ručni rad: morali ste preuzeti podatke o pokrivenosti koda iz svakog projekta i kombinirati ih u tablicu.
U izdanju 13.4 postalo je moguće jednostavno i brzo sastaviti .csv datoteka sa svim podacima o pokrivenosti kodom za sve projekte grupe ili za odabir projekata. Ova značajka je MVC, a slijedit će je mogućnost iscrtajte prosječnu pokrivenost tijekom vremena.
Ovo izdanje uvodi podršku za nekoliko novih jezika za fuzz testiranje s ciljem potpune pokrivenosti.
Sada možete procijeniti sve mogućnosti testiranja fuzzinga u svojim Java, Rust i Swift aplikacijama i pronaći pogreške i ranjivosti koje drugi skeneri i metode testiranja mogu propustiti.
Stranica Okruženja prikazuje ukupno stanje vaših okruženja. U ovom smo izdanju poboljšali ovu stranicu dodavanjem prikaza upozorenja. Aktivirana upozorenja zajedno sa statusom vaših okruženja pomoći će vam da brzo poduzmete radnje da ispravite situacije koje se pojave.
Korištenjem ugniježđenih cjevovoda, sada je moguće pokrenuti nove cjevovode unutar cjevovoda-dijeta. Dodatna razina dubine može biti korisna ako vam je potrebna fleksibilnost za generiranje promjenjivog broja cjevovoda.
Ranije, pri korištenju ugniježđenih cjevovoda, svaki podređeni cjevovod zahtijevao je da se posao okidača ručno definira u nadređenom cjevovodu. Sada možete stvoriti ugniježđene cjevovode koji će dinamički pokrenuti bilo koji broj novih ugniježđenih cjevovoda. Na primjer, ako imate monorepozitorij, možete dinamički generirati prvi podcjevovod, koji će sam stvoriti potreban broj novih cjevovoda na temelju promjena u grani.
Prethodno kretanje između nadređenih i ugniježđenih cjevovoda nije bilo baš zgodno - bilo vam je potrebno mnogo klikova da dođete do željenog cjevovoda. Također nije bilo lako dokučiti koji je posao započeo naftovod. Sada će biti puno lakše vidjeti veze između nadređenih i ugniježđenih cjevovoda.
Ako ste koristili matrica zadataka, možda ste primijetili da je bilo teško odrediti koja je varijabla matrice korištena za određeni posao, jer su nazivi poslova izgledali kao matrix 1/4. U izdanju 13.4 vidjet ćete relevantne vrijednosti varijable koje su korištene u tom poslu umjesto generičkog naziva posla. Na primjer, ako je vaš cilj otklanjanje pogrešaka u x86 arhitekturi, tada bi posao bio pozvan matrix: debug x86.
GitLab korisnici sada će moći povezati svoje GitLab račune sa svojim Atlassian Cloud računom. To će vam omogućiti da se prijavite na GitLab sa svojim vjerodajnicama za Atlassian, a također će postaviti temelje za buduća poboljšanja integracije. Gitlab s Jirom te s ostalim proizvodima iz linije Atlassian.
Organizacije usmjerene na usklađenost trebaju način da revizorima pokažu holistički pogled na komponente povezane s bilo kojom promjenom u proizvodnji. U GitLabu to znači prikupljanje svega na jednom mjestu: zahtjeve za spajanje, ulaznice, cjevovode, sigurnosna skeniranja i druge podatke o predaji. Do sada ste ih ili morali ručno prikupljati u GitLabu ili konfigurirati svoje alate za prikupljanje informacija, što nije bilo baš učinkovito.
Sada možete programski prikupljati i izvoziti te podatke kako biste ispunili zahtjeve revizije ili izvršili druge analize. Da biste izvezli popis svih obveza spajanja za trenutnu grupu, morate otići na Nadzorne ploče usklađenosti i kliknite na gumb Popis svih obveza spajanja. Rezultirajuća datoteka će sadržavati sva izdanja zahtjeva za spajanje, njihovog autora, ID pridruženog zahtjeva za spajanje, grupu, projekt, potvrđivače i druge informacije.
Upravljanje pristupom prostoru imena GitLab važan je dio napora za usklađivanje. Od načela najmanje privilegije do onemogućavanja vremenskog pristupa, može postojati nekoliko zahtjeva povezanih s osobnim pristupnim tokenima u GitLabu. Kako bismo olakšali održavanje i upravljanje svim ovim korisničkim vjerodajnicama unutar vašeg imenskog prostora, omogućili smo popis svih osobnih pristupnih tokena i opcionalno odbij pristup putem API-ja.
Ova poboljšanja GitLab API-ja omogućuju korisnicima da ispisuju i opozivaju svoje osobne pristupne tokene, a administratorima da popisuju i opozivaju tokene svojih korisnika. Administratorima će sada biti lakše vidjeti tko ima pristup njihovom prostoru imena, donositi odluke o pristupu na temelju korisničkih podataka i opozivati osobne pristupne tokene koji su možda ugroženi ili koji su izvan tvrtkinih pravila upravljanja pristupom.
Kada pregledavate promjene koda, rasprave i predaje zahtjeva za spajanje, često je poželjno izvršiti lokalnu provjeru grane radi dubljeg pregleda. Međutim, pronalaženje naziva niti postaje sve teže kako se više sadržaja dodaje opisu zahtjeva za spajanje i morate se pomicati niže po stranici.
Dodali smo naziv grane na bočnu traku zahtjeva za spajanje, čineći ga dostupnim u bilo kojem trenutku i eliminirajući potrebu za listanjem kroz cijelu stranicu. Baš kao i veza na zahtjev za spajanje, odjeljak izvorne grane sadrži praktičan gumb "kopiraj".
Hvala Ethan Reesor za vaš ogroman doprinos razvoju ove značajke!
Zahtjevi za spajanje koji dodaju promjene višestrukim datotekama ponekad skupljaju razlike velikih datoteka radi poboljšanja performansi prikazivanja. Kada se to dogodi, moguće je slučajno preskočiti datoteku tijekom pregleda, posebno u zahtjevima za spajanje s velikim brojem datoteka. Počevši od verzije 13.4, zahtjevi za spajanje označit će razlike koje sadrže presavijene datoteke, tako da nećete propustiti te datoteke tijekom pregleda koda. Radi još veće jasnoće, planiramo dodati isticanje ovim datotekama u budućem izdanju. Pratite novosti o ulaznica za gitlab#16047.
U odjeljku razlika zahtjeva za spajanje, velike datoteke su sažete radi poboljšanja performansi. Međutim, prilikom pregleda koda, neke datoteke mogu biti propuštene kada se pregledavač pomiče kroz popis datoteka, jer su sve velike datoteke sažete.
Dodali smo vidljivo upozorenje na vrhu stranice razlike zahtjeva za spajanje kako bismo obavijestili korisnike da u ovom odjeljku postoji spojena datoteka. Na taj način nećete propustiti promjene zahtjeva za spajanje tijekom pregleda.
Prethodno, kada je primarni čvor Gitaly klastera bio izvan mreže, repozitoriji na tom čvoru bili su označeni kao samo za čitanje. To je spriječilo gubitak podataka u situacijama kada je došlo do promjena na čvoru koje još nisu replicirane. Kada se čvor vratio na mrežu, GitLab nije bio automatski vraćen, a administratori su morali ručno pokrenuti proces sinkronizacije ili prihvatiti gubitak podataka. Ostale situacije, kao što je neuspjeh replikacijskog posla na sekundarnom čvoru, također mogu rezultirati ustajalim spremištima ili spremištima samo za čitanje. U ovom slučaju, spremište je ostalo ustajalo sve dok se ne dogodi sljedeća operacija pisanja, koja bi pokrenula posao replikacije.
Da biste riješili ovaj problem Praefect sada raspoređuje posao replikacije kada otkrije zastarjelo spremište na jednom čvoru i najnoviju verziju spremišta na drugom. Ovaj posao replikacije automatski održava spremište ažurnim, eliminirajući potrebu za ručnim vraćanjem podataka. Automatski oporavak također osigurava da se sekundarni čvorovi brzo ažuriraju ako posao replikacije ne uspije, umjesto da se čeka sljedeća operacija pisanja. Budući da mnogi Gilaly klasteri pohranjuju veliki broj repozitorija, ovo značajno smanjuje vrijeme koje administratori i inženjeri pouzdanosti troše na oporavak podataka nakon pogreške.
Osim toga, automatski popravak pokreće replikaciju repozitorija na svakom novom Gitaly čvoru dodanom u klaster, eliminirajući ručni rad prilikom dodavanja novih čvorova.
Učinkovita komunikacija u GitLabu temelji se na listama obaveza. Ako ste spomenuti u komentaru, ključno je moći prijeći na zadatak i započeti nešto raditi ili to označiti kao dovršeno. Također je važno moći sami sebi dodijeliti zadatak kada trebate raditi na nečemu ili se na to vratiti kasnije.
Ranije niste mogli dodavati zadatke ili ih označavati kao dovršene kada ste radili s dizajnom. To je ozbiljno narušilo učinkovitost komunikacije između proizvodnih timova, budući da su obveze ključni element tijeka rada GitLaba.
U izdanju 13.4, dizajni sustižu komentare ulaznica u korištenju zadataka, što rad s njima čini dosljednijim i učinkovitijim.
Poboljšali smo vodič za rješavanje problema za GitLab CI/CD s više informacija o uobičajenim problemima na koje možete naići. Nadamo se da će poboljšana dokumentacija biti vrijedan resurs koji će vam pomoći da brzo i jednostavno pokrenete GitLab CI/CD.
Prethodno su zahtjevi za spajanje mogli slučajno ispasti iz reda čekanja za spajanje zbog kasnih komentara. Ako je zahtjev za spajanje već bio u redu čekanja i netko mu je dodao komentar koji je stvorio novu neriješenu raspravu, zahtjev za spajanje smatrao se nepodobnim za spajanje i ispao bi iz reda čekanja. Sada, nakon što je zahtjev za spajanje dodan u red čekanja za spajanje, novi komentari se mogu dodavati bez straha od ometanja procesa spajanja.
Programeri bi trebali moći vidjeti vrijednost pokrivenosti koda nakon što je cjevovod dovršen - čak i u složenim scenarijima kao što je pokretanje cjevovoda s višestrukim poslovima koje je potrebno raščlaniti da bi se izračunala vrijednost pokrivenosti. Prethodno je widget za zahtjev za spajanje prikazivao samo prosjek ovih vrijednosti, što je značilo da morate otići do stranice s poslom i natrag do zahtjeva za spajanjem da biste dobili međuvrijednosti pokrivenosti. Kako bismo vam uštedjeli vrijeme i ove dodatne korake, učinili smo da widget prikazuje prosječnu vrijednost pokrivenosti, njezine promjene između ciljne i izvorne grane i opis alata koji prikazuje vrijednost pokrivenosti za svaki posao na temelju koje je izračunat prosjek.
Registar paketa GitLab je mjesto za pohranu i distribuciju paketa u različitim formatima. Kada imate mnogo paketa u svom projektu ili grupi, morate brzo identificirati neiskorištene pakete i ukloniti ih kako biste spriječili druge da ih preuzmu. Možete ukloniti pakete iz svog registra putem API paketa ili preko korisničkog sučelja registra paketa. Međutim, do sada niste mogli ukloniti pakete kada gledate grupu kroz korisničko sučelje. Kao rezultat toga, morali ste ukloniti nepotrebne pakete po projektu, što je bilo neučinkovito.
Sada možete ukloniti pakete kada pregledavate registar paketa grupe. Jednostavno idite na stranicu registra paketa grupe, filtrirajte pakete prema nazivu i uklonite one koji vam ne trebaju.
Možete koristiti Conan repozitorij u GitLabu za objavljivanje i distribuciju C/C++ ovisnosti. Međutim, prije su se paketi mogli skalirati samo na razinu instance, budući da je ime paketa Conan moglo imati najviše 51 znak. Ako želite objaviti paket iz podgrupe, npr gitlab-org/ci-cd/package-stage/feature-testing/conan, bilo je gotovo nemoguće učiniti.
Sada možete smanjiti Conan pakete na razinu projekta, što olakšava objavljivanje i distribuciju ovisnosti o vašim projektima.
Uzbuđeni smo što možemo na naš popis dodati skeniranje ovisnosti za C, C++, C# i .Net projekte koda koji koriste NuGet 4.9+ ili Conan upravitelje paketa podržani jezici i okviri. Sada možete omogućiti skeniranje ovisnosti kao dio sigurnosne faze kako biste provjerili postoje li poznate ranjivosti u ovisnostima dodanim putem upravitelja paketa. Pronađene ranjivosti bit će prikazane u vašem zahtjevu za spajanje zajedno s njihovom razinom ozbiljnosti, tako da prije izvršenja spajanja znate kakve rizike nosi nova ovisnost. Također možete konfigurirati svoj projekt prema potrebi potvrda zahtjeva za spajanje za ovisnosti s ranjivostima s kritičnim (Critical), visokim (High) ili nepoznatim (Unknown) razinama ozbiljnosti.
Prethodno, prilikom postavljanja postavki zahtjeva za spajanje Spojite kada cjevovod završi (Spoji kada cjevovod uspije, MWPS) nije poslana obavijest e-poštom. Morali ste ručno provjeriti status ili pričekati obavijest o spajanju. S ovim izdanjem sa zadovoljstvom predstavljamo doprinose korisnika @ravishankar2kool, koji je riješio ovaj problem dodavanjem automatskih obavijesti svima koji su pretplaćeni na zahtjev za spajanje kada recenzent promijeni postavku spajanja na MWPS.
Ne pokreće svaki problem koji se odmah pojavi upozorenja: korisnici prijavljuju prekide rada, a članovi tima istražuju probleme s performansama. Incidenti su sada vrsta karte, tako da ih vaši timovi mogu brzo kreirati kao dio svog uobičajenog tijeka rada. Klik Novi zadatak s bilo kojeg mjesta u GitLabu i na terenu Vrsta Odaberi Incident.
Poboljšali smo GitLab upozorenja dodavanjem nove vrste spominjanja posebno za njih u GitLab Markdown, što olakšava dijeljenje i spominjanje upozorenja. Koristiti ^alert#1234spomenuti upozorenje u bilo kojem Markdown polju: u incidentima, prijavama ili zahtjevima za spajanje. To će vam također pomoći da identificirate poslove koji su stvoreni iz upozorenja, a ne iz ulaznica ili zahtjeva za spajanje.
Opis upozorenja sadrži informacije ključne za rješavanje problema i oporavak, a te informacije trebaju biti lako dostupne kako ne biste morali mijenjati alate ili kartice dok radite na rješavanju incidenta. Incidenti stvoreni iz upozorenja prikazuju puni opis upozorenja na kartici Detalji upozorenja.
GitLab, kao jedna aplikacija, ima jedinstvenu sposobnost brzog otkrivanja sadržaja u cijelom tijeku rada DevOpsa. U GitLabu 13.4, napredno pretraživanje vraća rezultate 75% brže ograničeno na određene imenske prostore i projekte, kao na GitLab.com.
Postojala je mogućnost odgode brisanja projekta uveden 12.6. Međutim, ranije nije bilo moguće na jednom mjestu vidjeti sve projekte koji čekaju brisanje. Administratori GitLab korisničkih instanci sada mogu vidjeti sve projekte brisanja na čekanju na jednom mjestu, zajedno s gumbima za jednostavno vraćanje tih projekata.
Ova mogućnost daje administratorima veću kontrolu nad brisanjem projekta prikupljanjem svih relevantnih informacija na jednom mjestu i pružanjem mogućnosti poništavanja neželjenih radnji brisanja.
Prethodno su se grupna push pravila mogla konfigurirati samo posjetom svakoj grupi pojedinačno putem GitLab korisničkog sučelja i primjenom tih pravila. Sada možete upravljati ovim pravilima putem API-ja kako biste podržali svoje prilagođene alate i GitLab automatizaciju.
Pohranjivanje vjerodajnica Pruža administratorima informacije koje su im potrebne za upravljanje korisničkim vjerodajnicama za njihovu GitLab instancu. Budući da se organizacije usmjerene na usklađenost razlikuju u strogosti svojih politika upravljanja vjerodajnicama, dodali smo gumb koji omogućuje administratorima opcionalno opozivanje korisničkog osobnog pristupnog tokena (PAT). Administratori sada mogu jednostavno opozvati potencijalno ugrožene PAT-ove. Ova je značajka korisna za organizacije koje žele fleksibilnije mogućnosti usklađenosti kako bi smanjile smetnje za svoje korisnike.
U GitLabu 13.4 predstavljamo novi način za prilagodbu uređivača statičkih stranica. Iako konfiguracijska datoteka ne sprema niti prima nikakve postavke u ovom izdanju, mi postavljamo temelje za buduću prilagodbu ponašanja uređivača. U budućim izdanjima dodat ćemo u datoteku .gitlab/static-site-editor.yml parametri za ugradnju adresu baznog mjesta, na kojoj slike učitane u editor su pohranjene, nadjačavajući postavke Markdown sintakse i druge postavke uređivača.
Prednji sadržaj je fleksibilan i prikladan način za definiranje varijabli stranice u podatkovnim datotekama za obradu pomoću generatora statičkih stranica. Obično se koristi za postavljanje naslova stranice, predloška izgleda ili autora, ali se može koristiti za prosljeđivanje bilo koje vrste metapodataka generatoru prilikom prikazivanja stranice u HTML-u. Uključen na samom vrhu svake podatkovne datoteke, uvodni dio obično je formatiran kao YAML ili JSON i zahtijeva dosljednu i preciznu sintaksu. Korisnici koji nisu upoznati s određenim sintaksnim pravilima mogu nenamjerno unijeti nevažeću oznaku, što zauzvrat može uzrokovati probleme s formatiranjem ili čak pogreške u izradi.
WYSIWYG način uređivanja statičnog uređivača web-mjesta već uklanja uvod iz uređivača kako bi spriječio ove pogreške oblikovanja. Međutim, to vas sprječava da promijenite vrijednosti pohranjene u ovom dijelu bez povratka na uređivanje u izvornom načinu. U GitLabu 13.4 možete pristupiti bilo kojem polju i urediti njegovu vrijednost u poznatom sučelju temeljenom na obrascima. Kada se pritisne tipka postavke (Postavke) otvorit će se ploča koja prikazuje polje obrasca za svaki ključ definiran na početku. Polja su popunjena trenutnom vrijednošću, a uređivanje bilo kojeg od njih jednostavno je poput unosa u web obrazac. Uređivanjem uvoda na ovaj način izbjegava se složena sintaksa i daje vam potpunu kontrolu nad sadržajem dok se osigurava dosljedan format konačnog rezultata.
Za Jira korisnike na GitLabu: GitLab aplikacija za Jira и DVCS konektor omogućuju vam prikaz informacija o GitLab obvezama i zahtjevima za spajanje izravno u Jiri. U kombinaciji s našom ugrađenom Jira integracijom, možete se lako kretati između dvije aplikacije dok radite.
Ove su značajke ranije bile dostupne samo u našem Premium planu, ali sada su dostupne svim korisnicima!
Gitaly klaster vam omogućuje repliciranje Git repozitorija na više "toplih" Gitaly čvorova. Ovo povećava toleranciju na greške eliminirajući pojedinačne točke kvara. Transakcijske operacije, uveden u GitLab 13.3, uzrokuju emitiranje promjena na sve Gitaly čvorove u klasteru, ali samo Gitaly čvorovi koji glasuju u dogovoru s primarnim čvorom spremaju promjene na disk. Ako se svi čvorovi replike ne slažu, samo će jedna kopija promjene biti pohranjena na disku, stvarajući jednu točku kvara dok se ne završi asinkrona replikacija.
Većinsko glasovanje poboljšava toleranciju grešaka zahtijevajući pristanak većine čvorova (ne svih) prije spremanja promjena na disk. Ako je ova značajka prebacivanja omogućena, pisanje bi trebalo uspjeti na više čvorova. Čvorovi koji se ne slažu automatski se sinkroniziraju korištenjem asinkrone replikacije iz onih čvorova koji su formirali kvorum.
Projekti u kojima ljudi pišu konfiguracije u JSON-u ili YAML-u često su skloni problemima jer je lako napraviti tipfeler i nešto pokvariti. Moguće je napisati alate za inspekciju za otkrivanje ovih problema u CI cjevovodu, ali korištenje JSON datoteke sheme može biti korisno za pružanje dokumentacije i savjeta.
Sudionici projekta mogu u svom repozitoriju definirati put do prilagođene sheme u datoteci .gitlab/.gitlab-webide.yml, koji specificira shemu i put do datoteka koje treba provjeriti. Kada učitate određenu datoteku u Web IDE, vidjet ćete dodatne povratne informacije i provjeru valjanosti koje će vam pomoći da stvorite datoteku.
Ako koristite pokretne trake s usmjerenim acikličkim grafom (Usmjereni aciklički graf (DAG)), možda ćete otkriti da postoji ograničenje od 10 poslova koje posao može navesti u needs:, prestrogo. U 13.4, zadano ograničenje povećano je s 10 na 50 kako bi se omogućile složenije mreže odnosa između poslova u vašim cjevovodima.
Ako ste administrator prilagođene GitLab instance, možete podići ovo ograničenje još više postavljanjem značajke prebacivanja, iako ne nudimo službenu podršku za to.
U nekim slučajevima, propušteni posao u cjevovodu mogao bi se netočno smatrati uspješnim za ovisnosti navedene u needs, što je uzrokovalo pokretanje naknadnih poslova, što se nije smjelo dogoditi. Ovo ponašanje je popravljeno u verziji 13.4 i needs sada ispravno obrađuje slučajeve propuštenih zadataka.
GitLab sada automatski zaključava posljednji uspješni posao i artefakt cjevovoda na bilo kojoj aktivnoj grani, zahtjevu za spajanje ili oznaci kako bi spriječio brisanje nakon isteka. Postaje lakše postaviti agresivnija pravila isteka za čišćenje starih artefakata. To pomaže smanjiti potrošnju prostora na disku i osigurava da uvijek imate kopiju najnovijeg artefakta iz cjevovoda.
Optimiziranje vašeg CI/CD cjevovoda može poboljšati brzinu isporuke i uštedjeti novac. Poboljšali smo našu dokumentaciju kako bismo uključili brzi vodič za izvlačenje maksimuma iz optimiziranja vaših cjevovoda.
Izvješće o ispitivanju jedinice je jednostavan način da vidite rezultate svih testova u cjevovodu. Međutim, s velikim brojem testova, pronalaženje neuspješnih testova može potrajati dugo. Ostali problemi koji mogu otežati korištenje izvješća uključuju poteškoće pri pomicanju kroz duge izlaze praćenja i zaokruživanje vremena na nulu za testove koji se izvode za manje od 1 sekunde. Sada, prema zadanim postavkama, prilikom razvrstavanja izvješća o testiranju, neuspjele testove prvo stavlja na početak izvješća, a zatim razvrstava testove po trajanju. To olakšava pronalaženje kvarova i dugih testova. Osim toga, trajanje testa sada se prikazuje u milisekundama ili sekundama, što ih čini puno bržima za čitanje, a također su riješeni prethodni problemi s pomicanjem.
Sada postoje ograničenja na veličinu datoteka paketa koje se mogu prenijeti u registar paketa GitLab. Ograničenja su dodana za optimiziranje performansi registra paketa i sprječavanje zlouporabe. Ograničenja se razlikuju ovisno o formatu paketa. Za GitLab.com maksimalne veličine datoteka su:
Conan: 250 MB
Maven: 3 GB
NPM: 300 MB
NuGet: 250 MB
PyPI: 3 GB
Za prilagođene GitLab instance, zadane su vrijednosti iste. Međutim, administrator može ažurirati ograničenja pomoću Tračnice konzole.
Možete koristiti GitLab PyPI repozitorij za stvaranje, objavljivanje i dijeljenje Python paketa zajedno s izvornim kodom i CI/CD cjevovodima. Međutim, prije se niste mogli autentificirati u repozitoriju koristeći unaprijed definiranu varijablu okoline CI_JOB_TOKEN. Kao rezultat toga, morali ste koristiti svoje osobne vjerodajnice za ažuriranje PyPI repozitorija ili ste možda odlučili da uopće ne koristite repozitorij.
Sada je lakše koristiti GitLab CI/CD za objavljivanje i instaliranje PyPI paketa pomoću unaprijed definirane varijable okruženja CI_JOB_TOKEN.
DAST skeniranju na zahtjev koje je bilo predstavljen u prethodnom izdanju, dodani su DAST profili skenera. Oni proširuju konfiguracijske mogućnosti ovih skeniranja, omogućujući vam da brzo stvorite više profila za pokrivanje više vrsta skeniranja. U 13.4, profil alata za indeksiranje izvorno uključuje postavku vremenskog ograničenja indeksiranja koja postavlja koliko dugo DAST alat za indeksiranje treba raditi dok pokušava otkriti sve stranice indeksiranog web mjesta. Profil također uključuje postavku vremenskog ograničenja ciljne web-lokacije za postavljanje koliko dugo alat za indeksiranje treba čekati da web-lokacija postane dostupna prije nego što prekine indeksiranje ako web-mjesto ne odgovori statusnim kodom 200 ili 300. Kako budemo nastavljali poboljšavati, ova značajka bit će dodan u profil skenera u budućim izdanjima; dodat će se dodatni konfiguracijski parametri.
Ako koristite GitLab stranice i želite bolje upravljati promjenama URL-a, možda ste primijetili da upravljanje preusmjeravanjima na vašoj stranici GitLab stranica nije bilo moguće. GitLab vam sada omogućuje konfiguriranje pravila za preusmjeravanje jednog URL-a na drugi za vaše web-mjesto Pages dodavanjem konfiguracijske datoteke u repozitorij. Ova značajka je omogućena zahvaljujući doprinosu Kevina Barnetta (@PapaDrFreud), naš Eric Eastwood (@MadLittleMods) i GitLab timovi. Hvala svima na doprinosu.
Pristup prethodnim verzijama stanja Terraform neophodan je i za usklađenost i za otklanjanje pogrešaka ako je potrebno. Podrška za verziju Terraform stanja kojim upravlja GitLab dostupna je počevši od GitLaba 13.4. Određivanje verzija je automatski omogućeno za nove Terraform datoteke stanja. Postojeće datoteke stanja Terraform bit će automatski migrirano u repozitorij s verzijama u kasnijem izdanju.
Prilikom obrade incidenata morate moći jednostavno odrediti koliko je dugo upozorenje bilo otvoreno i koliko je puta događaj pokrenut. Ti su detalji često ključni u određivanju utjecaja na kupca i onoga što bi vaš tim trebao prvo riješiti. Na novoj ploči s pojedinostima o incidentu prikazujemo vrijeme početka upozorenja, broj događaja i poveznicu na izvorno upozorenje. Ove su informacije dostupne za incidente koji su generirani iz upozorenja.
Dimenzija ozbiljnosti incidenta omogućuje odgovornim osobama i dionicima da odrede učinak ispada, kao i metodu i hitnost odgovora. Dok vaš tim dijeli rezultate tijekom rješavanja incidenta i oporavka, oni mogu promijeniti ovu postavku. Sada možete urediti ozbiljnost incidenta na desnoj bočnoj traci stranice s pojedinostima o incidentu, a ozbiljnost se prikazuje na popisu incidenata.
Ovo poboljšanje uređivača mrežnih sigurnosnih pravila za spremnik omogućuje korisnicima jednostavno stvaranje, uređivanje i brisanje svojih pravila izravno iz GitLab korisničkog sučelja. Značajke uređivača uključuju .yaml za iskusne korisnike i uređivač pravila s intuitivnim sučeljem za one koji se tek upoznaju s mrežnim pravilima. Nove mogućnosti upravljanja pravilima možete pronaći u odjeljku Sigurnost i usklađenost > Upravljanje prijetnjama > Pravila (Sigurnost i usklađenost > Upravljanje prijetnjama > Pravila).
I GitLab i GitLab Runner sada podržavaju Azure blob pohrana, što olakšava pokretanje GitLab usluga na Azureu.
GitLab instance podržavaju Azure za sve vrste pohrana objekata, uključujući LFS datoteke, CI artefakte i sigurnosne kopije. Za postavljanje Azure Blob pohrane slijedite upute za instalaciju Omnibus ili Shema kormila.
Kao odgovor na rastuću potražnju za podrškom za pokretanje GitLaba na 64-bitnoj ARM arhitekturi, sa zadovoljstvom najavljujemo dostupnost službenog paketa ARM64 Ubuntu 20.04 Omnibus. Veliko hvala Zitai Chen i Guillaumeu Gardetu na ogromnom doprinosu koji su dali - njihovi zahtjevi za spajanje odigrali su ključnu ulogu u ovome!
Za preuzimanje i instaliranje paketa za Ubuntu 20.04 idite na našu stranica za instalaciju i odaberite Ubuntu.
Pametne kartice, kao što su Common Access Cards (CAC), sada se mogu koristiti za autentifikaciju na GitLab instanci postavljenoj putem Helm charta. Pametne kartice se autentificiraju prema lokalnoj bazi podataka pomoću X.509 certifikata. Time je podrška za pametne kartice s Helm grafikonom sada u skladu s podrškom za pametne kartice dostupne u implementacijama Omnibusa.