ProHoster > Блог > Administracija > # GitLab 13.4 objavljen sa HashiCorp repozitorijumom za CI varijable i Kubernetes agentom
# GitLab 13.4 objavljen sa HashiCorp repozitorijumom za CI varijable i Kubernetes agentom
Izdanje 13.4 je objavljeno s HashiCorp pohranom za CI varijable, Kubernetes agentom i sigurnosnim centrom, kao i promjenjivim funkcijama u Starteru
U GitLabu uvijek razmišljamo o tome kako možemo pomoći korisnicima da smanje rizik, poboljšaju efikasnost i poboljšaju brzinu isporuke na vašoj omiljenoj platformi. Ovog mjeseca smo dodali puno korisnih novih funkcija koje proširuju sigurnosne mogućnosti, smanjuju broj ranjivosti, povećavaju efikasnost, pojednostavljuju rad sa GitLabom i pomažu vašem timu da još brže isporuči funkcije. Nadamo se da će vam glavne karakteristike izdanja biti korisne, kao i 53 druge nove funkcije, dodano u ovom izdanju.
Drugi način za smanjenje rizika je korištenje novog GitLab Kubernetes Agent. Operativni timovi mogu implementirati Kubernetes klastere iz GitLaba bez potrebe da izlažu svoj klaster cijelom internetu. Također uvodimo podršku za automatsku kontrolu verzija za nove Terraform datoteke stanja s GitLab upravlja Terraform stanjem za podršku usklađenosti i jednostavnosti otklanjanja grešaka. Konačno, postala je sigurnosna kontrolna tabla GitLab sigurnosni centar sa izvještajima o ranjivosti i sigurnosnim postavkama.
Fabio je dao značajan doprinos doprinos в prikaz pokrivenosti koda u razlikama zahtjeva za spajanjem - funkcija koja se dugo čekala u GitLab zajednici. Ovo je zaista važan doprinos sa netrivijalnim promenama koje su zahtevale stalnu saradnju sa članovima GitLab tima i uticale 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 na CI poslove koristeći GitLab runner zadataka (GitLab runner). Sada se širimo autentifikaciju koristeći JWT, dodajući novu sintaksu secrets da fajl .gitlab-ci.yml. Ovo će olakšati postavljanje i korištenje HashiCorp spremišta sa GitLabom.
GitLab-ova integracija sa Kubernetes-om dugo je omogućavala implementaciju u Kubernetes klastere bez potrebe za ručnom konfiguracijom. Mnogim korisnicima se dopala jednostavnost korištenja ovog paketa, dok su drugi naišli na poteškoće. Za trenutnu integraciju, vaš klaster mora biti dostupan sa Interneta da bi mu GitLab mogao pristupiti. Za mnoge organizacije to nije moguće jer ograničavaju pristup klasterima iz sigurnosnih, usklađenih ili regulatornih razloga. Da bi zaobišli ova ograničenja, korisnici su morali da naprave svoje alate na vrhu GitLaba, inače ne bi mogli da koriste ovu funkciju.
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 tako što traž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 konfigurisanje i upravljanje implementacijama putem koda. Neke postojeće funkcije Kubernetes integracije, kao što su ploče za implementaciju i GitLab upravljane aplikacije, još nisu podržane. Pretpostavljamoda će ove mogućnosti biti dodane agentu u budućim izdanjima, kao i nove integracije fokusirane na sigurnost i usklađenost.
Ranije je GitLabov sistem dozvola otežavao pravilnu podjelu odgovornosti unutar vašeg tima između onih koji su odgovorni za razvoj i onih koji su odgovorni za implementaciju. Sa izdanjem GitLaba 13.4, možete dati dozvolu za odobravanje zahtjeva za spajanje za implementaciju, kao i za stvarno postavljanje koda ljudima koji ne pišu kod, a da im ne date prava pristupa za održavanje (u ruskoj lokalizaciji GitLaba „održavač“ ).
Ranije je upravljanje ranjivostima na nivou instance bilo ograničeno i u funkcionalnosti i u fleksibilnosti. Interfejs je bio jedna stranica koja kombinuje detalje ranjivosti, metričke grafikone i postavke. Nema puno prostora za razvoj ovih funkcija ili korištenje drugih sigurnosnih funkcija.
Napravili smo fundamentalne promjene u načinu na koji upravljamo sigurnošću i transparentnošću u GitLabu. Sigurnosni panel instance je pretvoren u cijeli sigurnosni centar. Najveća promjena je uvođenje nove strukture menija: umjesto jedne stranice, sada vidite sigurnosnu kontrolnu tablu, izvještaj o ranjivosti i odjeljak postavki. Iako se funkcionalnost nije promijenila, razbijanje na dijelove omogućit će poboljšanja ovog odjeljka koja bi inače bila teška. Ovo takođe postavlja teren za dodavanje drugih mogućnosti vezanih za bezbednost u budućnosti.
Namenski odjeljak izvještaja o ranjivosti sada ima više prostora za prikaz važnih detalja. Evo ranjivosti koje se trenutno nalaze na listi ranjivosti projekta. Premještanje widgeta sa metrikom ranjivosti u poseban odjeljak stvara praktičan sigurnosni kontrolni panel. Sada je to platno za buduće vizualizacije – ne samo za upravljanje ranjivostima, već i za sve metrike vezane za sigurnost. Konačno, odvojeno područje postavki stvara zajednički prostor za sve sigurnosne postavke na nivou instance, a ne samo za upravljanje ranjivostima.
Ranije ove godine GitLab se obavezao premjestiti 18 karakteristika u open source. U ovom izdanju, završili smo migraciju promjenjivih funkcija na Starter plan i nastavit ćemo ih migrirati na Core sa Git Lab 13.5. Uzbuđeni smo što ovu funkciju donosimo većem broju korisnika i želimo čuti kako je koristite.
Ponekad kada se krećete po GitLabu želite da idete direktno na određeni projekat, a ne na stranicu rezultata pretrage.
Koristeći globalnu traku za pretraživanje, možete brzo doći do najnovijih tiketa, grupa, projekata, postavki i tema pomoći. Možete čak koristiti i interventni taster /da pomerite kursor na traku za pretragu kako biste se još efikasnije kretali po GitLabu!
Kada pregledate zahtjev za spajanje, može biti teško utvrditi da li je promijenjeni kod pokriven testovima jedinica. Umjesto toga, recenzenti se mogu osloniti na ukupnu pokrivenost i tražiti da se ona poveća prije nego što odobre zahtjev za spajanje. Ovo može dovesti do slučajnog pristupa pisanju testova, koji zapravo neće poboljšati kvalitet koda ili pokrivenost testom.
Sada, kada gledate diff zahtjeva za spajanjem, vidjet ćete vizualni prikaz pokrivenosti koda. Nove oznake će vam omogućiti da brzo shvatite da li je promijenjeni kod pokriven jediničnim testom, što će pomoći da se ubrza pregled koda i vrijeme spajanja i implementacije novog koda.
Od izdavanja GitLab 12.5 koristim paneli za okruženje možete pratiti stanje okruženja, ali ne više od sedam okruženja u tri projekta. Poboljšali smo ovaj panel u izdanju 13.4 tako što smo ga podijelili na stranice kako bismo vam pomogli da održavate i upravljate svojim okruženjima u velikom obimu. Sada možete vidjeti više okruženja u više projekata.
API fuzzing testiranje je odličan način da pronađete greške i ranjivosti u vašim web aplikacijama i API-jima koje bi drugi skeneri i metode testiranja mogli propustiti.
API fuzzing testiranje u GitLabu vam omogućava da pružite OpenAPI v2 specifikacija ili HAR fajl vašu aplikaciju, a zatim automatski generiše nasumične ulazne podatke dizajnirane za testiranje rubnih slučajeva i pronalaženje grešaka. Rezultati su odmah vidljivi unutar vašeg cjevovoda.
Ovo je naše prvo izdanje za API fuzz testiranje i voljeli bismo čuti što mislite. Imamo još na lageru za fuzz testiranje mnogo ideja, koju ćemo bazirati na izdavanju ove funkcije.
Ranije kreiranje grafikona na kontrolnoj tabli metrike u GitLabu nije bio lak zadatak. Nakon što ste kreirali metriku u YAML datoteci na kontrolnoj tabli, izvršili ste promjene u master, bez mogućnosti da potvrdite da novokreirani graf radi tačno onako kako vam je potrebno. Počevši od ovog izdanja, možete pregledati promjene dok kreirate graf, dobivajući ideju o rezultatu prije slanja promjena u YAML datoteku na kontrolnoj tabli.
Kada upravljate velikim brojem projekata u GitLabu, potreban vam je jedan izvor informacija o tome kako se pokrivenost koda mijenja tokom vremena u svim projektima. Ranije je prikazivanje ovih informacija zahtijevalo zamoran i dugotrajan ručni rad: morali ste preuzeti podatke o pokrivenosti koda iz svakog projekta i kombinirati ih u tabeli.
U izdanju 13.4 postalo je moguće lako i brzo sastaviti .csv fajl sa svim podacima o pokrivenosti koda za sve projekte grupe ili za izbor projekata. Ova funkcija je MVC, a pratit će je i mogućnost prosječna pokrivenost parcele tokom vremena.
Ovo izdanje uvodi podršku za nekoliko novih jezika za fuzz testiranje sa ciljem pune pokrivenosti.
Sada možete procijeniti pune mogućnosti fuzzing testiranja u vašim Java, Rust i Swift aplikacijama i pronaći greške i ranjivosti koje drugi skeneri i metode testiranja mogu propustiti.
Stranica Environments prikazuje ukupno stanje vaših okruženja. U ovom izdanju smo poboljšali ovu stranicu dodavanjem prikaza upozorenja. Aktivirana upozorenja zajedno sa statusom vašeg okruženja pomoći će vam da brzo preduzmete radnje da ispravite situacije koje se pojave.
Korištenjem ugniježđenih cjevovoda sada je moguće pokrenuti nove cjevovode unutar podređenih cjevovoda. Dodatni nivo dubine može biti koristan ako vam je potrebna fleksibilnost za generiranje promjenjivog broja cjevovoda.
Ranije, kada se koriste ugniježđeni cjevovodi, svaki podređeni cjevovod je zahtijevao da se posao okidača ručno definira u nadređenom cjevovodu. Sada možete kreirati 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 podvodovod, koji će sam kreirati potreban broj novih cjevovoda na osnovu promjena u grani.
Ranije, navigacija između nadređenog i ugniježđenog cjevovoda nije bila baš zgodna - trebalo vam je puno klikova da biste došli do željenog cjevovoda. Takođe nije bilo lako otkriti koji posao je započeo cevovod. Sada će biti mnogo lakše vidjeti veze između roditeljskog i ugniježđenog 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, budući da su nazivi poslova izgledali ovako 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 grešaka u arhitekturi x86, onda će posao biti pozvan matrix: debug x86.
Korisnici GitLaba sada će moći da povežu svoje GitLab naloge sa svojim Atlassian Cloud nalogom. Ovo će vam omogućiti da se prijavite na GitLab sa vašim Atlassian vjerodajnicama, a također će postaviti temelje za buduća poboljšanja integracije. Gitlab sa Jira i sa ostalim proizvodima iz Atlassian linije.
Organizacije koje su fokusirane na usklađenost trebaju način da pokažu revizorima holistički pogled na komponente povezane sa bilo kojom promjenom u proizvodnji. U GitLabu to znači prikupljanje svega na jednom mjestu: zahtjeve za spajanje, tikete, cjevovode, sigurnosna skeniranja i druge podatke za urezivanje. Do sada ste morali ili ručno da ih prikupljate u GitLab-u ili da konfigurišete svoje alate za prikupljanje informacija, što nije bilo baš efikasno.
Sada možete programski prikupljati i izvoziti ove podatke kako biste ispunili zahtjeve revizije ili izvršili druge analize. Da biste izvezli listu svih urezivanja spajanja za trenutnu grupu, trebate otići na Kontrolne ploče usklađenosti i kliknite na dugme Lista svih urezivanja spajanja. Rezultirajuća datoteka će sadržavati sva urezivanja zahtjeva za stapanjem, njihovog autora, ID pridruženog zahtjeva za stapanjem, grupu, projekat, potvrdnike i druge informacije.
Upravljanje pristupom GitLab imenskom prostoru je važan dio napora za usklađivanje. Od principa najmanje privilegija do onemogućavanja vremenski ograničenog pristupa, može postojati nekoliko zahtjeva povezanih s ličnim tokenima pristupa 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 tokena ličnog pristupa i opciono odbiti pristup preko API-ja.
Ova poboljšanja GitLab API-ja omogućavaju korisnicima da navedu i opozovu svoje lične tokene za pristup, a administratorima da navedu i opozovu tokene svojih korisnika. Administratorima će sada biti lakše da vide ko ima pristup njihovom imenskom prostoru, donose odluke o pristupu na osnovu korisničkih podataka i opozivaju lične tokene za pristup koji su možda kompromitovani ili koji ne spadaju u politiku upravljanja pristupom kompanije.
Prilikom pregleda promjena koda, diskusija i urezivanja zahtjeva za stapanjem, često je poželjno izvršiti lokalnu provjeru grane radi dubljeg pregleda. Međutim, pronalaženje imena niti postaje sve teže jer se više sadržaja dodaje u opis zahtjeva za spajanje i morate se pomicati dalje niz stranicu.
Dodali smo naziv grane na bočnu traku zahtjeva za spajanje, čineći ga dostupnim u bilo koje vrijeme i eliminirajući potrebu za pomicanjem kroz cijelu stranicu. Baš kao i veza sa zahtjevom za spajanje, odjeljak izvorne grane sadrži zgodno dugme "kopiraj".
Spasibo Ethan Reesor za vaš ogroman doprinos razvoju ove funkcije!
Zahtjevi za spajanje koji dodaju promjene u više datoteka ponekad skupljaju razlike velikih datoteka kako bi se poboljšale performanse renderiranja. Kada se to dogodi, moguće je slučajno preskočiti datoteku tokom pregleda, posebno u zahtjevima za spajanje s velikim brojem datoteka. Počevši od verzije 13.4, zahtjevi za spajanje će označiti razlike koje sadrže presavijene datoteke, tako da nećete propustiti ove datoteke tokom pregleda koda. Za još veću jasnoću, planiramo da dodamo isticanje ovih datoteka u budućem izdanju. Pratite nas za ažuriranja gitlab karta#16047.
U odjeljku razlike zahtjeva za spajanjem, velike datoteke se skupljaju radi poboljšanja performansi. Međutim, prilikom pregleda koda, neki fajlovi mogu biti propušteni kada recenzent skroluje kroz listu datoteka, pošto su svi veliki fajlovi skupljeni.
Dodali smo vidljivo upozorenje na vrhu stranice diff zahtjeva za spajanjem kako bismo obavijestili korisnike da postoji spojena datoteka u ovom odjeljku. Na ovaj način nećete propustiti nijednu promjenu zahtjeva za spajanje tokom pregleda.
Ranije, kada je primarni čvor Gitaly klastera otišao van mreže, spremišta na tom čvoru su bila označena kao samo za čitanje. Ovo je spriječilo gubitak podataka u situacijama kada je došlo do promjena na čvoru koji još nije bio repliciran. Kada se čvor vratio na mrežu, GitLab nije automatski vraćen i administratori su morali ručno pokrenuti proces sinhronizacije ili prihvatiti gubitak podataka. Druge situacije, kao što je neuspjeh posla replikacije na sekundarnom čvoru, također mogu rezultirati zastarjelim spremištima ili spremištima samo za čitanje. U ovom slučaju, spremište je ostalo zastarjelo dok se ne dogodi sljedeća operacija pisanja, koja bi pokrenula posao replikacije.
Za rješavanje ovog problema Praefect sada zakazuje 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žuriranim, 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 spremišta, ovo značajno smanjuje vrijeme koje administratori i inženjeri pouzdanosti troše na oporavak podataka nakon greške.
Osim toga, automatski popravak pokreće replikaciju spremišta na bilo koji novi Gitaly čvor dodan u klaster, eliminirajući ručni rad prilikom dodavanja novih čvorova.
Efikasna komunikacija u GitLabu zasnovana je na listama obaveza. Ako ste pomenuti u komentaru, ključno je da možete da pređete na zadatak i ili počnete da radite nešto ili da ga označite kao završeno. Takođe je važno da možete sebi dodeliti zadatak kada treba da radite na nečemu ili se kasnije vratite na to.
Ranije niste mogli dodavati zadatke ili ih označavati kao dovršene kada radite s dizajnom. Ovo je ozbiljno poremetilo efikasnost komunikacije između proizvodnih timova, budući da su obaveze kritični element GitLab toka posla.
U izdanju 13.4, dizajni sustižu komentare ulaznica u korišćenju zadataka, što rad s njima čini dosljednijim i efikasnijim.
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 i pokrenete GitLab CI/CD.
Ranije su zahtjevi za spajanje mogli slučajno ispasti iz reda za spajanje zbog kasnih komentara. Ako je zahtjev za spajanje već bio u redu i neko mu je dodao komentar koji je stvorio novu neriješenu diskusiju, zahtjev za spajanje se smatrao nepodobnim za spajanje i ispao bi iz reda. Sada, nakon što je zahtjev za spajanje dodat u red spajanja, novi komentari se mogu dodati bez straha od ometanja procesa spajanja.
Programeri bi trebali biti u mogućnosti vidjeti vrijednost pokrivenosti koda nakon što je cjevovod završen - čak i u složenim scenarijima kao što je pokretanje cjevovoda s više poslova koje je potrebno raščlaniti da bi se izračunala vrijednost pokrivenosti. Ranije je vidžet zahtjeva za spajanjem pokazivao samo prosjek ovih vrijednosti, što je značilo da ste morali ići na stranicu posla i nazad na zahtjev za spajanje da biste dobili srednje vrijednosti pokrivenosti. Da bismo vam uštedjeli vrijeme i ove dodatne korake, napravili smo widget da prikazuje prosječnu vrijednost pokrivenosti, njene promjene između ciljne i izvorne grane i opis alata koji prikazuje vrijednost pokrivenosti za svaki posao na osnovu kojeg je izračunat prosjek.
GitLab registar paketa je mjesto za pohranu i distribuciju paketa u različitim formatima. Kada imate puno paketa u svom projektu ili grupi, morate brzo identificirati neiskorištene pakete i ukloniti ih kako biste spriječili ljude da ih preuzmu. Možete ukloniti pakete iz vašeg registra putem API paketa ili preko korisničkog interfejsa 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 neefikasno.
Sada možete ukloniti pakete kada pregledavate registar paketa grupe. Jednostavno idite na stranicu registra paketa grupe, filtrirajte pakete po imenu i uklonite sve koji vam nisu potrebni.
Možete koristiti Conan repozitorij u GitLabu za objavljivanje i distribuciju C/C++ zavisnosti. Međutim, ranije su paketi mogli samo skalirati na nivo instance, jer je naziv Conan paketa mogao imati najviše 51 znak. Ako želite da objavite paket iz podgrupe, na primer gitlab-org/ci-cd/package-stage/feature-testing/conan, to je bilo gotovo nemoguće uraditi.
Sada možete smanjiti Conan pakete na nivo projekta, što olakšava objavljivanje i distribuciju zavisnosti vaših projekata.
Uzbuđeni smo što možemo na našu listu dodati skeniranja zavisnosti za C, C++, C# i .Net projekte koji koriste NuGet 4.9+ ili Conan menadžere paketa podržani jezici i okviri. Sada možete omogućiti skeniranje ovisnosti kao dio sigurnosne faze da provjerite poznate ranjivosti u ovisnostima koje se dodaju putem upravitelja paketa. Pronađene ranjivosti će biti prikazane u vašem zahtjevu za spajanje zajedno sa njihovim nivoom ozbiljnosti, tako da znate prije izvođenja spajanja koje rizike nosi nova ovisnost. Također možete konfigurirati svoj projekt tako da zahtijeva potvrda zahtjeva za spajanje za zavisnosti sa ranjivostima sa kritičnim (kritičnim), visokim (visokim) ili nepoznatim (nepoznatim) nivoima ozbiljnosti.
Ranije, prilikom postavljanja postavki zahtjeva za spajanje Spajanje kada se cjevovod završi (Merge When Pipeline Succeeds, MWPS) nije poslano obavještenje putem e-pošte. Morali ste ručno provjeriti status ili čekati obavijest o spajanju. Sa ovim izdanjem sa zadovoljstvom predstavljamo doprinose korisnika @ravishankar2kool, koji je riješio ovaj problem dodavanjem automatskih obavještenja svima koji su pretplaćeni na zahtjev za spajanje kada recenzent promijeni postavku spajanja u MWPS.
Ne izaziva svaki problem koji se pojavi odmah upozorenja: korisnici prijavljuju prekide, a članovi tima istražuju probleme s performansama. Incidenti su sada vrsta kazne, tako da ih vaši timovi mogu brzo kreirati kao dio svog normalnog toka posla. Kliknite Novi zadatak s bilo kojeg mjesta u GitLabu i na terenu Tip izabrati Incident.
Poboljšali smo GitLab upozorenja tako što smo dodali novu vrstu spominjanja posebno za njih u GitLab Markdown, što olakšava dijeljenje i spominjanje upozorenja. Koristi ^alert#1234da spomenete upozorenje u bilo kojem polju Markdown: u incidentima, tiketima ili zahtjevima za spajanje. Ovo će vam također pomoći da identificirate poslove koji su kreirani iz upozorenja, a ne iz tiketa ili zahtjeva za spajanje.
Opis upozorenja sadrži informacije ključne za rješavanje problema i oporavak, a ove informacije bi trebale biti lako dostupne tako da ne morate mijenjati alate ili kartice dok radite na rješavanju incidenta. Incidenti kreirani iz upozorenja prikazuju puni opis upozorenja na kartici Detalji upozorenja.
GitLab, kao jedna aplikacija, ima jedinstvenu mogućnost da brzo otkrije sadržaj u cijelom DevOps radnom toku. U GitLabu 13.4, napredna pretraga vraća rezultate 75% brže kada je ograničeno na određene prostore imena i projekte, kao na GitLab.com.
Postojala je opcija da se odgodi brisanje projekta uveden 12.6. Međutim, ranije nije bilo moguće vidjeti sve projekte koji čekaju brisanje na jednom mjestu. Administratori GitLab korisničkih instanci sada mogu vidjeti sve projekte na čekanju za brisanje na jednom mjestu, zajedno s dugmadima za jednostavno vraćanje tih projekata.
Ova funkcija 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.
Ranije su grupna push pravila mogla biti konfigurisana samo posjetom svake grupe pojedinačno kroz GitLab korisničko sučelje i primjenom tih pravila. Sada možete upravljati ovim pravilima putem API-ja kako biste podržali vaše prilagođene alate i GitLab automatizaciju.
Pohrana vjerodajnica Pruža administratorima informacije koje su im potrebne za upravljanje korisničkim vjerodajnicama za njihovu GitLab instancu. Budući da se organizacije fokusirane na usklađenost razlikuju po strogosti svojih politika upravljanja vjerodajnicama, dodali smo dugme koje omogućava administratorima da opciono opozove korisnički token za lični pristup (PAT). Administratori sada mogu lako opozvati potencijalno ugrožene PAT-ove. Ova funkcija je korisna za organizacije koje žele fleksibilnije opcije usklađenosti kako bi smanjile ometanje svojih korisnika.
U GitLab 13.4, uvodimo novi način prilagođavanja statičkog uređivača web mjesta. Iako konfiguraciona datoteka ne sprema niti prima nikakva podešavanja u ovom izdanju, mi postavljamo temelje za buduće prilagođavanje ponašanja urednika. U budućim izdanjima dodaćemo fajlu .gitlab/static-site-editor.yml parametri za instalaciju adresa osnovne lokacije, na kojoj slike učitane u editor se pohranjuju, nadjačavajući postavke sintakse Markdowna i druge postavke uređivača.
Prednja stvar je fleksibilan i zgodan način za definisanje varijabli stranica u datotekama podataka za obradu od strane generatora statičkog sajta. 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 datoteke sa podacima, uvodni dio je obično formatiran kao YAML ili JSON i zahtijeva dosljednu i preciznu sintaksu. Korisnici koji nisu upoznati sa specifičnim sintaktičkim pravilima mogu nenamjerno unijeti nevažeće oznake, što zauzvrat može uzrokovati probleme s formatiranjem ili čak neuspjehe u izgradnji.
WYSIWYG način uređivanja statičkog uređivača web mjesta već uklanja uvod iz uređivača kako bi spriječio ove greške u formatiranju. Međutim, to vas sprječava da promijenite vrijednosti pohranjene u ovom dijelu bez vraćanja na uređivanje u izvornom načinu. U GitLabu 13.4, možete pristupiti bilo kojem polju i urediti njegovu vrijednost u poznatom interfejsu zasnovanom na obrascima. Kada se pritisne dugme Postavke (Postavke) otvorit će se panel koji prikazuje polje obrasca za svaki ključ definiran na početku. Polja se popunjavaju trenutnom vrijednošću, a uređivanje bilo kojeg od njih je jednostavno kao unošenje u web obrazac. Uređivanje uvoda na ovaj način izbjegava složenu sintaksu i daje vam potpunu kontrolu nad sadržajem dok osiguravate da je konačni rezultat dosljedno formatiran.
Za korisnike Jira na GitLabu: GitLab aplikacija za Jira и DVCS konektor omogućavaju vam da prikažete informacije o GitLab urezivanju i zahtjevima za spajanje direktno u Jira. U kombinaciji s našom ugrađenom Jira integracijom, možete se lako kretati između dvije aplikacije dok radite.
Ove funkcije su ranije bile dostupne samo u našem Premium planu, ali su sada dostupne svim korisnicima!
Gitaly klaster vam omogućava da replicirate Git repozitorije na više "toplih" Gitaly čvorova. Ovo povećava toleranciju grešaka eliminacijom pojedinačnih tačaka kvara. Transakcione operacije, uveden u GitLab 13.3, uzrokuje da se promjene emituju na sve Gitaly čvorove u klasteru, ali samo Gitaly čvorovi koji glasaju u saglasnosti sa primarnim čvorom spremaju promjene na disk. Ako se svi čvorovi replike ne slažu, samo jedna kopija promjene će biti pohranjena na disku, stvarajući jednu tačku kvara dok se asinhrona replikacija ne završi.
Većinsko glasanje poboljšava toleranciju grešaka tako što zahtijeva pristanak većine čvorova (ne svih) prije spremanja promjena na disk. Ako je ova funkcija prebacivanja omogućena, upisivanje bi trebalo uspjeti na više čvorova. Nesaglasni čvorovi se automatski sinkroniziraju korištenjem asinhrone replikacije od onih čvorova koji su formirali kvorum.
Projekti u kojima ljudi pišu konfiguracije u JSON ili YAML često su skloni problemima jer je lako napraviti grešku u kucanju i pokvariti nešto. Moguće je napisati inspekcijske alate kako bi se ovi problemi uhvatili u CI cevovodu, ali korištenje JSON datoteke šeme može biti korisno za pružanje dokumentacije i savjeta.
Učesnici projekta mogu definirati u svom spremištu putanju do prilagođene šeme u datoteci .gitlab/.gitlab-webide.yml, koji specificira šemu i putanju do datoteka koje treba provjeriti. Kada učitate određenu datoteku u Web IDE, vidjet ćete dodatne povratne informacije i provjeru valjanosti koji će vam pomoći da kreirate datoteku.
Ako koristite transportere sa usmjerenim acikličnim grafom (Directed Acyclic Graph (DAG)), možda ćete otkriti da postoji ograničenje od 10 poslova koje posao može specificirati u needs:, prestrogo. U 13.4, zadana granica je povećana sa 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, ovo ograničenje možete povećati još više postavljanjem funkcije prebacivanja, iako ne nudimo zvaničnu podršku za ovo.
U nekim slučajevima, propušteni posao u cjevovodu može se pogreš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šan posao i artefakt cjevovoda na bilo kojoj aktivnoj grani, zahtjevu za spajanje ili oznaci kako bi spriječio njegovo brisanje nakon isteka. Postaje lakše postaviti agresivnija pravila isteka za čišćenje starih artefakata. Ovo pomaže u smanjenju potrošnje prostora na disku i osigurava da uvijek imate kopiju najnovijeg artefakta iz cjevovoda.
Optimizacija vašeg CI/CD cevovoda 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 optimizacije vaših cjevovoda.
Izveštaj o ispitivanju jedinice je jednostavan način da vidite rezultate svih testova u cjevovodu. Međutim, s velikim brojem testova, pronalaženje neuspjelih testova može potrajati dugo. Drugi problemi koji mogu otežati korištenje izvještaja uključuju poteškoće pri skrolovanju kroz dugačke izlaze praćenja i zaokruživanje vremena na nulu za testove koji se izvode za manje od 1 sekunde. Sada, prema zadanim postavkama, prilikom sortiranja izvještaja o testiranju, prvo postavlja neuspjele testove na početak izvještaja, a zatim sortira testove po trajanju. To olakšava pronalaženje grešaka i dugih testova. Uz to, trajanje testa se sada prikazuje u milisekundama ili sekundama, što ih čini mnogo bržim za čitanje, a riješeni su i prethodni problemi sa pomicanjem.
Sada postoje ograničenja za veličinu datoteka paketa koje se mogu učitati u GitLab registar paketa. Dodata su ograničenja kako bi se optimizirale performanse registra paketa i spriječile zloupotrebe. Ograničenja se razlikuju ovisno o formatu paketa. Za GitLab.com maksimalne veličine fajlova su:
Conan: 250MB
Maven: 3GB
NPM: 300MB
NuGet: 250MB
PyPI: 3GB
Za prilagođene GitLab instance, zadane postavke su iste. Međutim, administrator može ažurirati ograničenja koristeći Rails konzole.
Možete koristiti GitLab PyPI spremište za kreiranje, objavljivanje i dijeljenje Python paketa zajedno sa izvornim kodom i CI/CD cjevovodima. Međutim, ranije niste mogli da se autentifikujete u spremištu koristeći unapred definisanu varijablu okruženja CI_JOB_TOKEN. Kao rezultat toga, morali ste koristiti svoje lične vjerodajnice da ažurirate PyPI spremište, ili ste možda odlučili da uopće ne koristite spremište.
Sada je lakše koristiti GitLab CI/CD za objavljivanje i instaliranje PyPI paketa koristeći unaprijed definiranu varijablu okruženja CI_JOB_TOKEN.
Za DAST skeniranje na zahtjev koji je bio predstavljeno u prethodnom izdanju, dodani su profili DAST skenera. Oni proširuju mogućnosti konfiguracije ovih skeniranja, omogućavajući vam da brzo kreirate više profila za pokrivanje više vrsta skeniranja. U 13.4, profil popisivača izvorno uključuje postavku vremenskog ograničenja indeksiranja koja postavlja koliko dugo DAST popisivač treba da radi dok pokušava da otkrije sve stranice indeksirane stranice. Profil takođe uključuje postavku vremenskog ograničenja za ciljnu lokaciju kako bi se odredilo koliko dugo pretraživač treba da čeka da stranica postane dostupna prije nego što prekine indeksiranje ako web lokacija ne odgovori statusnim kodom 200 ili 300. Kako nastavljamo poboljšavati, ova funkcija će biti dodano profilu skenera u budućim izdanjima; bit će dodati dodatni parametri konfiguracije.
Ako koristite GitLab stranice i želite bolje upravljati promjenama URL-a, možda ste primijetili da upravljanje preusmjeravanjem na vašoj GitLab stranicama nije moguće. GitLab vam sada omogućava da konfigurišete pravila za preusmjeravanje jednog URL-a na drugi za vašu stranicu stranice dodavanjem konfiguracijske datoteke u spremište. Ova funkcija je omogućena zahvaljujući doprinosu Kevina Barnetta (@PopeDrFreud), naš Eric Eastwood (@MadLittleMods) i GitLab timovi. Hvala svima na doprinosu.
Pristup prethodnim verzijama Terraform stanja je neophodan i za usklađenost i za otklanjanje grešaka ako je potrebno. Podrška za verzioniranje Terraform stanja kojim upravlja GitLab pruža se počevši od GitLaba 13.4. Versioniranje je automatski omogućeno za nove datoteke stanja Terraform. Postojeći Terraform državni fajlovi će biti automatski migrira u verzionirano spremište u kasnijem izdanju.
Kada obrađujete incidente, morate biti u mogućnosti lako odrediti koliko je dugo upozorenje bilo otvoreno i koliko puta je događaj pokrenut. Ovi detalji su često kritični u određivanju utjecaja na kupca i onoga što bi vaš tim trebao prvo riješiti. U novom panelu Detalji o incidentu prikazujemo vrijeme početka upozorenja, broj događaja i vezu do originalnog upozorenja. Ove informacije su dostupne za incidente koji se generiraju iz upozorenja.
Dimenzija ozbiljnosti incidenta omogućava osobama koje reaguju i zainteresovanim stranama da odrede uticaj kvara, kao i metod i hitnost odgovora. Kako vaš tim dijeli rezultate tokom rješavanja incidenata i oporavka, oni mogu promijeniti ovu postavku. Sada možete urediti ozbiljnost incidenta na desnoj bočnoj traci stranice Detalji o incidentu, a težina se prikazuje na listi incidenata.
Ovo poboljšanje uređivača pravila sigurnosti mreže kontejnera omogućava korisnicima da lako kreiraju, uređuju i brišu svoja pravila direktno iz GitLab korisničkog interfejsa. Karakteristike uređivača uključuju .yaml za iskusne korisnike i uređivač pravila s intuitivnim sučeljem za one koji su novi u mrežnim pravilima. U odjeljku možete pronaći nove opcije upravljanja pravilima Sigurnost i usklađenost > Upravljanje prijetnjama > Pravila (Sigurnost i usklađenost > Upravljanje prijetnjama > Smjernice).
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 skladišta objekata, uključujući LFS datoteke, CI artefakte i rezervne kopije. Da biste postavili Azure Blob pohranu, slijedite upute za instalaciju omnibus ili Helm chart.
GitLab procesori poslova također podržavaju Azure za pohranu distribuirani keš. Azure skladište se može konfigurirati pomoću odjeljka [runners.cache.azure].
Kao odgovor na rastuću potražnju za podrškom za pokretanje GitLaba na 64-bitnoj ARM arhitekturi, sa zadovoljstvom najavljujemo dostupnost zvaničnog ARM64 Ubuntu 20.04 Omnibus paketa. Ogromno hvala Zitai Chen i Guillaume Gardet za ogroman doprinos koji su dali - njihovi zahtjevi za spajanje igrali su ključnu ulogu u tome!
Da preuzmete i instalirate paket za Ubuntu 20.04, idite na naš stranica za instalaciju i odaberite Ubuntu.
Pametne kartice, kao što su Common Access Cards (CAC), sada se mogu koristiti za autentifikaciju GitLab instance koja je raspoređena preko Helm grafikona. Pametne kartice se provjeravaju u lokalnoj bazi podataka koristeći X.509 certifikate. Uz to, podrška za pametne kartice sa Helm grafikonom je sada u skladu s podrškom za pametne kartice dostupnom u Omnibus implementacijama.