# Вышел релиз GitLab 13.4 с хранилищем HashiCorp для переменных CI и Kubernetes Agent

Doli shkoi 13.4 me ruajtjen HashiCorp për variablat CI, Agjenti Kubernetes dhe qendra e sigurisë, si dhe funksionalitetet që mund të aktivizohen në Starter

Në GitLab, ne gjithmonë mendojmë për mënyrat se si të ndihmojmë përdoruesit të reduktojnë rreziqet, të rrisin efikasitetin dhe shpejtësinë e dërgesës në platformën tuaj të preferuar. Në këtë muaj kemi shtuar mjaft novacione të dobishme që zgjasin mundësitë e sigurisë, zvogëlojnë numrin e dobësive, rrisin efikasitetin, thjeshtojnë punën me GitLab dhe ndihmojnë ekipin tuaj të dërgojë funksionalitete edhe më shpejt. Shpresojmë se do t'ju nevojiten funksionalitetet kryesore të këtij lëshimi, si dhe 53 funksionalitete të tjera të reja, të shtuar në këtë lëshim.

Mundësi të zgjeruara të sigurisë

Ne mundohemi të shtojmë disa funksionalitete të reja në GitLab DevSecOps çdo muaj, dhe ky lëshim nuk është përjashtim. Çelësat sekrete nga ruajtja HashiCorp tani mund të përdoren në detyrat CI/CD si pjesë e ndërtimit dhe shpërndarjes. Gjithashtu, organizatat që dëshirojnë të mbajnë ndarjen e detyrave për shpërndarjen e kodit tani mund të shtojnë përdoruesit me akses Reporter në rolin Deployer. Ky rol i përputhet principit të privilegjeve minimale të aksesit dhe do të lejojë të konfirmoni kërkesat për bashkim (në lokalizimin shqip të GitLab 'kërkesat për bashkim') dhe të zhvilloni kodin në mjedise të mbrojtura, pa ofruar akses për ndryshimin e vetë kodit.

Një mënyrë tjetër për të ulur rreziqet është përdorimi i Agjentit GitLab Kubernetes. Specialistët e operacioneve mund të zhvillojnë klasterë Kubernetes nga GitLab pa nevojën për të hapur aksesin e klasterit të tyre për tërë internetin. Ne gjithashtu prezantojmë mbështetje automatike për kontrollin e versioneve për skedarët e rinj të gjendjes Terraform me gjendjen e menaxhuar GitLab Terraform për të mbështetur përputhshmërinë dhe lehtësinë në debugging. Dhe në fund, pultin e sigurisë në instancë e kemi transformuar në qendër të sigurisë GitLab me raporte për dobësitë dhe cilësimet e sigurisë.

Punë më të lehtë dhe efikase me GitLab

Ne e kemi përmirësuar kërkimin tonë global duke shtuar navigim të shpejtë nga barra e kërkimit, duke lejuar kalimin lehtësisht në biletat e fundit, grupe, projekte, cilësime dhe seksione ndihme. Jemi të lumtur të njoftojmë se në GitLab Pages kanë ardhur ridrektimet për të redirektuar faqe dhe katalogë të veçantë brenda faqes, që do t'u lejojë përdoruesve të zhvillojnë faqet e tyre më me efikasitet. Për ata që dëshirojnë të marrin informacione të zgjeruara mbi zhvillimin, ky lëshim lejon të menaxhojnë qindra zhvillime të mbështetura për projekte nga paneli i kontrollit të mjedisit!

Depozita me kod të hapur

Ne paraqesim shfaqjen e mbulimit të kodit në diferencat e kërkesave për bashkim, e cila u shtua nga MVP i këtij muaji, Fabio Huser. Shënimet mbi mbulimin nga testet e njësive të kodit të ndryshuar japin zhvilluesve një pasqyrë të qartë mbi mbulimin e kodit gjatë rishikimit; kjo informacion ndihmon në përshpejtimin e rishikimit dhe zvogëlon kohën për bashkim dhe zhvillimin e kodit të ri. Gjithashtu ne kemi zhvendosur flamujt e veçorive (feature flags) në Starter dhe planifikojmë t'i transferojmë ata në Core në lëshimin 13.5.

Dhe kjo është vetëm fillimi!

Si gjithmonë, në përmbledhjen e përgjithshme ka shumë pak hapësirë, ndërsa veçoritë e shkëlqyera në lëshimin 13.4 janë shumë. Ja disa të tjera:

• Shikoni listën e tokeneve të qasjeve personale dhe shfuqizoni ato përmes API
• Shfuqizoni tokene të qasjeve personale për ruajtjen e identitetit të vetë-menaxhuar
• Shënoni detyrat e përmbushura në faqen e dizajnit
• Përgjigjet e ngjashme (në lokalizimin shqip të GitLab quhen «linja e ndërtimit») tani mund të nisin përgjigje të ngjashme
• Mbështetje për autentifikimin përmes kartave inteligjente për Helm chart GitLab.

Nëse dëshironi të dini më herët se çfarë do ju presë në të ardhmen versionin e ardhshëm, shikoni videon tonë mbi lëshimin 13.5.

Shikoni webin tonë për “Resiliency In Challenging Times”.

MVP të këtij muaji — Fabio Huser

Fabio ka kontribuar ndjeshëm kontributi në shfaqjen e mbulimit të kodit në diferencat e kërkesave për bashkim — një tipar që është pritur shumë nga komuniteti i GitLab. Ky është një kontribut vërtet i rëndësishëm me ndryshime jo triviale që kërkuan bashkëpunim të vazhdueshëm me anëtarët e ekipit të GitLab dhe preknin shumë fusha të projektit, si UX, frontend dhe backend.

Tiparet kryesore të versionit GitLab 13.4

Përdorni çelët e HashiCorp Vault në detyrat CI

(PREMIUM, ULTIMATE, SILVER, GOLD) Faza e ciklit DevOps: Lëshimi

Në lëshimin 12.10, GitLab prezantoi mundësinë për të marrë dhe dërguar çelësa në detyrat CI përmes menaxherit të detyrave GitLab (GitLab runner). Tani po e zgjasim autentifikimin përmes JWT, duke shtuar sintaksën e re secrets në skedarin .gitlab-ci.yml. Kjo do ta lehtësojë konfigurimin dhe përdorimin e depozitës HashiCorp me GitLab.

Dokumentacioni për punën me çelësa dhe biletën origjinale.

Prezantimi i Agjentit GitLab Kubernetes

(PREMIUM, ULTIMATE) Faza e ciklit DevOps: Konfiguro

Integrimi i GitLab me Kubernetes ka mundësuar kohë më parë deployimin në klasterë Kubernetes pa nevojën për konfigurim manual. Shumë përdorues e kanë vlerësuar lehtësinë e përdorimit të kësaj bashkëpunimi, ndërsa të tjerë janë përballur me disa vështirësi. Për integrimin aktual, klasteri juaj duhet të jetë i aksesueshëm nga interneti, në mënyrë që GitLab të ketë qasje në të. Për shumë organizata, kjo nuk është e mundur, pasi ata kufizojnë qasjen në klasterë për arsye sigurie, përmbushjeje kërkesash ose rregullore. Për të anashkaluar këto kufizime, përdoruesit duhet të krijojnë mjetet e tyre mbi GitLab, përndryshe nuk mund të shfrytëzojnë këtë mundësi.

Sot ne paraqesim GitLab Kubernetes Agent – një mënyrë të re për të implementuar në klasteret Kubernetes. Agjenti funksionon brenda klasterit tuaj, kështu që nuk do t'ju duhet ta hapni atë për gjithë internetin. Agjenti koordinon implementimin duke kërkuar ndryshime të reja nga GitLab, në vend që GitLab të dërgojë përditësime në klaster. Pa marrë parasysh metodën GitOps që përdorni, GitLab do t'ju përshtatet.

Kujdes, kjo është lëshimi i parë i agjentit. Aktualisht, ne kemi fokusuar GitLab Kubernetes Agent në konfigurimin dhe menaxhimin e implementimit përmes kodit. Disa funksionalitete ekzistuese të integrimit të Kubernetes, si bordet e implementimit dhe aplikacionet e menaxhuara nga GitLab, për momentin nuk mbështeten. Ne supozojmë, që këto mundësi do të shtohen në agjent në lëshime të ardhshme, si dhe integrime të reja të orientuara drejt sigurisë dhe përputhshmërisë.

Dokumentacioni për GitLab Kubernetes Agent dhe biletën origjinale.

Ofroni përdoruesve leje për të implementuar pa akses në kod

(PREMIUM, ULTIMATE, SILVER, GOLD) Faza e ciklit DevOps: Lëshimi

Më parë, sistemi i lejeve në GitLab nuk ofronte mundësinë për të ndarë në mënyrë të arsyeshme detyrat në ekipin tuaj midis atyre që janë përgjegjës për zhvillimin dhe atyre që janë përgjegjës për implementimin. Me lansimin e GitLab 13.4, mund t'i jepni leje për miratimin e merge requests për implementim, si dhe për implementimin e kodit njerëzve që nuk programojnë, pa iu ofruar atyre të drejtat e aksesit si mirëmbajtës (në lokalizimin rus të GitLab, "mirëmbajtës").

Dokumentacioni për qasjen në ambient dhe epiku origjinal.

Qendra e Sigurisë

(ULTIMATE, GOLD) Faza e ciklit DevOps: Siguro

Më parë, menaxhimi i dobësive në nivel instancë ishte i kufizuar si në funksionalitet ashtu edhe në fleksibilitet. Interfaca ishte një faqe e vetme që kombinonte detajet e dobësive, grafikët e treguesve dhe cilësimet. Nuk kishte shumë hapësirë për zhvillimin e këtyre funksioneve ose për përdorimin e mjeteve të tjera të sigurisë.

Ne kemi bërë ndryshime themelore në menaxhimin e sigurisë dhe transparencës në GitLab. Paneli i sigurisë së instancës është transformuar në një qendër të plotë të sigurisë. Ndryshimi më i madh është introduktimi i një strukture të re menuje: në vend të një faqe, tani shihni veçmas panelin e menaxhimit të sigurisë, raportin e dobësive dhe seksionin e cilësimeve. Edhe pse funksionaliteti nuk ka ndryshuar, ndarja në pjesë do të lejojë përmirësimin e këtij seksioni, gjë që përndryshe do të ishte e vështirë. Kjo gjithashtu krijon një bazë për shtimin e mundësive të tjera që lidhen me sigurinë në të ardhmen.

Sekcioni special për raportimin e dobësive tani ka më shumë hapësirë për të treguar detajet e rëndësishme. Këtu janë mbledhur dobësitë që aktualisht janë në listën e dobësive të projektit. Shkëmbimi i widget-eve me metrika dobësish në një seksion të veçantë krijon një panel të përshtatshëm për menaxhimin e sigurisë. Tani ky është një kanavacë për vizualizime të ardhshme — jo vetëm për menaxhimin e dobësive, por edhe për çdo metrikë tjetër që lidhet me sigurinë. Për më tepër, një hapësirë e veçantë për cilësime krijon një hapësirë të përbashkët për të gjitha cilësimet e sigurisë në nivel instance, jo vetëm për menaxhimin e dobësive.

Dokumentacioni për qendrën e sigurisë së instancës dhe epiku origjinal.

Veçoritë e ndërrueshme tani në GitLab Starter

(STARTER, PREMIUM, ULTIMATE, BRONZE, SILVER, GOLD) Faza e ciklit DevOps: Lëshimi

Në GitLab 11.4 u lëshua versioni alfa i veçorive të ndërrueshme. Në 12.2 ne prezantuam strategjitë për to përqindjen e përdoruesve dhe sipas ID-së së përdoruesve, dhe në 13.1 shtuam listat e përdoruesve dhe cilësimin e strategjive për mjedise të ndryshme.

Më herët këtë vit, GitLab mori përsipër angazhimin për të transferuar 18 veçori në kodin e hapur. Në këtë version ne përfunduam transferimin e veçorive të ndërrueshme në planin Starter dhe do të vazhdojmë transferimin e tyre në Core me GitLab 13.5. Jemi të lumtur të ofrojmë këtë mundësi për më shumë përdorues dhe duam të dimë se si do t'i përdorni ata.

Dokumentacioni për funksionalitetet e alternuara dhe biletën origjinale.

Navigim i shpejtë nga barra e kërkimit

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Disponueshmëria

Ndonjëherë, kur navigoni në GitLab, dëshironi të kaloni menjëherë në një projekt të caktuar, jo në faqen me rezultatet e kërkimit.

Me panelin e kërkimit global, ju mund të kaloni shpejt te biletat e fundit, grupet, projektet, konfigurimet dhe seksionet e ndihmës. Ju gjithashtu mund të përdorni çelësin e shpejtësisë /, për të kaluar kursorin në panelin e kërkimit, për ta bërë lëvizjen tuaj në GitLab edhe më efikase!

Dokumentacioni për mbushjen e automatizuar në kërkim dhe biletën origjinale.

Shfaqja e mbulimit të kodit në diferencat e kërkesave për bashkim

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Faza e ciklit DevOps: Krijimi

Gjatë rishikimit të kërkesës për bashkim, mund të jetë e vështirë të përcaktohet nëse kodi i modifikuar është mbuluar nga testet e njësive. Në vend të kësaj, rishikuesit mund të mbështeten në mbulimin e përgjithshëm dhe të kërkojnë rritjen e tij përpara se të konfirmojnë kërkesën për bashkim. Kjo mund të çojë në një qasje të paorganizuar ndaj shkrimit të testeve, e cila në të vërtetë nuk do të përmirësojë cilësinë e kodit ose mbulimin e tij nga testet.

Tani tani, kur shikoni difen e kërkesës së bashkimit, do të shihni një pamje të qartë të mbulimit të kodit. Shënimet e reja do të lejojnë të kuptoni shpejt nëse kodi i modifikuar është mbuluar nga një test njësi, që do të ndihmojë në përshpejtimin e rishikimit të kodit dhe kohës së bashkimit e përhapjes së kodit të ri.

Faleminderit Fabio Huser dhe Siemens për këtë vefeatures!

Dokumentacioni mbi shfaqjen e mbulimit të kodit nga testet dhe biletën origjinale.

Më shumë mjedise dhe projekte në panelin e mjeteve

(PREMIUM, ULTIMATE, SILVER, GOLD) Faza e ciklit DevOps: Lëshimi

Nga lëshimi i GitLab 12.5 me panelin e mjeteve ju keni mundur të ndiqni gjendjen e mjeteve, por jo më shumë se shtatë mjedise në tri projekte. Ne e kemi përmirësuar këtë panel në lëshimin 13.4, duke e ndarë atë në faqe për t'ju ndihmuar të mbani dhe menaxhoni mjediset tuaja në shkallë më të madhe. Tani mund të shihni më shumë mjedise në më shumë projekte.

Dokumentacioni mbi panelin e mjeteve dhe biletën origjinale.

GitLab pranoi menaxhimin e ofruesit GitLab Terraform

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Faza e ciklit DevOps: Konfiguro

Së fundi ne mori të drejtat e mirëmbajtësve për ofruesin GitLab Terraform dhe planifikojmë për ta përmirësuar në lëshimet e ardhshme. Në muajin e fundit pranuam 21 kërkesa për bashkim dhe mbyllëm 31 bileta, duke përfshirë disa gabime dhe vefeatures që kanë ekzistuar prej kohësh, si mbështetje për klasterët e instancave. Ju mund të mësoni më shumë rreth ofruesit GitLab Terraform në dokumentacionin për Terraform.

Dokumentacioni për ofruesin GitLab Terraform dhe biletën origjinale.

Testimi i fuzzing-ut të API-ve me specifikimet OpenAPI ose skedarin HAR

(ULTIMATE, GOLD) Faza e ciklit DevOps: Siguro

Testimi i fuzzing-ut të API-ve është një mënyrë e shkëlqyer për të zbuluar gabime dhe vulnerabilitete në aplikacionet tuaja web dhe API që mund të humbasin skanerët e tjerë dhe metodat e testimit.

Testimi i fuzzing-ut të API-ve në GitLab lejon të ofrohet specificimi OpenAPI v2 ose skedari HAR i aplikacionit tuaj, dhe pastaj automatikisht gjeneron të dhëna të rastësishme të dizajnuara për të verifikuar rastet e skajshme dhe për të gjetur gabime. Rezultatet shfaqen menjëherë në kuadër të pipeline tuaj.

Ky është lëshimi ynë i parë i testimit të fuzzing-ut të API-ve, dhe do të ishim të lumtur të dëgjonim çfarë mendoni. Për testimin e fuzzing-ut kemi akoma mjaft Ide, të cilat do t'i bazojmë në lëshimin e këtij funksioni.

Dokumentacioni për testimin e fuzzing-ut të API-ve dhe epiku origjinal.

Parapamja e grafikëve të rinj në panelin e metrikave

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Faza e ciklit DevOps: Monitor

Më parë, krijimi i një grafiku në panelin e metrikave në GitLab ishte një detyrë e vështirë. Pas krijimit të një metri në skedarin YAML të panelit, duhej të bënit ndryshime në master, nuk e keni mundësinë të verifikoni se si funksionon grafiku i krijuar sapo. Nga ky version mund të parashikoni ndryshimet ndërsa krijoni grafikun, duke fituar një ide mbi rezultatin para se të dërgoni ndryshimet në skedarin YAML të panelit.

Dokumentacioni për shtimin e një grafiku të ri në panel dhe biletën origjinale.

Të dhënat e mbulimit të kodit me teste për të gjitha projektet e grupit

(PREMIUM, ULTIMATE, SILVER, GOLD) Faza e ciklit DevOps: Verifikimi

Kur menaxhoni një numër të madh projektesh në GitLab, keni nevojë për një burim të vetëm informacioni mbi atë se si ndryshon mbulimi i kodit me kalimin e kohës në të gjitha projektet. Më parë, shfaqja e kësaj informatione kërkonte punë manuale të lodhshme dhe të mundimshme: duhej të shkarkonit të dhënat e mbulimit të kodit me teste nga secili projekt dhe t'i bashkoni ato në një tabelë.

Në versionin 13.4 u shfaq mundësia për të mbledhur lehtë dhe shpejt në .csv një skedar të gjitha të dhënat e mbulimit të kodit për të gjitha projektet e grupit ose për një përzgjedhje projektesh. Ky funksionalitet është MVC, pas tij do të vijë mundësia për të ndërtuar një grafik të mbulimit mesatar me kalimin e kohës.

Dokumentacioni për analitikën e depozitave dhe biletën origjinale.

Mbështetje për gjuhë të reja për testimin e plotë të fuzzing-ut

(ULTIMATE, GOLD) Faza e ciklit DevOps: Siguro

Ky lançim paraqet mbështetje për disa gjuhë të reja për testimin e fuzzing-ut, të fokusuar në mbulimin e plotë.

Tani mund të vlerësoni të gjitha mundësitë e testimit të fuzzing-ut në aplikacionet tuaja në Java, Rust dhe Swift dhe të gjeni gabime dhe vulnerabilitete që skanerë dhe metoda të tjera testimi mund të humbasin.

Dokumentacioni për gjuhët e mbështetura për testimin e fuzzing-ut dhe epiku origjinal.

Njoftimet në faqen kryesore të ambienteve

(PREMIUM, ULTIMATE, SILVER, GOLD) Faza e ciklit DevOps: Lëshimi

Faqja e ambienteve tregon gjendjen e përgjithshme të ambienteve tuaja. Në këtë lançim e kemi përmirësuar këtë faqe duke shtuar shfaqjen e njoftimeve. Njoftimet e ndodhura së bashku me statusin e ambienteve tuaja do t'ju ndihmojnë të merrni masa më shpejt për të adresuar situatat që shfaqen.

Dokumentacioni për shikimin e njoftimeve më të fundit në ambiente dhe biletën origjinale.

Pipeline-t e ngjashme tani mund të nisin pipeline-t e tyre të ngjashme

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Faza e ciklit DevOps: Verifikimi

Duke përdorimit të pipeline-ve të futura, tani është e mundur të nisni pipeline të rinj brenda pipeline-ve të fëmijëve. Një nivel shtesë thellësie mund të jetë i dobishëm nëse keni nevojë për fleksibilitet për të gjeneruar një sasi të ndryshme pipeline-sh.

Më parë, gjatë përdorimit të pipeline-ve të futura, çdo pipeline fëmijë kërkonte një detyrë-trigger, e cila caktohej manualisht në pipeline-n prind. Tani, mund të krijoni pipeline të futura që do të nisin dinamik çdo numër të pipeline-ve të reja të futura. Për shembull, nëse keni një mono-repozitor, mund të gjeneroni dinamik pipeline-n e parë të futur, i cili vetë do të krijojë numrin e nevojshëm të pipeline-ve të reja, duke u bazuar në ndryshimet në degën.

Dokumentacioni për pipeline-t e futura dhe biletën origjinale.

Navigim i përmirësuar midis pipeline-ve prind dhe të futura

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Faza e ciklit DevOps: Verifikimi

Lëvizja midis konvejereve prind dhe atyre të ngulitura më parë ishte e vështirë — nevojiteshin shumë klikime për të arritur në konvejerin e kërkuar. Po ashtu, ishte e vështirë të kuptoje se cila detyrë e kishte aktivizuar atë konvejer. Tani do të jetë shumë më e lehtë të shohësh lidhjet midis konvejereve prind dhe atyre të ngulitura.

Dokumentacioni për pipeline-t e futura dhe biletën origjinale.

Detyrat paralele të matricave tregojnë variablat përkatës në emrin e detyrës.

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Faza e ciklit DevOps: Verifikimi

Nëse keni përdorur matricën e detyrave, mund të keni vënë re se ishte e vështirë të përcaktohet se cili variabël matricor ishte përdorur për një detyrë të caktuar, pasi emrat e detyrave dukej se ishin si matrix 1/4. Në versionin 13.4 do të shihni vlerat përkatëse të variablave që janë përdorur në këtë detyrë, në vend të emrit të përgjithshëm të detyrës. Për shembull, nëse qëllimi juaj është debugimi për arkitekturën x86, detyra do të quhet matrix: debug x86.

Dokumentacioni për detyrat paralele të matricave. dhe biletën origjinale.

Përmirësime të tjera në GitLab 13.4.

Lidhja e llogarisë Atlassian.

(CORE, STARTER, PREMIUM, ULTIMATE) Faza e ciklit DevOps: Menaxho.

Përdoruesit e GitLab tani do të kenë mundësinë të lidhin llogaritë e tyre GitLab me llogarinë Atlassian Cloud. Kjo do të lejojë autentifikimin në GitLab me kredencialet e Atlassian, si dhe do të krijojë bazën për përmirësime të ardhshme në integrim. Gitlab me Jira dhe me produkte të tjera nga seria Atlassian.

Dokumentacioni për integrimin me Atlassian dhe biletën origjinale.

Eksportoni listën e të gjitha komiteteve të bashkimit

(ULTIMATE, GOLD) Faza e ciklit DevOps: Menaxho.

Organizatave që janë të fokusuar në përputhje u nevojitet një mënyrë për të treguar auditorëve një pamje gjithëpërfshirëse të komponentëve të lidhur me çdo ndryshim të caktuar në prodhim. Në kuadër të GitLab, kjo do të thotë se duhet të mbledhni gjithçka në një vend: kërkesat për bashkim, biletat, tubacionet, skanimet e sigurisë dhe të dhëna të tjera mbi komitetin. Deri tani, ju duhej ose të mbledhni manualisht këtë në GitLab, ose të konfiguroni mjetet tuaja për të mbledhur informacion, që nuk ishte shumë efektiv.

Tani, ju mund të mbledhni dhe eksportoni këto të dhëna për të përmbushur kërkesat e auditit ose për të kryer analiza të tjera. Për të eksportuar listën e të gjitha komiteteve të bashkimit për grupin aktual, ju duhet të shkoni në panelet e përputhshmërisë dhe të klikoni në butonin Lista e të gjitha komiteteve të bashkimit. Skedari i rezultuar do të përmbajë të gjithë komitetet e kërkesës për bashkim, autorin e tyre, ID-në e kërkesës së lidhur, grupin, projektin, konfirmuesit dhe informacion të tjera.

Dokumentacioni për krijimin e raportit dhe biletën origjinale.

Shkarkimi i listës dhe menaxhimi i tokeneve personale të qasjes përmes API-së

(ULTIMATE, GOLD) Faza e ciklit DevOps: Menaxho.

Menaxhimi i aksesit në hapësirën emërtuese të GitLab është një pjesë e rëndësishme e aktivitetit të përputhshmërisë. Nga parimet e privilegjeve minimale deri te ndalimi i aksesit me timer - mund të ketë disa kërkesa të lidhura me tokenet personale të qasjes në GitLab. Për ta bërë më të lehtë mbajtjen dhe menaxhimin e të gjithë këtyre akreditiveve të përdoruesve brenda hapësirës suaj emërtuese, ne ofruam mundësinë për të shkarkuar listën e të gjithë tokeneve personale të qasjes dhe opcionalisht të ndalohet aksesin përmes API-së.

Këto përmirësime në API-në e GitLab lejojnë përdoruesit të listojnë dhe të anulojnë tokent e tyre personale të aksesit, ndërsa administratorët mund të listojnë dhe të anulojnë tokenet e përdoruesve të tyre. Tani administratorët do të kenë më lehtë të shohin ata që kanë qasje në hapësirën e tyre, të marrin vendime mbi dhënien e aksesit në bazë të të dhënave të përdoruesve dhe gjithashtu të anulojnë tokenet personale të aksesit që mund të kenë qenë të komprometuar apo që tejkalojnë rregullat e kompanisë për menaxhimin e aksesit.

Dokumentacioni për tokent personale të aksesit dhe biletën origjinale.

Biletat e lidhura dhe funksionalitete të tjera tani në GitLab Core

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Faza e ciklit DevOps: Plan

Para disa muajsh shpallëm planin për të transferonim 18 funksionalitete në kodin e hapur. Duke punuar për të përmbushur këtë premtim, ne kemi bërë biletat e lidhura, eksportin e biletave në CSV dhe modin e fokusit në tavolinën e detyrave (në lokalizimin në rus të GitLab "tavolina e diskutimeve") të disponueshëm në planin Core. Kjo i referohet vetëm marrëdhënieve të tipit "lidhet me", marrëdhëniet e tipit "bllokon" dhe "bllokohet" mbeten në planet e paguara.

Dokumentacioni për biletat e lidhura dhe biletën origjinale.

Shfaqja e emrit të degës burimore në panelin anësor të kërkesës për bashkim

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Faza e ciklit DevOps: Krijimi

Gjatë shqyrtimit të ndryshimeve në kod, diskutimeve dhe komiteteve të kërkesës për bashkim, shpesh është e dëshirueshme të bëhet një checkout lokal i degës për një shqyrtim më të thellë. Megjithatë, gjetja e emrit të degës bëhet gjithnjë e më e vështirë ndërsa përshkrimi i kërkesës për bashkim shton më shumë përmbajtje, dhe është e nevojshme të rrotullohet më tej faqja.

Kemi shtuar emrin e degës në panelin anësor të kërkesës për bashkim, duke e bërë atë gjithmonë të disponueshëm dhe duke eliminuar nevojën për të rrotulluar tërë faqen. Ashtu si lidhja në kërkesën për bashkim, seksioni me degën burimore përmban një buton të përshtatshëm 'kopjo'.

Faleminderit Ethan Reesor për kontributin e jashtëzakonshëm në zhvillimin e kësaj funksionalitete!

Dokumentacioni për kërkesat për bashkim dhe biletën origjinale.

Të dhëna për praninë e skedarëve të ngritur në difet e kërkesës për bashkim

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Faza e ciklit DevOps: Krijimi

Mërgimi i kërkesave që shtojnë ndryshime në disa skedarë ndonjëherë minimizon diferencat e skedarëve të mëdhenj për të përmirësuar performancën e shfaqjes. Kur ndodh kjo, mund të kaloni përmbajtjen e një skedari gjatë rishikimit, veçanërisht në kërkesat e mërgimit me numra të mëdhenj skedarësh. Duke filluar nga versioni 13.4, kërkesat e mërgimit do të shënojnë diferencat që përmbajnë skedarë të minimizuar, kështu që nuk do të humbni këto skedarë gjatë rishikimit të kodit. Për më shumë qartësi, planifikojmë të shtojmë ndriçimin e këtyre skedarëve në rishikimin e ardhshëm. Qëndroni të informuar për azhurnimet në ticket gitlab#16047.

Dokumentacioni për skedarët e minimizuar në diferencën e kërkesës së mërgimit dhe biletën origjinale.

Paralajmërimi për praninë e skedarëve të minimizuar në diferencën e kërkesës së mërgimit

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Faza e ciklit DevOps: Krijimi

Në seksionin e diferencave të kërkesave të mërgimit, skedarët e mëdhenj minimizohen për të përmirësuar performancën. Sidoqoftë, gjatë rishikimit të kodit, disa skedarë mund të humbasin kur rishikuesi kalon përmes listës së skedarëve, pasi të gjithë skedarët e mëdhenj janë minimizuar.

Ne kemi shtuar një paralajmërim të dukshëm në krye të faqes së diferencës së kërkesës për bashkim, për të informuar përdoruesit se në këtë seksion ka një skedë të zgjatur. Kështu, ju nuk do të humbisni asnjë ndryshim në kërkesën për bashkim gjatë rishikimit.

Dokumentacioni për skedarët e minimizuar në diferencën e kërkesës së mërgimit dhe biletën origjinale.

Riparimi automatik i depozitës së klasterit Gitaly

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Faza e ciklit DevOps: Krijimi

Më parë, kur nodi kryesor i klasterit Gitaly ndalonte, depozitët në këtë nod ishin të markuara si të disponueshme vetëm për lexim. Kjo parandalonte humbjen e të dhënave në situata ku kishte ndryshime që ende nuk ishin replikuar. Kur nodi rikthehej, GitLab nuk ripërtritej automatikisht, dhe administratorët kishin nevojë të nisin manualisht procesin e sinkronizimit ose të pranonin humbjen e të dhënave. Situata të tjera si dështimi i një detyre të replikimit në nodin dytësor gjithashtu mund të çonin në depozita të vjetra ose të disponueshme vetëm për lexim. Në këtë rast, depozita mbetej e vjetruar derisa të kryhej operacioni i ardhshëm i shkruar që do të aktivizonte detyrën e replikimit.

Për të zgjidhur këtë problem Praefect tani tani planifikon një detyrë për replikimin kur ai zbulon një depo të vjetruar në një nod dhe versionin më të fundit të depozitës në një tjetër. Kjo detyrë replikimi e bën depozitën automatikisht aktuale, duke eliminuar nevojën për të rikuperuar të dhënat manualisht. Rikuperimi automatik gjithashtu siguron një rikthim të shpejtë në gjendjen e fundit për nodet dytësore nëse detyra e replikimit dështon, në vend që të pritet operacioni i ardhshëm i shkrimit. Duke qenë se shumë klastera Gitaly ruajnë një numër të madh depozitash, kjo ndjeshëm redukton kohën që administratorët dhe inxhinierët e sigurisë harxhojnë për të rikuperuar të dhënat pas një gabimi.

Për më tepër, riparimi automatik nis replikimin e depozitave në çdo nod të ri Gitaly që është shtuar në klaster, duke eliminuar punën manuale kur shtohen nodet e reja.

Dokumentacioni për rikuperimin e të dhënave Gitaly dhe biletën origjinale.

Shëno detyrën to-do si të përfunduar në faqen e dizajnit

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Faza e ciklit DevOps: Krijimi

Komunikimi efektiv në GitLab bazohet në listat e detyrave to-do. Nëse ju përmendën në një komente, është kritike të keni mundësinë të shkoni te detyra dhe ose të filloni të punoni, ose ta shënoni atë si të kryer. Po ashtu, është e rëndësishme të keni mundësinë t'i caktoni një detyrë vetes, kur keni nevojë të punoni mbi diçka ose të ktheheni tek ajo më vonë.

Më parë, nuk keni mundur të shtoni detyra ose t'i shënoni ato si të kryera gjatë punës me dizajnet. Kjo ka penguar rëndë efektivitetin e komunikimit midis ekipeve produktive, pasi detyrat to-do janë një element kritik i procesit të punës në GitLab.

Në lëshimin 13.4, dizajnet e arrijnë komentet për biletat në përdorimin e detyrave, duke e bërë punën me to më të njëtrajtshme dhe efikase.

Dokumentacioni për shtimin e detyrave për dizajnet dhe biletën origjinale.

Udhëzues i përmirësuar për zgjidhjen e problemeve për CI/CD

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Faza e ciklit DevOps: Verifikimi

Kemi përmirësuar udhëzimin për zgjidhjen e problemeve për GitLab CI/CD duke shtuar informacione të reja mbi problemet e zakonshme me të cilat mund të përballeni. Shpresojmë që dokumentacioni i përmirësuar do të jetë një burim i çmuar që do t'ju ndihmojë të konfiguroni dhe të nisni shpejt dhe lehtësisht GitLab CI/CD.

Dokumentacioni për zgjidhjen e problemeve CI/CD dhe biletën origjinale.

Mërgimet nuk bien më nga radha e mërgimit

(PREMIUM, ULTIMATE, SILVER, GOLD) Faza e ciklit DevOps: Verifikimi

Më parë, mërgimet mund të binin nga radha e mërgimit rastësisht për shkak të komenteve të vonshme. Nëse mërgimi ishte tashmë në radhë, dhe dikush shtonte një koment që krijonte një diskutim të ri të paqëruar, mërgimi konsiderohej i papërshtatshëm për mërgim dhe binte nga radha. Tani, pasi mërgimi shtohet në radhën e mërgimit, mund të shtoni komente të reja pa frikë se do të prishni procesin e mërgimit.

Dokumentacioni për radhën e mërgimit dhe biletën origjinale.

Shfaqja e vlerës së mbulimit të kodit në mërgim

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Faza e ciklit DevOps: Verifikimi

Zhvilluesit duhet të kenë mundësinë të shohin vlerën e mbulimit të kodit pas përfundimit të procesit—edhe në skenarë të komplikuar, si puna e procesit me disa detyra që duhen analizuar për të llogaritur vlerën e mbulimit. Më parë, widget-i i kërkesës për bashkim tregonte vetëm mesataren e këtyre vlerave, duke e bërë që të duhej të kalonit në faqen e detyrës dhe përsëri në kërkesën për bashkim për të marrë vlerat ndërmjetëse të mbulimit. Për të kursyer kohën tuaj dhe për t'ju liruar nga këto hapa të panevojshëm, ne bëmë që widget-i të tregojë mesataren e mbulimit, ndryshimin e saj midis degëve të synuara dhe atyre burimore, si dhe një këshillë pop-up që tregon vlerën e mbulimit për çdo detyrë, mbi të cilën është llogaritur mesatarja.

Dokumentacioni për analizimin e mbulimit të kodit dhe biletën origjinale.

Fshirja e paketave nga regjistri i paketave gjatë shikimit të grupit

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Faza e ciklit DevOps: Paketë

Regjistri i pakove GitLab është vendi për të ruajtur dhe shpërndarë pakot në formate të ndryshme. Kur projekti ose grupi juaj ka shumë paketa, ju nevojitet të identifikoni shpejt pakot e përdorura që nuk janë më të nevojshme dhe t'i hiqni ato, në mënyrë që të tjerët të mos i shkarkojnë. Ju mund të hiqni pakot nga regjistri juaj përmes API-së së pakove ose përmes ndërfaqes së përdoruesit të regjistrit të pakove. Megjithatë, deri tani nuk keni pasur mundësi të hiqni pakot gjatë shikimit të grupit përmes ndërfaqes së përdoruesit. Si rezultat, ju është dashur të hiqni pakot epaditur për secilin projekt veçmas, që ishte joefikas.

Tani mund të hiqni pakot gjatë shikimit të regjistrit të pakove të grupit. Thjesht kaloni në faqen e regjistrit të pakove të grupit, filtrojeni paketat sipas emrit dhe hiqni të gjitha ato të panevojshme.

Dokumentacioni për heqjen e pakove nga regjistri i pakove dhe biletën origjinale.

Shkallëzimi i pakove Conan deri në nivelin e projektit

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Faza e ciklit DevOps: Paketë

Mund ta përdorni repository-n Conan në GitLab për publikimin dhe shpërndarjen e varësive C/C++. Megjithatë, më parë paketat mund të shkallëzoheshin vetëm në nivel instancës, pasi emri i paketës Conan mund të përmbante maksimum 51 karaktere. Nëse do të donit të publikoni një paketë nga një nëngrup, për shembull, gitlab-org/ci-cd/package-stage/feature-testing/conan, kjo ishte pothuajse e pamundur të bëhej.

Tani mund të shkallëzoni paketat Conan në nivel projekti, duke lejuar publikimin dhe shpërndarjen e lehtë të varësive të projekteve tuaja.

Dokumentacioni për publikimin e paketave Conan dhe biletën origjinale.

Mbështetje për menaxherë të rinj paketash dhe gjuhësh për skanimin e varësive

(ULTIMATE, GOLD) Faza e ciklit DevOps: Siguro

Jemi të lumtur të shtojmë skanimin e varësive për projektet me kod në C, C++, C# dhe .Net, të cilat përdorin NuGet 4.9+ ose menaxherët e paketave Conan, në listën tonë të gjuhëve dhe framework-eve të mbështetur. Tani tani mund ta përfshini skanimin e varësive si një pjesë të fazës Secure, për të kontrolluar nëse ka dobësi të njohura në varësitë e shtuar përmes menaxherëve të paketave. Dobësitë e gjetura do të shfaqen në kërkesën tuaj të bashkimit së bashku me nivelin e rrezikshmërisë, që të dini para se të realizoni bashkimin se çfarë rreziqesh paraqet varësia e re. Ju gjithashtu mund të konfiguroni projektin tuaj që të kërkojë miratimin e kërkesës për bashkim për varësitë me dobësi me rrezikshmëri kritike (Critical), të lartë (High) ose të panjohur (Unknown).

Dokumentacioni për gjuhët dhe menaxherët e paketave të mbështetur dhe epiku origjinal.

Njoftimet kur ndryshoni cilësimin e kërkesës për bashkim në 'Bashkoni kur përfundon me sukses pipeline'

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Faza e ciklit DevOps: Lëshimi

Më parë, kur vendosnit cilësimin e kërkesës për bashkim Bashkohet kur përfundon pipeline (Merge When Pipeline Succeeds, MWPS) nuk dërgohej asnjë njoftim me email. Ju duhej të kontrollonit manualisht statusin ose të prisnit një njoftim për përfundimin e bashkimit. Në këtë version ne jemi të lumtur të prezantojmë kontributin e përdoruesit @ravishankar2kool, i cili zgjidhi këtë problem duke shtuar dërgimin automatik të njoftimeve për të gjithë ata që janë subscribed në merge request, kur rishikuesi ndërron cilësimin e shkrirjes në MWPS.

Dokumentacioni për njoftimet e ngjarjeve të merge requests dhe biletën origjinale.

Krijimi i klasterëve EKS me versionin e Kubernetes të përcaktuar nga përdoruesi

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Faza e ciklit DevOps: Konfiguro

Përdoruesit e GitLab tani mund të zgjedhin vetë versionin e Kubernetes që do të ofrohet EKS; mund të zgjidhni midis versioneve 1.14–1.17.

Dokumentacioni për shtimin e klasterëve EKS dhe biletën origjinale.

Krijimi i incidenteve si lloje ticketesh

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Faza e ciklit DevOps: Monitor

Jo çdo problem që ndodh menjëherë nxit dërgimin e njoftimeve: përdoruesit raportojnë për çështje të caktuara, ndërsa anëtarët e ekipit shqyrtojnë problemet me performancën. Tani incidentet janë një formë e ticketëve, kështu që ekipet tuaja do të jenë në gjendje t’i krijojnë ato shpejt brenda procesit të tyre të zakonshëm. Klikoni Detyrë e re nga çdo vend në GitLab, dhe në fushën Tipo zgjidhni Incident.

Dokumentacioni për krijimin manual të incidenteve dhe biletën origjinale.

Përmendjet e njoftimeve të GitLab në Markdown

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Faza e ciklit DevOps: Monitor

Ne kemi përmirësuar njoftimet GitLab duke shtuar një lloj të ri përmendjeje posaçërisht për to në versionin Markdown të GitLab, duke e bërë më të lehtë ndarjen e njoftimeve dhe përmendjen e tyre. Përdorni ^alert#1234, për të përmendur njoftimin në çdo fushë me formatim Markdown: në incidente, bileta ose kërkesa për bashkim. Kjo gjithashtu do t'ju ndihmojë të identifikoni detyrat që krijohen nga njoftimet dhe jo nga biletat ose kërkesat për bashkim.

Dokumentacioni për menaxhimin e incidenteve dhe biletën origjinale.

Shikimi i ngarkesës së njoftimeve për incidente

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Faza e ciklit DevOps: Monitor

Përshkrimi i njoftimit përmban informacion kritik për diagnostikimin e dështimeve dhe rikuperimin, dhe ky informacion duhet të jetë lehtësisht i aksesueshëm, në mënyrë që të mos keni nevojë të kaloni nga një mjet në tjetrin gjatë zgjidhjes së incidentit. Incidentet e krijuara nga njoftimet shfaqin përshkrimin e plotë të njoftimit në tab Detajet e Njoftimit.

Kërkim i avancuar 75% më i shpejtë

(STARTER, PREMIUM, ULTIMATE, BRONZE, SILVER, GOLD) Disponueshmëria

GitLab, si një aplikacion i vetëm, ka një mundësi unike për të bërë kërkimin e përmbajtjes në të gjithë procesin e punës DevOps më të shpejtë. Në GitLab 13.4, kërkimi i avancuar jep rezultate 75% më shpejt. e kufizuar në hapësira emri dhe projekte të caktuara, ashtu si në GitLab.com.

Dokumentacion për një kërkim të zgjeruar më të shpejtë dhe biletën origjinale.

Shikimi i projekteve të fshira për administratorët

(CORE, STARTER, PREMIUM, ULTIMATE) Faza e ciklit DevOps: Menaxho.

Mundësia për të vonuar fshirjen e projektit u nënshkrua në 12.6. Megjithatë, më parë nuk kishte mundësi për të parë në një vend të vetëm të gjitha projektet që prisnin fshirje. Tani administratorët e instancave të personalizuara GitLab mund të shikojnë të gjitha projektet që presin fshirjen, në një vend - së bashku me butona për rinovimin e lehtë të këtyre projekteve.

Kjo mundësi u lejon administratorëve të kontrollojnë më mirë fshirjen e projekteve, duke mbledhur të gjithë informacionin e nevojshëm në një vend dhe duke ofruar mundësinë për të anuluar veprimet e padëshiruara të fshirjes.

Faleminderit Ashesh Vidyut (@asheshvidyut7) për këtë veçori!

Dokumentacion për fshirjen e projekteve dhe biletën origjinale.

Në API është shtuar mbështetje për rregullat e shtytjes për grupin

(STARTER, PREMIUM, ULTIMATE, BRONZE, SILVER, GOLD) Faza e ciklit DevOps: Menaxho.

Më parë, rregullat e grupit për ndihmën e shtypjes mund të konfiguroheshin vetëm duke vizituar çdo grup individualisht përmes ndërfaqes së përdoruesit të GitLab dhe duke aplikuar këto rregulla. Tani mund të menaxhoni këto rregulla përmes API-së për të mbështetur mjetet tuaja të përdoruesit dhe automatizimin e GitLab.

Dokumentacioni për rregullat e shtypjes për grupin dhe biletën origjinale.

Tërheqja e tokenëve personalë të aksesit për ruajtjen e vetë-menaxhuar të kredencialeve

(ULTIMATE) Faza e ciklit DevOps: Menaxho.

Ruajta e kredencialeve ofron administratorëve informacionin e nevojshëm për të menaxhuar kredencialet e përdoruesve të instancës së tyre GitLab. Duke qenë se organizatat e orientuara ndaj përputhshmërisë ndryshojnë në ashpërsinë e rregullave të menaxhimit të kredencialeve, ne kemi shtuar një buton që lejon administratorët të tërheqin, sipas dëshirsë, tokenin e personalizuar të aksesit të përdoruesit (PAT). Tani administratorët mund të tërheqin lehtësisht PAT që mund të jenë kompromentuar. Kjo veçori është e dobishme për organizatat që kërkojnë mundësi më fleksibile për të siguruar përputhshmërinë, duke minimizuar shpërqendrimet e përdoruesve të tyre.

Dokumentacioni për ruajtjen e kredencialeve dhe biletën origjinale.

Skedari i konfigurimit për redaktuesin e faqeve statike

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Faza e ciklit DevOps: Krijimi

Në GitLab 13.4 prezantojmë një mënyrë të re për të konfiguruar redaktuesin e faqeve statike. Ndërsa skedari i konfigurimit nuk ruan dhe nuk merr asnjë parametr në këtë version, ne po vendosim bazat për konfigurimin e ardhshëm të sjelljes së redaktuesit. Në versionet e ardhshme ne do të shtojmë në skedar .gitlab/static-site-editor.yml parametra për konfigurimin adreçën bazë të faqes, mbi të cilën ruhen imazhet e ngarkuara në redaktues, mbivendosja e konfigurimeve të sintaksës Markdown dhe konfigurimeve të tjera të redaktuesit.

Dokumentacioni për konfigurimin e redaktuesit të faqeve statike dhe epiku origjinal.

Redaktimi i hyrjes së skedarit me ndihmën e redaktuesit të faqeve statike

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Faza e ciklit DevOps: Krijimi

Pjesa hyrëse (front matter) është një mënyrë fleksibile dhe e përshtatshme për të përcaktuar variabla të faqeve në skedarët e të dhënave, të destinuara për përpunim nga gjeneruesi i faqeve statike. Ajo zakonisht përdoret për të vendosur titullin e faqes, modelin e skemës ose autorin, por mund të përdoret gjithashtu për të transmetuar çdo lloj metadatosh në gjenerues gjatë renditjes së faqes në HTML. E vendosur në të gjithë pjesën e sipërme të çdo skedari të dhënash, pjesa hyrëse zakonisht formatizohet si YAML ose JSON dhe kërkon një sintaksë të qëndrueshme dhe të saktë. Përdoruesit që nuk janë të njohur me rregullat specifike të sintaksës mund të fusin mëndje aksidentalisht markup të pavlefshëm, gjë që, njëlloj, mund të shkaktojë probleme me formatimin ose madje edhe dështime në ndërtim.

Mënyra e redaktimit WYSIWYG e editorit të faqeve statike tani e heq pjesën hyrëse nga redaktori për të evituar këto gabime formatimi. Megjithatë, kjo nuk ju lejon të ndryshoni vlerat e ruajtura në këtë pjesë pa u kthyer në redaktimin në modën e kodit burimor. Në GitLab 13.4, mund të aksesoni çdo fushë dhe të redaktoni vlerën e saj në një ndërfaqe të njohur të bazuar në forma. Pasi të klikoni butonin Cilësimet (Cilësimet) do të hapet një panel ku shfaqet fusha e formës për secilin çelës të përcaktuar në fillim. Fushat plotësohen me vlerën aktuale, dhe për të redaktuar cilëndo prej tyre mjafton thjesht ta shkruani në formën në internet. Kjo redaktim i pjesës hyrëse lejon shmangien e vështirësive në sintaksë dhe ju jep kontroll të plotë mbi përmbajtjen, duke siguruar një formatim të qëndrueshëm të rezultatit përfundimtar.

Dokumentacioni për editorin e faqeve statike dhe biletën origjinale.

GitLab për Jira dhe DVCS Connector tani në Core

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Faza e ciklit DevOps: Krijimi

Për përdoruesit e Jira në GitLab: aplikacioni GitLab për Jira dhe DVCS Connector mund të paraqesin informacion rreth komiteteve dhe kërkesave për bashkim në GitLab direkt në Jira. Në kombinim me integrimin tonë të çintegruar me Jira, mund të lëvizni lehtësisht midis dy aplikacioneve gjatë punës.

Këto funksione më parë ishin të aksesueshme vetëm në planin tonë Premium, por tani janë në dispozicion për të gjithë përdoruesit!

Dokumentacioni për integrimin me Jira dhe biletën origjinale.

Votimi me shumicë për transaksionet e klasterit Gitaly (beta)

(CORE, STARTER, PREMIUM, ULTIMATE) Faza e ciklit DevOps: Krijimi

Klusteri Gitaly lejon replikimin e repositeteve Git në disa nodë "të ngrohta" Gitaly. Kjo rrit disponueshmërinë duke eliminuar pikët e vetme të dështimit. Operacionet transaksionale, të paraqitura në GitLab 13.3, shkaktojnë shpërndarjen e gjerë të ndryshimeve në të gjitha nodet Gitaly në klaster, por vetëm nodet Gitaly që votojnë për pajtimin me nodin kryesor ruajnë ndryshimet në disk. Nëse të gjitha nodet e replikës nuk arrijnë të bien dakord, vetëm një kopje e ndryshimit do të ruhet në disk, duke krijuar një pikë të vetme dështimi deri në përfundimin e replikimit asinkron.

Votimi me shumicë votash rrit qëndrueshmërinë, duke kërkuar miratimin e shumicës së node-ve (jo të gjitha) para se të ruajë ndryshimet në disk. Nëse kjo veçori e aktivizuar është e aktivizuar, regjistrimi duhet të realizohet me sukses në disa node. Node-të e paakorduar automatikisht sinkronizohen përmes replikimit asinkron me ato node që formuan kuorum.

Dokumentacioni për konfigurimin e koherencës në Gitaly dhe biletën origjinale.

Mbështetje për skemën e përdoruesit për validimin e JSON në Web IDE

(PREMIUM, ULTIMATE, SILVER, GOLD) Faza e ciklit DevOps: Krijimi

Projeketet ku njerëzit shkruajnë konfiguracione në formatin JSON ose YAML shpesh hasin probleme, pasi është e lehtë të bësh një gabim shtypi dhe të thyesh diçka. Mund të shkruash mjete kontrolli që kapin këto probleme në pipeline-in CI, por përdorimi i një skeme JSON mund të jetë e dobishme për të ofruar dokumentacion dhe sugjerime.

Pjesëmarrësit e projektit mund të përcaktojnë në depo e tyre rrugën për skemën e përdoruesit në skedarin .gitlab/.gitlab-webide.yml, i cili tregon skemën dhe rrugën për skedarët që do të kontrollohen. Kur ngarkohet një skedar i caktuar në Web IDE, do të shihet një reagim dhe kontroll shtesë që ndihmon për të krijuar skedarin.

Dokumentacioni për skemat e përdoruesve në Web IDE dhe biletën origjinale.

Kufiri i ndarjes së grafit të drejtpërdrejtë aciklik (DAG) është rritur në 50

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Faza e ciklit DevOps: Verifikimi

Nëse përdorni pipelines me graf të drejtpërdrejtë aciklik (Directed Acyclic Graph (DAG)), mund të keni vënë re se kufiri prej 10 detyrash, që një detyrë mund të tregojë në needs:, është shumë i ashpër. Në versionin 13.4, kufiri default u rrit nga 10 në 50 për të mundësuar rrjeta më komplekse të marrëdhënieve midis detyrave në pipelines tuaja.

Nëse jeni administrator i një instancë të personalizuar të GitLab, mund ta rrisni këtë kufi edhe më shumë duke konfiguruar një funksion të aktivizueshëm, megjithatë ne nuk ofrojmë mbështetje zyrtare për këtë.

Dokumentacioni për konfigurimin e needs: dhe biletën origjinale.

Përmirësuar sjellja needs për detyrat e humbura

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Faza e ciklit DevOps: Verifikimi

Në disa raste, një detyrë e humbur në pipeline mund të jetë gabimisht e konsideruar si e suksesshme për varësitë e treguara në needs, duke shkaktuar ekzekutimin e detyrave të mëpasshme, gjë që nuk duhej të ndodhte. Ky trajtim është korrigjuar në versionin 13.4, dhe needs tani trajton saktësisht rastet e detyrave të humbura.

Dokumentacioni për konfigurimin e needs dhe biletën origjinale.

Përfshini artefaktin e fundit të detyrës për të parandaluar fshirjen e tij

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Faza e ciklit DevOps: Verifikimi

GitLab tani automatikisht bllokon artefaktin e fundit të një detyre dhe ecurie të suksesshme në çdo degë aktive, kërkesë bashkimi ose etiketë për të parandaluar fshirjen e tij pas skadimit të afatit. Bën më të lehtë vendosjen e rregullave më agresive të skadimit për të pastruar artefaktet e vjetra. Kjo ndihmon në uljen e konsumit të hapësirës së diskut dhe garanton që keni gjithmonë një kopje të artefaktit të fundit nga ecuria.

Dokumentacioni mbi skadimin e artefakteve dhe biletën origjinale.

Udhëzues për CI/CD për optimizimin e ecurisë

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Faza e ciklit DevOps: Verifikimi

Optimizimi i ecurisë CI/CD mund të rrisë shpejtësinë e dorëzimit dhe të kursejë para. Ne kemi përmirësuar dokumentacionin tonë duke shtuar një udhëzues të shkurtër për të arritur maksimumin nga optimizimi i ecurive tuaja.

Dokumentacioni për përmirësimin e efikasitetit të ecurive dhe biletën origjinale.

Raporti i testimit është renditur sipas statusit të testit

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Faza e ciklit DevOps: Verifikimi

Raporti i testeve të njësi — është një mënyrë e thjeshtë për të parë rezultatet e të gjitha testeve në linjë. Megjithatë, me një numër të madh testesh, gjetja e testeve të dështuar mund të marrë shumë kohë. Problemet e tjera që e bëjnë të vështirë përdorimin e raportit përfshijnë vështirësitë në rrotullimin e të dhënave të gjata të gjurmimit dhe rrethimin e kohës në zero për testet që ekzekutohen për më pak se 1 sekondë. Tani, me parazgjedhje, raporti i testimit kur renditet vendos së pari testet e dështuar në fillim të raportit dhe pastaj rendit testet sipas kohëzgjatjes. Kjo e simplifikon gjetjen e dështimeve dhe testeve të gjata. Gjithashtu, kohëzgjatja e testeve tani shfaqet në milisekonda ose sekonda, kështu që është shumë më e lehtë për t'u lexuar dhe janë zgjidhur gjithashtu problemet e mëparshme me rrotullimin.

Dokumentacioni mbi raportet e testeve unitare dhe biletën origjinale.

Kufizimet mbi madhësinë e skedarëve të ngarkuar në regjistrin e paketave

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Faza e ciklit DevOps: Paketë

Tani ka tani kufizime mbi madhësinë e skedave të paketave që mund të ngarkohen në regjistrin e pakove GitLab. Kufizimet u shtuan për të optimizuar performancën e regjistrit të pakove dhe për të parandaluar abuzimet. Kufizimet varen nga formati i paketës. Për GitLab.com madhësitë maksimale të skedave janë:

• Conan: 250MB
• Maven: 3GB
• NPM: 300MB
• NuGet: 250MB
• PyPI: 3GB

Për instancat e përdoruesve të GitLab, vlerat e paracaktuara janë të njëjta. Megjithatë, administratori mund të përditësojë kufizimet nëpërmjet konsolës Rails.

Dokumentacioni mbi kufizimet e madhësisë së skedave dhe biletën origjinale.

Përdorni CI_JOB_TOKEN për të publikuar paketat PyPI

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Faza e ciklit DevOps: Paketë

Mund të përdorni regjistrin e GitLab PyPI për të krijuar, publikuar dhe ndarë paketa Python së bashku me kodin burimor dhe tubat CI/CD. Megjithatë, më parë nuk keni mundur të autentifikoheni në regjistrin me një variabël mjedisore të paracaktuar CI_JOB_TOKEN. Si rrjedhojë, keni pasur nevojë të përdorni kredencialet tuaja personale për të përditësuar regjistrin PyPI, ose ndoshta keni zgjedhur të mos e përdorni fare regjistrin.

Tani është bërë më e lehtë për të përdorur GitLab CI/CD për publikimin dhe instalimin e paketave PyPI me ndihmën e variablit të paracaktuar të mjedisit CI_JOB_TOKEN.

Dokumentacioni për përdorimin e GitLab CI me paketat PyPI dhe biletën origjinale.

Profillet e skanimit DAST sipas kërkesës

(ULTIMATE, GOLD) Faza e ciklit DevOps: Siguro

Për skanimin DAST sipas kërkesës, që ishte prezantuar në versionin e kaluar, u shtuan profillet e skanimit DAST. Ato zgjeruan mundësitë e konfigurimit të këtij skanimi, duke lejuar që të krijoni shpejt disa profile për të mbuluar disa lloje skanimi. Në 13.4, profili i skanimit përfshin fillimisht parametrin e skadimit të robotit kërkues, i cili përcakton se sa kohë duhet të punojë robotics DAST kur përpiqet të zbulojë të gjitha faqet e faqes që skanohet. Profili gjithashtu përfshin parametrin e skadimit të faqes qëllim, për të përcaktuar se sa kohë duhet të presë skaneri përpara se të ndërpresë skanimin, nëse faqja nuk përgjigjet me një kod statusi 200 ose 300. Ndërsa do të vazhdojmë ta përmirësojmë këtë veçori në versionet e ardhshme, do të shtohen parametrat e tjerë të konfigurimit në profilin e skanerit.

Dokumentacioni për profilin e skanimit DAST dhe biletën origjinale.

Një skedar i thjeshtë konfigurimi për ridrejtimet e GitLab Pages

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Faza e ciklit DevOps: Lëshimi

Nëse po përdorni GitLab Pages dhe dëshironi të menaxhoni më mirë ndryshimet e URL-ve, mund të keni vërejtur se menaxhimi i ridrejtimeve në faqen tuaj GitLab Pages ka qenë i pamundur. Tani, GitLab ju lejon të konfiguroni rregulla për të ridrejtimi një URL në një tjetër për faqen tuaj, duke shtuar një skedar konfigurimi në depo. Kjo funksionalitet është bërë e mundur falë kontributit të Kevin Barnett (@PopeDrFreud), Eric Eastwood tonë (@MadLittleMods) dhe ekipit të GitLab. Faleminderit të gjithëve për kontributin tuaj.

Dokumentacioni për ridrejtimet dhe biletën origjinale.

Gjendja Terraform e menaxhuar nga GitLab

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Faza e ciklit DevOps: Konfiguro

Qasja në versionet e mëparshme të gjendjes Terraform është e nevojshme si për përputhshmërinë ashtu edhe për debugging kur është e nevojshme. Mbështetje për menaxhimin e versioneve të gjendjes Terraform të menaxhuar nga GitLab, ofrohet duke filluar nga GitLab 13.4. Menaxhimi i versioneve aktivizohet automatikisht për skedarët e rinj të gjendjes Terraform. Skedarët ekzistues të gjendjes Terraform do të transportohen automatikisht në një depo me mbështetje për versionet në një lëshim të mëvonshëm.

Dokumentacioni për gjendjet Terraform të menaxhuar nga GitLab dhe biletën origjinale.

Detaje të rëndësishme për njoftimet për incidente

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Faza e ciklit DevOps: Monitor

Kur përpunoni incidente, ju nevojitet të përcaktoni lehtësisht sa kohë është hapur një njoftim dhe sa herë ka ndodhur një ngjarje. Këto detaje shpesh kanë rëndësi të përparshme për të përcaktuar ndikimin te klienti dhe për të kuptuar se çfarë duhet të bëjë ekipi juaj në radhë të parë. Në panelin e ri të detajeve për incidentet ne tregojmë kohën e fillimit të njoftimit, numrin e ngjarjeve dhe një lidhje me njoftimin origjinal. Këto informacione janë në dispozicion për incidentet që krijohen nga njoftimet.

Dokumentacioni për menaxhimin e incidenteve dhe epiku origjinal.

Vendosja dhe modifikimi i parametrave të seriousnessit të incidentit

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Faza e ciklit DevOps: Monitor

Parametri "seriousness i incidentit" lejon profesionistët e reagimit dhe palët e interesuara të përcaktojnë pasojat e një ndalese të punës, si dhe metodat dhe urgjencën e reagimit. Ndërsa ekipi juaj ndan rezultatet gjatë zgjidhjes së incidentit dhe rikthen funksionimin, ata mund të modifikojnë këtë parameter. Tani mund të editoni seriousness-in e incidentit në panelin anësor të djathtë të faqes "Detajet e Incidentit", dhe shkalla e seriousnessit tregohet në listën e incidenteve.

Dokumentacioni për menaxhimin e incidenteve dhe biletën origjinale.

Krijimi, redaktimi dhe fshirja e rregullave të sigurisë së rrjetit për enët

(ULTIMATE, GOLD) Faza e ciklit DevOps: Mbrojtje

Ky përmirësim i redaktorit të rregullave të sigurisë së rrjetit për enët lejon përdoruesit të krijojnë, redaktojnë dhe fshijnë rregullat e tyre drejtpërdrejt nga ndërfaqja e përdoruesit të GitLab. Mundësitë e redaktorit përfshijnë një modalitet .yaml për përdoruesit e avancuar dhe një redaktor rregullash me një ndërfaqe intuitive për ata që nuk janë të njohur me rregullat e rrjetit. Mund të gjeni mundësi të reja për menaxhimin e rregullave në seksionin Siguria dhe përputhshmëria > Menaxhimi i kërcënimeve > Rregullat (Security & Compliance > Threat Management > Policies).

Dokumentacioni i redaktorit të rregullave të rrjetit dhe epiku origjinal.

Mbështetje për ruajtjen e objekteve blob në Azure

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Disponueshmëria

Të dy GitLab dhe GitLab Runner tani mbështesin ruajtjen e objekteve blob në Azure, e cila lehtëson ekzekutimin e shërbimeve GitLab në Azure.

Instancat e GitLab mbështesin Azure për të gjitha llojet e ruajtjes së objekteve, përfshirë skedarët LFS, artikujt CI dhe kopje rezervë. Për të konfiguruar ruajtjen e objekteve blob në Azure, ndiqni udhëzimet e instalimit Omnibus ose Helm chart.

Përpunuesit e detyrave të GitLab gjithashtu mbështesin Azure për ruajtjen e caches të shpërndara. Ruajza Azure mund të konfigurohet përmes seksionit [runners.cache.azure].

Dokumentacioni për përdorimin e ruajzës BLOB të Azure dhe biletën origjinale.

Paketat Omnibus ARM64 për Ubuntu dhe OpenSUSE

(CORE, STARTER, PREMIUM, ULTIMATE) Disponueshmëria

Si përgjigje ndaj kërkesës në rritje për mbështetje për ekzekutimin e GitLab në arkitekturën 64-bit ARM, jemi të lumtur të njoftojmë disponueshmërinë e paketës zyrtare ARM64 Ubuntu 20.04 Omnibus. Faleminderit shumë Zitai Chen dhe Guillaume Gardet për kontributin e tyre të jashtëzakonshëm—kërkesat e tyre për shkëmbim luajtën një rol kyç në këtë!

Për të shkarkuar dhe instaluar paketën për Ubuntu 20.04, vizitoni faqen tonë të instalimit dhe zgjidhni Ubuntu.

Dokumentacioni për paketat ARM64 dhe biletën origjinale.

Mbështetje për autentikimin me karta inteligjente për diagramin GitLab Helm

(PREMIUM, ULTIMATE) Disponueshmëria

Kartat inteligjente, siç janë kartat e qasjes së përbashkët (CAC), tani mund të përdoren për autentikimin në instancën GitLab, e cila është vendosur nëpërmjet diagramit Helm. Kartat inteligjente autentikohen në bazën e të dhënave lokale duke përdorur certifikatat X.509. Kështu, mbështetje për kartat inteligjente me diagramin Helm tani është në përputhje me mbështetje për kartat inteligjente, të disponueshme në vendosjet Omnibus.

Dokumentacioni për konfigurimet e autentikimit me karta inteligjente dhe biletën origjinale.

Të dhënat e plota për azhurnimet dhe udhëzimet për instalim mund të lexohen në postimin origjinal në anglisht: GitLab 13.4 u publikua me Vault për variablat CI dhe Agjentin Kubernetes.

Përkthimi nga anglishtja u realizua nga cattidourden, maryartkey, ainoneko dhe rishavant.

Burimi: habr.com