Publikimi 13.4 është lëshuar me hapësirën ruajtëse HashiCorp për variablat CI, Agjentin Kubernetes dhe qendrën e sigurisë, si dhe veçoritë e ndërrueshme në Starter
Në GitLab, ne jemi gjithmonë duke menduar se si mund t'i ndihmojmë përdoruesit të zvogëlojnë rrezikun, të përmirësojnë efikasitetin dhe të përmirësojnë shpejtësinë e dorëzimit në platformën tuaj të preferuar. Këtë muaj ne kemi shtuar shumë veçori të reja të dobishme që zgjerojnë aftësitë e sigurisë, zvogëlojnë numrin e dobësive, rrisin efikasitetin, thjeshtojnë punën me GitLab dhe ndihmojnë ekipin tuaj të ofrojë veçori edhe më shpejt. Shpresojmë që veçoritë kryesore të lëshimit t'i gjeni të dobishme, si dhe 53 veçori të tjera të reja, shtuar në këtë publikim.
Karakteristikat e avancuara të sigurisë
Ne përpiqemi të shtojmë disa veçori të reja në GitLab DevSecOps çdo muaj, dhe ky version nuk bën përjashtim. në kuadër të montimit dhe vendosjes. Për më tepër, organizatat që duan të mbështesin ndarjen e përgjegjësive të vendosjes së kodit munden tani . Ky rol korrespondon dhe do t'ju lejojë të konfirmoni kërkesat për bashkim (në lokalizimin rus të GitLab "kërkesat e bashkimit") dhe të vendosni kodin në mjedise të mbrojtura, pa ofruar akses për të ndryshuar vetë kodin.
Një mënyrë tjetër për të reduktuar rreziqet është përdorimi i ri . Ekipet e operacioneve mund të vendosin grupe Kubernetes nga GitLab pa pasur nevojë të ekspozojnë grupin e tyre në të gjithë internetin. Ne po prezantojmë gjithashtu mbështetjen e kontrollit automatik të versionit për skedarët e rinj të gjendjes Terraform me për të mbështetur pajtueshmërinë dhe lehtësinë e korrigjimit. Më në fund, pulti i sigurisë së shembullit u bë me raportet e cenueshmërisë dhe cilësimet e sigurisë.
Punë më e përshtatshme dhe efikase me GitLab
Ne kemi përmirësuar kërkimin tonë global për ta përfshirë , duke ju lejuar të lundroni me lehtësi te biletat, grupet, projektet, cilësimet dhe temat e ndihmës më të fundit. Ne jemi të ngazëllyer për të njoftuar se GitLab Pages për të ridrejtuar faqet dhe drejtoritë individuale brenda sajtit, gjë që do t'i lejojë përdoruesit të vendosin në mënyrë më efikase faqet e tyre. Dhe për ata që dëshirojnë të marrin informacion të zgjeruar në lidhje me vendosjen, ky version lejon !
Kontributet me burim të hapur
Ne përfaqësojmë të cilën e shtova . Shenjat në mbulimin e testit të njësisë së kodit të ndryshuar u japin zhvilluesve një ide të qartë të mbulimit të kodit gjatë rishikimit; ky informacion ndihmon në përshpejtimin e rishikimeve dhe zvogëlimin e kohës për bashkimin dhe vendosjen e kodit të ri. Dhe ne gjithashtu dhe plani .
Dhe ky është vetëm fillimi!
Si gjithmonë, ka shumë pak hapësirë në pasqyrën e përgjithshme, por ka shumë veçori interesante në versionin 13.4. Këtu janë disa të tjera:
- .
Nëse doni të dini paraprakisht se çfarë ju pret tjetër lëshojeni, hidhini një sy .
.
këtë muaj -
Fabio kontribuoi ndjeshëm в - një veçori që është pritur për një kohë shumë të gjatë në komunitetin GitLab. Ky është një kontribut vërtet i rëndësishëm me ndryshime jo të parëndësishme që kërkonin bashkëpunim të vazhdueshëm me anëtarët e ekipit të GitLab dhe prekën shumë fusha të projektit si UX, front-end dhe back-end.
Karakteristikat kryesore të lëshimit të GitLab 13.4
Përdorni çelësat HashiCorp Vault në punët CI
(PREMIUM, ULTIMATE, ARGJENDI, ARTË)
Në versionin 12.10, GitLab prezantoi aftësinë për të marrë dhe transferuar çelësat në punët CI duke përdorur mbajtësin e punës GitLab (GitLab runner). Tani jemi duke u zgjeruar , duke shtuar sintaksë të re secrets për të paraqitur .gitlab-ci.yml. Kjo do ta bëjë më të lehtë konfigurimin dhe përdorimin e depove HashiCorp me GitLab.
и .
Prezantimi i Agjentit GitLab Kubernetes
(PREMIUM, ULTIMATE)
Integrimi i GitLab me Kubernetes ka bërë prej kohësh të mundur vendosjen në grupimet e Kubernetes pa pasur nevojë për konfigurim manual. Shumë përdoruesve u pëlqeu lehtësia e përdorimit të kësaj pakete, ndërsa të tjerë hasën disa vështirësi. Për integrimin aktual, grupi juaj duhet të jetë i aksesueshëm nga interneti në mënyrë që GitLab të ketë akses në të. Për shumë organizata, kjo nuk është e mundur sepse ato kufizojnë aksesin në grupe për arsye sigurie, pajtueshmërie ose rregullative. Për të kapërcyer këto kufizime, përdoruesit duhej të ndërtonin mjetet e tyre në krye të GitLab, përndryshe nuk do të mund ta përdornin këtë veçori.
Sot po prezantojmë Agjentin GitLab Kubernetes, një mënyrë e re për t'u vendosur në grupimet Kubernetes. Agjenti funksionon brenda grupit tuaj, kështu që nuk keni nevojë ta ekspozoni atë në të gjithë internetin. Agjenti koordinon vendosjen duke kërkuar ndryshime të reja nga GitLab, në vend që GitLab të shtyjë përditësimet në grup. Pavarësisht se çfarë metode GitOps përdorni, GitLab ju ka mbuluar.
Ju lutemi vini re se ky është lëshimi i parë i agjentit. Fokusi ynë aktual për Agjentin GitLab Kubernetes është të konfigurojë dhe menaxhojë vendosjet përmes kodit. Disa veçori ekzistuese të integrimit të Kubernetes, të tilla si bordet e vendosjes dhe aplikacionet e menaxhuara nga GitLab, nuk mbështeten ende. që këto aftësi do t'i shtohen agjentit në publikimet e ardhshme, si dhe integrime të reja të fokusuara në sigurinë dhe pajtueshmërinë.
и .
Jepni përdoruesve leje vendosjeje pa qasje në kod
(PREMIUM, ULTIMATE, ARGJENDI, ARTË)
Më parë, sistemi i lejeve të GitLab e bëri të vështirë ndarjen e duhur të përgjegjësive brenda ekipit tuaj midis atyre që janë përgjegjës për zhvillimin dhe atyre që janë përgjegjës për vendosjen. Me lëshimin e GitLab 13.4, ju mund të jepni leje për të miratuar kërkesat për bashkim për vendosje, si dhe për të vendosur aktualisht kodin për njerëzit që nuk e shkruajnë kodin, pa u dhënë atyre të drejta aksesi të mirëmbajtësit (në lokalizimin rus të "mirëmbajtësit" të GitLab ).
и .
Qendra e Sigurisë
(I FUNDIT, GOLD)
Më parë, menaxhimi i cenueshmërisë në nivel shembulli ishte i kufizuar si në funksionalitet ashtu edhe në fleksibilitet. Ndërfaqja ishte një faqe e vetme që kombinon detajet e dobësive, grafikët metrikë dhe cilësimet. Nuk ka shumë hapësirë për të zhvilluar këto veçori ose për të përdorur veçori të tjera sigurie.
Ne kemi bërë ndryshime thelbësore në mënyrën se si menaxhojmë sigurinë dhe transparencën në GitLab. Paneli i sigurisë së shembullit është shndërruar në një qendër të tërë sigurie. Ndryshimi më i madh është prezantimi i një strukture të re të menysë: në vend të një faqeje, tani shihni veçmas panelin e sigurisë, raportin e cenueshmërisë dhe seksionin e cilësimeve. Ndërsa funksionaliteti nuk ka ndryshuar, ndarja e tij në pjesë do të lejojë përmirësime në këtë seksion që përndryshe do të ishin të vështira. Kjo gjithashtu krijon bazën për shtimin e aftësive të tjera të lidhura me sigurinë në të ardhmen.
Seksioni i dedikuar i Raportit të Vulnerability tani ka më shumë hapësirë për të shfaqur detaje të rëndësishme. Këtu janë dobësitë që janë aktualisht në listën e dobësive të projektit. Zhvendosja e miniaplikacioneve me matjet e cenueshmërisë në një seksion të veçantë krijon një panel kontrolli të përshtatshëm sigurie. Tani është një kanavacë për vizualizimet e ardhshme - jo vetëm për menaxhimin e cenueshmërisë, por për çdo metrikë të lidhur me sigurinë. Së fundi, një zonë e veçantë e cilësimeve krijon një hapësirë të përbashkët për të gjitha cilësimet e sigurisë në nivel shembulli, jo vetëm për menaxhimin e cenueshmërisë.
и .
Karakteristikat e ndërrueshme janë tani në GitLab Starter
(STARTER, PREMIUM, ULTIMATE, BRONZ, ARGJEND, AR)
GitLab 11.4 u lëshua . Në 12.2 ne prezantuam strategji për ta и , dhe në 13.1 shtuan и për ambiente të ndryshme.
Në fillim të këtij viti, GitLab bëri një angazhim në burim të hapur. Në këtë version, ne kemi përfunduar migrimin e veçorive të ndërrueshme në planin fillestar dhe do të vazhdojmë t'i migrojmë ato në Core nga . Jemi të entuziazmuar që ua sjellim këtë veçori më shumë përdoruesve dhe duam të dëgjojmë se si e përdorni.
и .
Navigim i shpejtë nga shiriti i kërkimit
(BËRTHAM, STARTER, PREMIUM, ULTIMATE, FALAS, BRONZ, ARGJEND, AR)
Ndonjëherë, kur lundroni në GitLab, dëshironi të shkoni direkt në një projekt specifik dhe jo në faqen e rezultateve të kërkimit.
Duke përdorur shiritin e kërkimit global, mund të lundroni shpejt te biletat, grupet, projektet, cilësimet dhe temat e ndihmës më të fundit. Mund të përdorni edhe një çelës kyç /për të lëvizur kursorin në shiritin e kërkimit për të lundruar në GitLab edhe më me efikasitet!
и .
Shfaqja e mbulimit të kodit në ndryshimet e kërkesës për bashkim
(BËRTHAM, STARTER, PREMIUM, ULTIMATE, FALAS, BRONZ, ARGJEND, AR)
Kur shqyrton një kërkesë për bashkim, mund të jetë e vështirë të përcaktohet nëse kodi i ndryshuar mbulohet nga testet e njësisë. Në vend të kësaj, rishikuesit mund të mbështeten në mbulimin e përgjithshëm dhe të kërkojnë që ai të rritet përpara se të miratojnë një kërkesë për bashkim. Kjo mund të çojë në një qasje të rastësishme për të shkruar teste, të cilat në fakt nuk do të përmirësojnë cilësinë e kodit ose mbulimin e testit.
Tani, kur shikoni një ndryshim të kërkesës për bashkim, do të shihni një shfaqje vizuale të mbulimit të kodit. Shenjat e reja do t'ju lejojnë të kuptoni shpejt nëse kodi i ndryshuar mbulohet nga një test i njësisë, i cili do të ndihmojë në përshpejtimin e rishikimit të kodit dhe kohën e bashkimit dhe vendosjes së kodit të ri.
Falënderim dhe Siemens për këtë veçori!
и .
Më shumë mjedise dhe projekte në panelin e Mjedisit
(PREMIUM, ULTIMATE, ARGJENDI, ARTË)
Që nga lëshimi i GitLab 12.5 duke përdorur ju mund të monitoroni gjendjen e mjediseve, por jo më shumë se shtatë mjedise në tre projekte. Ne e kemi përmirësuar këtë panel në versionin 13.4 duke e faqezuar për t'ju ndihmuar të mbani dhe menaxhoni mjediset tuaja në shkallë. Tani mund të shihni më shumë mjedise në më shumë projekte.
и .
GitLab merr kontrollin e ofruesit të GitLab Terraform
(BËRTHAM, STARTER, PREMIUM, ULTIMATE, FALAS, BRONZ, ARGJEND, AR)
Kohët e fundit ne dhe plani . Gjatë muajit të kaluar, ne kemi pranuar 21 kërkesa për bashkim dhe kemi mbyllur 31 bileta, duke përfshirë disa defekte të gjata dhe veçori që mungojnë si p.sh. ... Ti mundesh në dokumentacionin Terraform.
и .
Testimi i turbullt API me specifikimet OpenAPI ose skedarin HAR
(I FUNDIT, GOLD)
Testimi i fuzzimit të API-ve është një mënyrë e shkëlqyer për të gjetur gabime dhe dobësi në aplikacionet tuaja të internetit dhe API-të që mund t'u mungojnë skanerëve dhe metodave të tjera të testimit.
Testimi i fuzzimit të API në GitLab ju lejon të siguroni ose aplikacioni juaj dhe më pas gjeneron automatikisht të dhëna hyrëse të rastësishme të dizajnuara për të testuar rastet e skajshme dhe për të gjetur gabime. Rezultatet janë të dukshme menjëherë brenda tubacionit tuaj.
Ky është versioni ynë i parë i testimit të API fuzz dhe do të donim të dëgjonim se çfarë mendoni. Ne kemi më shumë në magazinë për testim fuzz , të cilën do ta bazojmë në lëshimin e kësaj veçorie.
и .
Shikoni paraprakisht grafikët e rinj në panelin e matjeve
(BËRTHAM, STARTER, PREMIUM, ULTIMATE, FALAS, BRONZ, ARGJEND, AR)
Më parë, krijimi i një grafiku në pultin e metrikës në GitLab nuk ishte një detyrë e lehtë. Pasi keni krijuar metrikën në skedarin YAML të panelit të kontrollit, keni bërë ndryshime në master, pa qenë në gjendje të verifikoni që grafiku i krijuar rishtazi funksionon ashtu siç ju nevojitet. Duke filluar me këtë version, ju mund të shikoni paraprakisht ndryshimet ndërsa krijoni grafikun, duke marrë një ide për rezultatin përpara se të dërgoni ndryshimet në skedarin YAML të pultit.
и .
Të dhëna për mbulimin e kodit nga testet për të gjitha projektet e grupit
(PREMIUM, ULTIMATE, ARGJENDI, ARTË)
Kur menaxhoni një numër të madh projektesh në GitLab, ju nevojitet një burim i vetëm informacioni se si mbulimi i kodit po ndryshon me kalimin e kohës në të gjitha projektet. Më parë, shfaqja e këtij informacioni kërkonte punë manuale të lodhshme dhe që kërkonte kohë: duhej të shkarkoje të dhënat e mbulimit të kodit nga çdo projekt dhe t'i kombinosh në një tabelë.
Në versionin 13.4, u bë e mundur të montohej lehtësisht dhe shpejt .csv skedar me të gjitha të dhënat mbi mbulimin e kodit për të gjitha projektet e grupit ose për një përzgjedhje projektesh. Kjo veçori është MVC, do të pasohet nga aftësia .
и .
Mbështetje për gjuhë të reja për testim të plotë fuzz
(I FUNDIT, GOLD)
Ky version prezanton mbështetje për disa gjuhë të reja për testimin fuzz që synon mbulimin e plotë.
Tani mund të vlerësoni aftësitë e plota të testimit fuzzing në aplikacionet tuaja Java, Rust dhe Swift dhe të gjeni gabime dhe dobësi që skanerët dhe metodat e tjera të testimit mund të humbasin.
и .
Sinjalizimet në faqen kryesore të mjedisit
(PREMIUM, ULTIMATE, ARGJENDI, ARTË)
Faqja e mjediseve tregon gjendjen e përgjithshme të mjediseve tuaja. Në këtë version ne e kemi përmirësuar këtë faqe duke shtuar ekranin e alarmit. Sinjalizimet e aktivizuara së bashku me statusin e mjediseve tuaja do t'ju ndihmojnë të ndërmerrni shpejt veprime për të korrigjuar situatat që lindin.
и .
Tubacionet e mbivendosur tani mund të ekzekutojnë tubacionet e tyre të mbivendosur
(BËRTHAM, STARTER, PREMIUM, ULTIMATE, FALAS, BRONZ, ARGJEND, AR)
Duke përdorur tubacione të ndërlidhura, tani është e mundur të ekzekutohen tubacione të reja brenda tubacioneve fëmijë. Niveli shtesë i thellësisë mund të jetë i dobishëm nëse keni nevojë për fleksibilitet për të gjeneruar një numër të ndryshueshëm tubacionesh.
Më parë, kur përdoreshin tubacionet e ndërlidhura, çdo tubacion fëmijë kërkonte që një punë nxitëse të përcaktohej manualisht në tubacionin prind. Tani mund të krijoni tubacione të mbivendosura që do të nisin në mënyrë dinamike çdo numër tubacionesh të reja të mbivendosur. Për shembull, nëse keni një monorepozitor, mund të gjeneroni në mënyrë dinamike nëntubacionin e parë, i cili vetë do të krijojë numrin e kërkuar të tubacioneve të reja bazuar në ndryshimet në degë.
и .
Lundrimi i përmirësuar midis tubacioneve mëmë dhe të mbivendosur
(BËRTHAM, STARTER, PREMIUM, ULTIMATE, FALAS, BRONZ, ARGJEND, AR)
Më parë, lundrimi midis tubacioneve mëmë dhe të mbivendosur nuk ishte shumë i përshtatshëm - ju nevojiteshin shumë klikime për të arritur në tubacionin e dëshiruar. Gjithashtu nuk ishte e lehtë të kuptosh se cila punë e nisi tubacionin. Tani do të jetë shumë më e lehtë për të parë lidhjet midis tubacioneve mëmë dhe të mbivendosur.
и .
Punët me matricë paralele tregojnë variablat përkatëse në titullin e punës
(BËRTHAM, STARTER, PREMIUM, ULTIMATE, FALAS, BRONZ, ARGJEND, AR)
Nëse keni përdorur , mund të keni vënë re se ishte e vështirë të përcaktoje se cila variabël matricë është përdorur për një punë të caktuar, pasi emrat e punëve dukeshin si matrix 1/4. Në versionin 13.4, do të shihni vlerat përkatëse të variablave që janë përdorur në atë punë në vend të emrit të përgjithshëm të punës. Për shembull, nëse qëllimi juaj është të korrigjoni arkitekturën x86, atëherë puna do të thirret matrix: debug x86.
и .
Përmirësime të tjera në GitLab 13.4
Lidhja e një llogarie Atlassian
(BËRTHAM, STARTER, PREMIUM, ULTIMATE)
Përdoruesit e GitLab tani do të jenë në gjendje të lidhin llogaritë e tyre GitLab me llogarinë e tyre Atlassian Cloud. Kjo do t'ju lejojë të identifikoheni në GitLab me kredencialet tuaja Atlassian dhe gjithashtu do të vendosë bazat për përmirësime të ardhshme të integrimit. dhe me produkte të tjera nga linja Atlassian.
и .
Eksportimi i një liste të të gjitha detyrimeve të bashkimit
(I FUNDIT, GOLD)
Organizatat e fokusuara në pajtueshmëri kanë nevojë për një mënyrë për t'u treguar audituesve një pamje tërësore të komponentëve që lidhen me çdo ndryshim të caktuar në prodhim. Në GitLab, kjo do të thotë të mbledhësh gjithçka në një vend: kërkesa për bashkim, bileta, tubacione, skanime sigurie dhe të dhëna të tjera të kryerjes. Deri më tani, ju ose duhej ta mblidhnit manualisht në GitLab ose të konfiguronit mjetet tuaja për të mbledhur informacionin, gjë që nuk ishte shumë efikase.
Tani mund t'i mbledhni dhe eksportoni në mënyrë programore këto të dhëna për të përmbushur kërkesat e auditimit ose për të kryer analiza të tjera. Për të eksportuar një listë të të gjitha detyrimeve të bashkimit për grupin aktual, duhet të shkoni te dhe klikoni në butonin Lista e të gjitha detyrimeve të bashkimit. Skedari që rezulton do të përmbajë të gjitha detyrimet e kërkesës për bashkim, autorin e tyre, ID-në e kërkesës së bashkimit të lidhur, grupin, projektin, konfirmuesit dhe informacione të tjera.
и .
Listoni dhe menaxhoni argumentet e aksesit personal përmes API
(I FUNDIT, GOLD)
Menaxhimi i aksesit në hapësirën e emrave të GitLab është një pjesë e rëndësishme e përpjekjeve të pajtueshmërisë. Nga parimet e privilegjit më të vogël deri tek çaktivizimi i aksesit në kohë, mund të ketë disa kërkesa që lidhen me shenjat e aksesit personal në GitLab. Për ta bërë më të lehtë ruajtjen dhe menaxhimin e të gjitha këtyre kredencialeve të përdoruesit brenda hapësirës suaj të emrave, ne kemi ofruar mundësinë për të renditur të gjitha shenjat e aksesit personal dhe opsionalisht nëpërmjet API.
Këto përmirësime në GitLab API i lejojnë përdoruesit të listojnë dhe revokojnë shenjat e tyre personale të aksesit, dhe administratorët të listojnë dhe revokojnë argumentet e përdoruesve të tyre. Tani do të jetë më e lehtë për administratorët të shohin se kush ka akses në hapësirën e tyre të emrave, të marrin vendime për aksesin bazuar në të dhënat e përdoruesit dhe të revokojnë shenjat personale të aksesit që mund të jenë komprometuar ose që bien jashtë politikave të menaxhimit të aksesit të kompanisë.
и .
Çështjet e lidhura dhe veçoritë e tjera janë tani në GitLab Core
(BËRTHAM, STARTER, PREMIUM, ULTIMATE, FALAS, BRONZ, ARGJEND, AR)
Disa muaj më parë ne shpallëm një plan për të . Duke punuar për të përmbushur këtë premtim, ne kemi bërë , и (në lokalizimin rus të "bordit të diskutimit" të GitLab) i disponueshëm në planin Core. Kjo vlen vetëm për marrëdhëniet "të lidhura me", marrëdhëniet "blloqe" dhe "të bllokuara" mbeten në planet me pagesë.
и .
Shfaqja e emrit të degës së origjinës në shiritin anësor të kërkesës për bashkim
(BËRTHAM, STARTER, PREMIUM, ULTIMATE, FALAS, BRONZ, ARGJEND, AR)
Kur rishikoni ndryshimet e kodit, diskutimet dhe detyrimet e kërkesave për bashkim, shpesh është e dëshirueshme të bëni një arkë lokale të degës për një rishikim më të thellë. Megjithatë, gjetja e emrit të temës bëhet gjithnjë e më e vështirë pasi më shumë përmbajtje shtohet në përshkrimin e kërkesës për bashkim dhe ju duhet të lëvizni më poshtë në faqe.
Ne kemi shtuar emrin e degës në shiritin anësor të kërkesës për bashkim, duke e bërë atë të aksesueshëm në çdo kohë dhe duke eliminuar nevojën për të lëvizur nëpër të gjithë faqen. Ashtu si lidhja me kërkesën për bashkim, seksioni i degës së burimit përmban një buton të përshtatshëm "kopjimi".
Falënderim për kontributin tuaj të madh në zhvillimin e kësaj veçorie!
и .
Treguesi i pranisë së skedarëve të shembur në kërkesën për bashkim ndryshon
(BËRTHAM, STARTER, PREMIUM, ULTIMATE, FALAS, BRONZ, ARGJEND, AR)
Kërkesat e bashkimit që shtojnë ndryshime në skedarë të shumtë ndonjëherë shembi dallimet e skedarëve të mëdhenj për të përmirësuar performancën e paraqitjes. Kur kjo ndodh, është e mundur të kapërceni aksidentalisht një skedar gjatë shqyrtimit, veçanërisht në kërkesat për bashkim me një numër të madh skedarësh. Duke filluar me versionin 13.4, kërkesat për bashkim do të tregojnë ndryshimet që përmbajnë skedarë të palosur, kështu që nuk do t'i humbisni këta skedarë gjatë shqyrtimit të kodit. Për qartësi edhe më të madhe, ne planifikojmë t'u shtojmë theksimin këtyre skedarëve në një version të ardhshëm. Qëndroni të akorduar për përditësime në .
и .
Paralajmërim për praninë e skedarëve të shembur në ndryshimin e një kërkese për bashkim
(BËRTHAM, STARTER, PREMIUM, ULTIMATE, FALAS, BRONZ, ARGJEND, AR)
Në seksionin e ndryshimeve të kërkesës për bashkim, skedarët e mëdhenj fshihen për të përmirësuar performancën. Megjithatë, kur rishikoni kodin, disa skedarë mund të mungojnë kur rishikuesi lëviz nëpër listën e skedarëve, pasi të gjithë skedarët e mëdhenj janë shembur.
Ne kemi shtuar një paralajmërim të dukshëm në krye të faqes së ndryshimit të kërkesës për bashkim për të informuar përdoruesit se ka një skedar të shkrirë në këtë seksion. Në këtë mënyrë, nuk do të humbisni asnjë ndryshim në kërkesën për bashkim gjatë shqyrtimit.
и .
Rikuperimi automatik i depove të grupit Gitaly
(BËRTHAM, STARTER, PREMIUM, ULTIMATE, FALAS, BRONZ, ARGJEND, AR)
Më parë, kur nyja kryesore e një grupi Gitaly dilte jashtë linje, depot në atë nyje shënoheshin si vetëm për lexim. Kjo parandaloi humbjen e të dhënave në situatat kur kishte ndryshime në nyje që nuk ishin përsëritur ende. Kur nyja u kthye në linjë, GitLab nuk u rivendos automatikisht dhe administratorët duhej të fillonin manualisht procesin e sinkronizimit ose të pranonin humbjen e të dhënave. Situata të tjera, të tilla si dështimi i një pune riprodhimi në një nyje dytësore, mund të rezultojnë gjithashtu në depo të ndenjura ose vetëm për lexim. Në këtë rast, depoja mbeti e ndenjur derisa të ndodhte operacioni tjetër i shkrimit, i cili do të fillonte punën e replikimit.
Për të zgjidhur këtë problem tani planifikon një punë riprodhimi kur zbulon një depo të vjetëruar në një nyje dhe versionin më të fundit të depove në një tjetër. Kjo punë e riprodhimit e mban të përditësuar automatikisht depon, duke eliminuar nevojën për të rivendosur manualisht të dhënat. Rimëkëmbja automatike siguron gjithashtu që nyjet dytësore të përditësohen shpejt nëse një punë riprodhimi dështon, në vend që të presin për operacionin tjetër të shkrimit. Meqenëse shumë grupe Gilaly ruajnë një numër të madh deposh, kjo redukton ndjeshëm kohën që administratorët dhe inxhinierët e besueshmërisë shpenzojnë për të rikuperuar të dhënat pas një gabimi.
Përveç kësaj, riparimi automatik fillon përsëritjen e depove në çdo nyje të re Gitaly të shtuar në grup, duke eliminuar punën manuale kur shtohen nyje të reja.
и .
Shënoni një detyrë për të bërë si të përfunduar në faqen e projektimit
(BËRTHAM, STARTER, PREMIUM, ULTIMATE, FALAS, BRONZ, ARGJEND, AR)
Komunikimi efektiv në GitLab bazohet në listat e detyrave. Nëse jeni përmendur në një koment, është kritike të jeni në gjendje të hidheni te një detyrë dhe ose të filloni të bëni diçka ose ta shënoni atë si të përfunduar. Është gjithashtu e rëndësishme të jeni në gjendje t'i caktoni një detyrë vetes kur duhet të punoni në diçka ose t'i ktheheni asaj më vonë.
Më parë, nuk mund të shtonit detyra ose t'i shënonit si të përfunduara kur punoni me dizajne. Kjo prishi seriozisht efikasitetin e komunikimit midis ekipeve të produkteve, pasi detyrat janë një element kritik i rrjedhës së punës GitLab.
Në versionin 13.4, dizajnet arrijnë me komentet e biletave në përdorimin e detyrave, gjë që e bën punën me to më të qëndrueshme dhe efikase.
и .
Udhëzues i përmirësuar për zgjidhjen e problemeve për CI/CD
(BËRTHAM, STARTER, PREMIUM, ULTIMATE, FALAS, BRONZ, ARGJEND, AR)
Ne kemi përmirësuar udhëzuesin e zgjidhjes së problemeve për GitLab CI/CD me më shumë informacion rreth problemeve të zakonshme që mund të hasni. Shpresojmë që dokumentacioni i përmirësuar do të jetë një burim i vlefshëm për t'ju ndihmuar të filloni dhe përdorni GitLab CI/CD shpejt dhe me lehtësi.
и .
Kërkesat për bashkim nuk bien më nga radha e bashkimit
(PREMIUM, ULTIMATE, ARGJENDI, ARTË)
Më parë, kërkesat për bashkim mund të dilnin nga radha e bashkimit rastësisht për shkak të komenteve të vonuara. Nëse një kërkesë për bashkim ishte tashmë në radhë dhe dikush shtoi një koment në të që krijonte një diskutim të ri të pazgjidhur, kërkesa për bashkim konsiderohej e papërshtatshme për një bashkim dhe do të dilte nga radha. Tani, pasi një kërkesë për bashkim shtohet në radhën e bashkimit, mund të shtohen komente të reja pa frikën e ndërprerjes së procesit të bashkimit.
и .
Shfaqja e vlerës së mbulimit të kodit për një punë në një kërkesë bashkimi
(BËRTHAM, STARTER, PREMIUM, ULTIMATE, FALAS, BRONZ, ARGJEND, AR)
Zhvilluesit duhet të jenë në gjendje të shohin vlerën e mbulimit të kodit pasi të ketë përfunduar tubacioni - edhe në skenarë komplekse, si p.sh. ekzekutimi i një tubacioni me punë të shumta që duhet të analizohen për të llogaritur vlerën e mbulimit. Më parë, miniaplikacioni i kërkesës për bashkim tregonte vetëm mesataren e këtyre vlerave, që nënkuptonte se duhej të lundroje te faqja e punës dhe të ktheheshe te kërkesa e bashkimit për të marrë vlera të ndërmjetme mbulimi. Për t'ju kursyer kohë dhe këto hapa shtesë, ne e bëmë miniaplikacionin të shfaqë vlerën mesatare të mbulimit, ndryshimet e saj midis degëve të objektivit dhe burimit, si dhe një këshillë veglash që tregon vlerën e mbulimit për secilën punë në bazë të së cilës është llogaritur mesatarja.
и .
Heqja e paketave nga regjistri i paketave kur shikoni një grup
(BËRTHAM, STARTER, PREMIUM, ULTIMATE, FALAS, BRONZ, ARGJEND, AR)
Regjistri i paketave GitLab është një vend për ruajtjen dhe shpërndarjen e paketave në formate të ndryshme. Kur keni shumë paketa në projektin ose grupin tuaj, duhet të identifikoni shpejt paketat e papërdorura dhe t'i hiqni ato për të parandaluar që njerëzit t'i shkarkojnë ato. Ju mund të hiqni paketat nga regjistri juaj nëpërmjet ose përmes ndërfaqes së përdoruesit të regjistrit të paketës. Megjithatë, deri më tani nuk mund të hiqnit paketat kur shikoni një grup përmes ndërfaqes së përdoruesit. Si rezultat, ju duhej të hiqnit paketat e panevojshme në bazë të projektit, gjë që ishte joefikase.
Tani mund të hiqni paketat kur shikoni regjistrin e paketave të një grupi. Thjesht shkoni te faqja e regjistrit të paketave të grupit, filtroni paketat sipas emrit dhe hiqni ato që nuk ju nevojiten.
и .
Shkallëzimi i paketave Conan në nivelin e projektit
(BËRTHAM, STARTER, PREMIUM, ULTIMATE, FALAS, BRONZ, ARGJEND, AR)
Ju mund të përdorni depon e Conan në GitLab për të publikuar dhe shpërndarë varësitë C/C++. Megjithatë, paketat e mëparshme mund të shkallëzoheshin vetëm në nivelin e shembullit, pasi emri i paketës Conan mund të kishte vetëm një maksimum prej 51 karakteresh. Nëse dëshironi të publikoni një paketë nga një nëngrup, për shembull gitlab-org/ci-cd/package-stage/feature-testing/conan, ishte pothuajse e pamundur të bëhej.
Tani mund t'i zvogëloni paketat Conan deri në nivelin e projektit, duke e bërë të lehtë publikimin dhe shpërndarjen e varësive të projekteve tuaja.
и .
Mbështetje për menaxherët e rinj të paketave dhe gjuhët për skanimin e varësisë
(I FUNDIT, GOLD)
Ne jemi të ngazëllyer të shtojmë skanimet e varësisë për projektet e kodit C, C++, C# dhe .Net që përdorin menaxherët e paketave NuGet 4.9+ ose Conan në listën tonë . Tani mund të aktivizoni skanimin e varësisë si pjesë e fazës Secure për të kontrolluar për dobësi të njohura në varësitë e shtuara përmes menaxherëve të paketave. Dobësitë e gjetura do të shfaqen në kërkesën tuaj për bashkim së bashku me nivelin e tyre të ashpërsisë, në mënyrë që të dini përpara se të ekzekutoni bashkimin se çfarë rreziqesh mbart varësia e re. Ju gjithashtu mund të konfiguroni projektin tuaj për të kërkuar për varësitë me dobësi me nivele kritike (kritike), të larta (të larta) ose të panjohura (të panjohura).
и .
Njoftimet kur ndryshoni cilësimin e kërkesës për bashkim në "Shkrije kur tubacioni të përfundojë me sukses"
(BËRTHAM, STARTER, PREMIUM, ULTIMATE, FALAS, BRONZ, ARGJEND, AR)
Më parë, kur vendosni cilësimet e kërkesës për bashkim Bashkohen kur tubacioni të përfundojë (Merge When Pipeline Succeeds, MWPS) nuk u dërgua asnjë njoftim me email. Ju është dashur të kontrolloni manualisht statusin ose të prisni për një njoftim bashkimi. Me këtë version, ne jemi të kënaqur të shfaqim kontributet e përdoruesve , i cili e zgjidhi këtë problem duke shtuar njoftime automatike për të gjithë të abonuar në një kërkesë bashkimi kur një rishikues ndryshon cilësimin e bashkimit në MWPS.
и .
Krijimi i grupeve EKS me një version të Kubernetes të specifikuar nga përdoruesi
(BËRTHAM, STARTER, PREMIUM, ULTIMATE, FALAS, BRONZ, ARGJEND, AR)
Përdoruesit e GitLab tani mund të zgjedhin versionin e Kubernetes që do të ofrohet nga EKS; ju mund të zgjidhni midis versioneve 1.14–1.17.
и .
Krijimi i incidenteve si lloje biletash
(BËRTHAM, STARTER, PREMIUM, ULTIMATE, FALAS, BRONZ, ARGJEND, AR)
Jo çdo problem që lind menjëherë shkakton alarme: përdoruesit raportojnë ndërprerje dhe anëtarët e ekipit hetojnë çështjet e performancës. Incidentet tani janë një lloj bilete, kështu që ekipet tuaja mund t'i krijojnë ato shpejt si pjesë e rrjedhës së tyre normale të punës. Klikoni Detyrë e re nga kudo në GitLab dhe në terren Lloj zgjedh Incident.
и .
Përmendja e alarmeve të GitLab në Markdown
(BËRTHAM, STARTER, PREMIUM, ULTIMATE, FALAS, BRONZ, ARGJEND, AR)
Ne kemi përmirësuar sinjalizimet e GitLab duke shtuar një lloj të ri përmendjeje posaçërisht për ta në GitLab Markdown, duke e bërë më të lehtë ndarjen dhe përmendjen e sinjalizimeve. Përdorni ^alert#1234për të përmendur sinjalizimin në çdo fushë Markdown: në incidente, bileta ose kërkesa për bashkim. Kjo do t'ju ndihmojë gjithashtu të identifikoni punët që krijohen nga sinjalizimet dhe jo nga biletat ose kërkesat për bashkim.
и .
Shikimi i ngarkesës së alarmit sipas incidentit
(BËRTHAM, STARTER, PREMIUM, ULTIMATE, FALAS, BRONZ, ARGJEND, AR)
Përshkrimi i sinjalizimit përmban informacione kritike për zgjidhjen e problemeve dhe rikuperimin, dhe ky informacion duhet të jetë lehtësisht i aksesueshëm, në mënyrë që të mos keni nevojë të ndërroni mjetet ose skedat ndërsa punoni për të zgjidhur një incident. Incidentet e krijuara nga sinjalizimet shfaqin përshkrimin e plotë të alarmit në skedë Detajet e alarmit.
Kërkim i avancuar 75% më i shpejtë
(STARTER, PREMIUM, ULTIMATE, BRONZ, ARGJEND, AR)
GitLab, si një aplikacion i vetëm, ka aftësinë unike për të bërë shpejt zbulimin e përmbajtjes në të gjithë rrjedhën tuaj të punës DevOps. Në GitLab 13.4, kërkimi i avancuar i kthen rezultatet 75% më shpejt kur është , si në GitLab.com.
и .
Shikimi i projekteve të fshira për administratorët
(BËRTHAM, STARTER, PREMIUM, ULTIMATE)
Kishte një mundësi për të shtyrë fshirjen e projektit . Megjithatë, më parë nuk ishte e mundur të shiheshin të gjitha projektet në pritje të fshirjes në një vend. Administratorët e shembullit të përdoruesve të GitLab tani mund të shikojnë të gjitha projektet e fshirjes në pritje në një vend, së bashku me butonat për t'i rikthyer me lehtësi ato projekte.
Kjo veçori u jep administratorëve një kontroll më të madh mbi fshirjen e projektit duke mbledhur të gjithë informacionin përkatës në një vend dhe duke ofruar mundësinë për të zhbërë veprimet e padëshiruara të fshirjes.
Falënderim për këtë veçori!
и .
U shtua mbështetje për rregullat e shtytjes së grupit në API
(STARTER, PREMIUM, ULTIMATE, BRONZ, ARGJEND, AR)
Më parë, rregullat e shtytjes në grup mund të konfiguroheshin vetëm duke vizituar secilin grup individualisht përmes UI-së së GitLab dhe duke zbatuar ato rregulla. Tani mund t'i menaxhoni këto rregulla nëpërmjet një API për të mbështetur mjetet tuaja të personalizuara dhe automatizimin GitLab.
и .
Revokimi i kodeve të aksesit personal për ruajtjen e kredencialeve të vetë-menaxhuar
(I FUNDIT)
U ofron administratorëve informacionin që u nevojitet për të menaxhuar kredencialet e përdoruesve për shembullin e tyre GitLab. Për shkak se organizatat e përqendruara te pajtueshmëria ndryshojnë në ashpërsinë e politikave të tyre të menaxhimit të kredencialeve, ne kemi shtuar një buton që lejon administratorët të revokojnë opsionalisht kodin e hyrjes personale të një përdoruesi (PAT). Administratorët tani mund të revokojnë lehtësisht PAT-të e mundshme të komprometuara. Kjo veçori është e dobishme për organizatat që duan opsione më fleksibël të pajtueshmërisë për të minimizuar ndërprerjet për përdoruesit e tyre.
и .
Skedari i konfigurimit për redaktuesin statik të faqes
(BËRTHAM, STARTER, PREMIUM, ULTIMATE, FALAS, BRONZ, ARGJEND, AR)
Në GitLab 13.4, ne po prezantojmë një mënyrë të re për të personalizuar redaktuesin statik të faqes. Megjithëse skedari i konfigurimit nuk ruan ose nuk merr asnjë cilësim në këtë version, ne po shtrojmë bazat për personalizimin e ardhshëm të sjelljes së redaktorit. Në publikimet e ardhshme do t'i shtojmë skedarit .gitlab/static-site-editor.yml parametrat për instalim , në të cilën , duke anashkaluar cilësimet e sintaksës Markdown dhe cilësimet e tjera të redaktuesit.
и .
Redaktimi i pjesës hyrëse të një skedari duke përdorur një redaktues statik të faqes
(BËRTHAM, STARTER, PREMIUM, ULTIMATE, FALAS, BRONZ, ARGJEND, AR)
Materiali i përparmë është një mënyrë fleksibël dhe e përshtatshme për të përcaktuar variablat e faqeve në skedarët e të dhënave për t'u përpunuar nga gjeneratori i faqes statike. Zakonisht përdoret për të vendosur titullin e faqes, shabllonin e paraqitjes ose autorin, por mund të përdoret për të kaluar çdo lloj meta të dhënash te gjeneratori kur e jep faqen në HTML. E përfshirë në krye të çdo skedari të dhënash, pjesa hyrëse zakonisht formatohet si YAML ose JSON dhe kërkon sintaksë të qëndrueshme dhe të saktë. Përdoruesit që nuk janë të njohur me rregulla specifike sintaksore mund të futin pa dashje shënimin e pavlefshëm, i cili nga ana tjetër mund të shkaktojë probleme në formatimin apo edhe dështime në ndërtim.
Modaliteti i redaktimit WYSIWYG i redaktuesit statik të faqes tashmë e heq hyrjen nga redaktori për të parandaluar këto gabime të formatimit. Sidoqoftë, kjo ju pengon të ndryshoni vlerat e ruajtura në këtë pjesë pa u kthyer në redaktim në modalitetin burimor. Në GitLab 13.4, ju mund të përdorni çdo fushë dhe të modifikoni vlerën e saj në një ndërfaqe të njohur të bazuar në forma. Kur shtypet butoni Cilësimet (Cilësimet) do të hapet një panel që tregon një fushë formulari për çdo çelës të përcaktuar në fillim. Fushat janë të mbushura me vlerën aktuale dhe redaktimi i ndonjërës prej tyre është po aq i thjeshtë sa futja e tij në formën e internetit. Redaktimi i hyrjes suaj në këtë mënyrë shmang sintaksën komplekse dhe ju jep kontroll të plotë mbi përmbajtjen duke siguruar që rezultati përfundimtar të formatohet vazhdimisht.
и .
GitLab për Jira dhe DVCS Connector tani është në Core
(BËRTHAM, STARTER, PREMIUM, ULTIMATE, FALAS, BRONZ, ARGJEND, AR)
Për përdoruesit e Jira në GitLab: и ju lejon të shfaqni informacione rreth angazhimeve të GitLab dhe të bashkoni kërkesat drejtpërdrejt në Jira. Kombinuar me integrimin tonë të integruar Jira, mund të lëvizni lehtësisht midis dy aplikacioneve ndërsa punoni.
Këto veçori më parë disponoheshin vetëm në planin tonë Premium, por tani janë të disponueshme për të gjithë përdoruesit!
и .
Votimi i shumicës për transaksionet e grupit Gitaly (beta)
(BËRTHAM, STARTER, PREMIUM, ULTIMATE)
Një grup Gitaly ju lejon të përsërisni depot e Git në nyje të shumta Gitaly "të ngrohta". Kjo rrit tolerancën ndaj gabimeve duke eliminuar pikat e vetme të dështimit. , i prezantuar në GitLab 13.3, bëjnë që ndryshimet të transmetohen në të gjitha nyjet Gitaly në grup, por vetëm nyjet Gitaly që votojnë në pajtim me nyjen parësore i ruajnë ndryshimet në disk. Nëse të gjitha nyjet e kopjeve nuk pajtohen, vetëm një kopje e ndryshimit do të ruhet në disk, duke krijuar një pikë të vetme dështimi derisa të përfundojë replikimi asinkron.
Votimi i shumicës përmirëson tolerancën ndaj gabimeve duke kërkuar pëlqimin e shumicës së nyjeve (jo të gjitha) përpara se të ruani ndryshimet në disk. Nëse kjo veçori e ndërrimit është e aktivizuar, shkrimi duhet të ketë sukses në nyje të shumta. Nyjet kundërshtuese sinkronizohen automatikisht duke përdorur replikimin asinkron nga ato nyje që kanë formuar një kuorum.
и .
Mbështetje e skemës së personalizuar për vërtetimin JSON në Web IDE
(PREMIUM, ULTIMATE, ARGJENDI, ARTË)
Projektet ku njerëzit shkruajnë konfigurime në JSON ose YAML janë shpesh të prirur për probleme sepse është e lehtë të bësh një gabim shtypi dhe të prishësh diçka. Është e mundur të shkruhen mjete inspektimi për të kapur këto çështje në tubacionin CI, por përdorimi i një skedari skeme JSON mund të jetë i dobishëm për të ofruar dokumentacion dhe sugjerime.
Pjesëmarrësit e projektit mund të përcaktojnë në depon e tyre shtegun drejt një skeme të personalizuar në një skedar .gitlab/.gitlab-webide.yml, i cili specifikon skemën dhe shtegun e skedarëve që do të kontrollohen. Kur ngarkoni një skedar specifik në Web IDE, do të shihni komente shtesë dhe vërtetim për t'ju ndihmuar të krijoni skedarin.
и .
Kufiri i degëzimit të Grafikut Aciklik të Drejtuar (DAG) u rrit në 50
(BËRTHAM, STARTER, PREMIUM, ULTIMATE, FALAS, BRONZ, ARGJEND, AR)
Nëse jeni duke përdorur transportues (Grafiku Aciklik i Drejtuar (DAG)), mund të zbuloni se ekziston një kufi prej 10 punësh që një punë mund të specifikojë në needs:, shumë i ashpër. Në 13.4, kufiri i paracaktuar u rrit nga 10 në 50 për të lejuar rrjete më komplekse të marrëdhënieve midis punëve në tubacionet tuaja.
Nëse je administrator i një shembulli të personalizuar të GitLab, mund ta rrisësh këtë kufi edhe më lart duke vendosur një veçori ndryshimi, megjithëse ne nuk ofrojmë mbështetje zyrtare për këtë.
и .
Sjellje e përmirësuar needs për detyrat e humbura
(BËRTHAM, STARTER, PREMIUM, ULTIMATE, FALAS, BRONZ, ARGJEND, AR)
Në disa raste, një punë e humbur në një tubacion mund të konsiderohet gabimisht e suksesshme për varësitë e specifikuara në needs, gjë që bëri që të hapeshin punë të mëvonshme, gjë që nuk duhej të ndodhte. Kjo sjellje është rregulluar në versionin 13.4 dhe needs tani trajton saktë rastet e detyrave të humbura.
и .
Vendosni objektin e fundit të kërkimit për të parandaluar fshirjen e tij
(BËRTHAM, STARTER, PREMIUM, ULTIMATE, FALAS, BRONZ, ARGJEND, AR)
GitLab tani bllokon automatikisht punën e fundit të suksesshme dhe artifaktin e tubacionit në çdo degë aktive, kërkesë bashkimi ose etiketë për të parandaluar fshirjen e tij pas skadimit. Bëhet më e lehtë të vendosësh rregulla më agresive të skadimit për të pastruar artefaktet e vjetra. Kjo ndihmon në reduktimin e konsumit të hapësirës në disk dhe siguron që të keni gjithmonë një kopje të artefaktit më të fundit nga tubacioni.
и .
Udhëzues CI/CD për optimizimin e tubacionit
(BËRTHAM, STARTER, PREMIUM, ULTIMATE, FALAS, BRONZ, ARGJEND, AR)
Optimizimi i tubacionit tuaj CI/CD mund të përmirësojë shpejtësinë e dorëzimit dhe të kursejë para. Ne kemi përmirësuar dokumentacionin tonë për të përfshirë një udhëzues të shpejtë për të përfituar sa më shumë nga optimizimi i tubacioneve tuaja.
и .
Raporti i testit i renditur sipas statusit të testit
(BËRTHAM, STARTER, PREMIUM, ULTIMATE, FALAS, BRONZ, ARGJEND, AR)
është një mënyrë e thjeshtë për të parë rezultatet e të gjitha testeve në një tubacion. Megjithatë, me një numër të madh testesh, gjetja e testeve të dështuara mund të marrë shumë kohë. Çështje të tjera që mund ta bëjnë raportin të vështirë për t'u përdorur përfshijnë vështirësinë në lëvizjen nëpër daljet e gjurmëve të gjata dhe rrumbullakimin e kohës në zero për testet që funksionojnë në më pak se 1 sekondë. Tani, si parazgjedhje, kur renditet një raport testimi, së pari vendos testet e dështuara në fillim të raportit dhe më pas i rendit testet sipas kohëzgjatjes. Kjo e bën më të lehtë gjetjen e dështimeve dhe testeve të gjata. Për më tepër, kohëzgjatjet e provës tani shfaqen në milisekonda ose sekonda, duke i bërë ato shumë më të shpejta për t'u lexuar dhe problemet e mëparshme të lëvizjes janë zgjidhur gjithashtu.
и .
Kufizime në madhësinë e skedarëve të ngarkuar në regjistrin e paketës
(BËRTHAM, STARTER, PREMIUM, ULTIMATE, FALAS, BRONZ, ARGJEND, AR)
Tani ka kufizime në madhësinë e skedarëve të paketave që mund të ngarkohen në regjistrin e paketave GitLab. Janë shtuar kufizime për të optimizuar performancën e regjistrit të paketave dhe për të parandaluar abuzimin. Kufijtë ndryshojnë në varësi të formatit të paketës. Për GitLab.com, madhësitë maksimale të skedarëve janë:
- Conan: 250 MB
- Maven: 3 GB
- NPM: 300 MB
- NuGet: 250 MB
- PyPI: 3 GB
Për rastet e personalizuara të GitLab, standardet janë të njëjta. Megjithatë, administratori mund të përditësojë kufizimet duke përdorur .
и .
Përdorni CI_JOB_TOKEN për të publikuar paketat PyPI
(BËRTHAM, STARTER, PREMIUM, ULTIMATE, FALAS, BRONZ, ARGJEND, AR)
Ju mund të përdorni depo GitLab PyPI për të krijuar, publikuar dhe ndarë paketat Python së bashku me kodin burimor dhe tubacionet CI/CD. Megjithatë, më parë nuk mund të vërtetoje në depo duke përdorur një variabël mjedisi të paracaktuar CI_JOB_TOKEN. Si rezultat, ju është dashur të përdorni kredencialet tuaja personale për të përditësuar depon e PyPI, ose mund të keni vendosur të mos e përdorni fare depon.
Tani është më e lehtë të përdoret GitLab CI/CD për të publikuar dhe instaluar paketat PyPI duke përdorur një variabël mjedisi të paracaktuar CI_JOB_TOKEN.
и .
Profilet e skanerit DAST sipas kërkesës
(I FUNDIT, GOLD)
Për skanimin DAST sipas kërkesës që ishte , janë shtuar profilet e skanerit DAST. Ato zgjerojnë aftësitë e konfigurimit të këtyre skanimeve, duke ju lejuar të krijoni shpejt profile të shumta për të mbuluar lloje të shumta skanimi. Në 13.4, profili i zvarritësit përfshin në mënyrë origjinale një cilësim të skadimit të zvarritësit që përcakton se sa kohë duhet të funksionojë zvarritësi DAST ndërsa përpiqet të zbulojë të gjitha faqet e një sajti të zvarritur. Profili përfshin gjithashtu një cilësim të skadimit të faqes së synuar për të vendosur se sa kohë duhet të presë zvarritësi që një sajt të bëhet i aksesueshëm përpara se të ndërpritet gjurmimi nëse sajti nuk përgjigjet me një kod statusi 200 ose 300. Ndërsa ne vazhdojmë të përmirësojmë, kjo veçori do të jetë shtohet në profilin e skanerit në versionet e ardhshme; do të shtohen parametra shtesë të konfigurimit.
и .
Një skedar i thjeshtë konfigurimi i ridrejtimit për Faqet GitLab
(BËRTHAM, STARTER, PREMIUM, ULTIMATE, FALAS, BRONZ, ARGJEND, AR)
Nëse përdorni Faqet GitLab dhe dëshironi të menaxhoni më mirë ndryshimet e URL-së, mund të keni vënë re se menaxhimi i ridrejtimeve në faqen tuaj të Faqeve GitLab nuk ishte i mundur. GitLab tani ju lejon të konfiguroni rregullat për të ridrejtuar një URL në një tjetër për faqen tuaj të Faqeve duke shtuar një skedar konfigurimi në depo. Kjo veçori është bërë e mundur falë kontributit të Kevin Barnett (), Eric Eastwood ynë () dhe ekipet e GitLab. Faleminderit të gjithëve për kontributin tuaj.
и .
Gjendja Terraform e menaxhuar nga GitLab
(BËRTHAM, STARTER, PREMIUM, ULTIMATE, FALAS, BRONZ, ARGJEND, AR)
Qasja në versionet e mëparshme të gjendjes Terraform është e nevojshme si për pajtueshmëri ashtu edhe për korrigjim nëse është e nevojshme. Mbështetja për versionimin e gjendjes Terraform të menaxhuar nga GitLab ofrohet duke filluar me GitLab 13.4. Versionimi aktivizohet automatikisht për skedarët e rinj të gjendjes Terraform. Do të jenë skedarët ekzistues të gjendjes Terraform në një publikim të mëvonshëm.
и .
Detaje të rëndësishme të njoftimit për incidentin
(BËRTHAM, STARTER, PREMIUM, ULTIMATE, FALAS, BRONZ, ARGJEND, AR)
Kur përpunoni incidente, duhet të jeni në gjendje të përcaktoni lehtësisht se sa kohë ishte hapur një alarm dhe sa herë u aktivizua ngjarja. Këto detaje janë shpesh kritike në përcaktimin e ndikimit te klienti dhe atë që ekipi juaj duhet të trajtojë së pari. Në panelin e ri të Detajeve të Incidentit, ne shfaqim kohën e fillimit të sinjalizimit, numrin e ngjarjeve dhe një lidhje me sinjalizimin origjinal. Ky informacion është i disponueshëm për incidentet që krijohen nga sinjalizimet.
и .
Vendosja dhe modifikimi i parametrit të ashpërsisë së incidentit
(BËRTHAM, STARTER, PREMIUM, ULTIMATE, FALAS, BRONZ, ARGJEND, AR)
Dimensioni i ashpërsisë së incidentit i lejon reaguesit dhe palët e interesuara të përcaktojnë ndikimin e një ndërprerjeje, si dhe metodën dhe urgjencën e përgjigjes. Ndërsa ekipi juaj ndan rezultatet gjatë zgjidhjes dhe rikuperimit të incidentit, ai mund ta ndryshojë këtë cilësim. Tani mund të modifikoni ashpërsinë e një incidenti në shiritin anësor të djathtë të faqes Detajet e incidentit dhe ashpërsia shfaqet në listën e incidenteve.
и .
Krijimi, redaktimi dhe fshirja e rregullave të sigurisë së rrjetit të kontejnerëve
(I FUNDIT, GOLD)
Ky përmirësim në Redaktuesin e Rregullave të Sigurisë së Rrjetit të Kontejnerëve i lejon përdoruesit të krijojnë, modifikojnë dhe fshijnë me lehtësi rregullat e tyre direkt nga ndërfaqja e përdoruesit GitLab. Karakteristikat e redaktorit përfshijnë .yaml për përdoruesit me përvojë dhe një redaktues rregullash me një ndërfaqe intuitive për ata që janë të rinj në rregullat e rrjetit. Mund të gjeni opsione të reja të menaxhimit të rregullave në seksion Siguria dhe Pajtueshmëria > Menaxhimi i Kërcënimeve > Rregullat (Siguria dhe Pajtueshmëria > Menaxhimi i Kërcënimeve > Politikat).
и .
Mbështetje për ruajtjen e blob Azure
(BËRTHAM, STARTER, PREMIUM, ULTIMATE, FALAS, BRONZ, ARGJEND, AR)
Të dy GitLab dhe GitLab Runner tani mbështesin , duke e bërë më të lehtë ekzekutimin e shërbimeve GitLab në Azure.
Instancat e GitLab mbështesin Azure për të gjitha llojet e dyqaneve të objekteve, duke përfshirë skedarët LFS, artefaktet CI, dhe . Për të konfiguruar hapësirën ruajtëse Azure Blob, ndiqni udhëzimet e instalimit ose .
Përpunuesit e punës GitLab mbështesin gjithashtu Azure për ruajtje . Ruajtja Azure mund të konfigurohet duke përdorur seksionin .
и .
Paketat Omnibus ARM64 për Ubuntu dhe OpenSUSE
(BËRTHAM, STARTER, PREMIUM, ULTIMATE)
Në përgjigje të kërkesës në rritje për mbështetje për ekzekutimin e GitLab në arkitekturën ARM 64-bit, ne jemi të kënaqur të njoftojmë disponueshmërinë e paketës zyrtare ARM64 Ubuntu 20.04 Omnibus. Falenderime të mëdha për Zitai Chen dhe Guillaume Gardet për kontributet e mëdha që dhanë - kërkesat e tyre për bashkim luajtën një rol kyç në këtë!
Për të shkarkuar dhe instaluar paketën për Ubuntu 20.04, shkoni te ne dhe zgjidhni Ubuntu.
и .
Mbështetje për vërtetimin e kartës inteligjente për grafikun GitLab Helm
(PREMIUM, ULTIMATE)
Kartat inteligjente, të tilla si Common Access Cards (CAC), tani mund të përdoren për të vërtetuar në një shembull të GitLab të vendosur përmes diagramit Helm. Kartat inteligjente vërtetohen kundrejt një baze të dhënash lokale duke përdorur certifikatat X.509. Me këtë, mbështetja e kartës inteligjente me diagramin Helm është tani në përputhje me mbështetjen e kartës inteligjente të disponueshme në vendosjet e Omnibus.
и .
Shënimet e hollësishme të lëshimit dhe udhëzimet e përditësimit/instalimit mund të lexohen në postimin origjinal në anglisht: .
Ne po punonim për përkthimin nga anglishtja , , и .
Burimi: www.habr.com