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

Doli 13.4 me depo HashiCorp për variablat CI, Agentin Kubernetes dhe qendrën e sigurisë, së bashku me veçori të ndërrueshme në Starter.

Në GitLab, ne gjithmonë mendojmë se si t'i ndihmojmë përdoruesit të reduktojnë rreziqet, të rrisin efikasitetin dhe shpejtësinë e dorëzimit në platformën tuaj të preferuar. Këtë muaj, ne kemi shtuar disa risitë të dobishme që zgjasin mundësitë e sigurisë, reduktojnë numrin e vulnerabiliteteve, rrisin efikasitetin, thjeshtojnë punën me GitLab dhe ndihmojnë ekipin tuaj të dorëzojë veçori edhe më shpejt. Shpresojmë se veçoritë kryesore të lëshimit do t'ju ndihmojnë, po ashtu. 53 veçori të tjera të reja., të shtuara në këtë lëshim.

Mundësi të zgjeruara të sigurisë.

Ne përpiqemi të shtojmë disa veçori të reja në GitLab DevSecOps çdo muaj dhe ky lëshim nuk është përjashtim. Çelësat sekretë nga depoja HashiCorp tani mund të përdoren në detyrat CI/CD. në kuadër të ndërtimit dhe shpërndarjes. Për më tepër, organizatat që duan të mbajnë ndarjen e detyrave për shpërndarjen e kodit tani mund të shtojnë përdoruesit me akses Reporter rol Deployer.Ky rol është në përputhje me parimin e privilegjeve minime të aksesit dhe do të lejojë miratimin e kërkesave për bashkimin (në lokalizimin në gjuhën shqipe të GitLab "kërkesat për bashkim") dhe shpërndarjen e kodit në mjedise të mbrojtura, pa ofruar akses për modifikimin e vetë kodit.

Një tjetër mënyrë për të reduktuar rreziqet është përdorimi i ri GitLab Kubernetes Agent.Specialistët e operacioneve mund të shpërndajnë klasterë Kubernetes nga GitLab pa pasur nevojë të hapin aksesin në klasterin e 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 të GitLab të Terraformit për mbështetje në përputhjen me kërkesat dhe lehtësinë në debugim. Dhe më në fund, paneli i sigurisë në instancë është shndërruar në qendrën e sigurisë të GitLab me raporte për vulnerabilitetet dhe cilësimet e sigurisë.

Puna më e lehtë dhe efikase me GitLab.

Ne përmirësuam kërkimin tonë global, duke i shtuar navigimin e shpejtë nga barra e kërkimit, që lejon kalimin lehtë në biletat e fundit, grupe, projekte, cilësime dhe seksione ndihme. Ne jemi të lumtur të njoftojmë se në GitLab Pages kanë dalë ridrejtimet. për të redirigjuar faqe dhe katalogë të veçantë brenda uebsite-it, duke lejuar përdoruesit të zhvillojnë faqet e tyre më efektivisht. Dhe për ata që dëshirojnë të marrin më shumë informacione në lidhje me zhvillimin, kjo lëshim lejon të menaxhojë qindra projekte të mbështetura nga zhvillimet nga paneli i mjetit të ambientit!

Depozita me burim të hapur

Ne prezantojmë shfaqjen e mbulimit të kodit në diferencat e kërkesave për bashkim, e cila e shtoi MVP i këtij muaji, Fabio Huser. Shënimet mbi mbulimin e testeve të nj-unit për kodin e ndryshuar i japin zhvilluesve një pamje gjithëpërfshirëse mbi mbulimin e kodit gjatë rishikimit; këto informacione ndihmojnë në acelerimin e rishikimit dhe reduktimin e kohës për bashkimin dhe zhvillimin e kodit të ri. Gjithashtu ne transferuam flamujt e veçorive (feature flags) në Starter dhe planifikojmë t'i transferojmë në Core në lëshimin 13.5.

Dhe kjo është vetëm fillimi!

Si zakonisht, në përmbledhjen e përgjithshme ka shumë pak hapësirë, dhe ka shumë veçori të shkëlqyera në lëshimin 13.4. Ja disa të tjera:

• Shikoni listën e tokeneve personale të aksesit dhe anuloni ato përmes API
• Anuloni tokene personale të aksesit për ruajtjen e të dhënave të vetë-stërvitura
• Shënoni të tamamtuarat to-do në faqen e dizajnit
• Pipeline të ngulitura tani mund të sjellin pipelinë e tyre të ngulitur
• Mbështetje për autentikimin përmes kartave inteligjente për Helm chart GitLab.

Nëse dëshironi të dini përpara se çfarë ju pret në lëshimin e ardhshëm shikoni video-n tonë për lëshimin 13.5.

Shikoni webin tonë “Resiliency In Challenging Times”.

MVP këtij muaji — Fabio Huser

Fabio kontribuoi në mënyrë të konsiderueshme Heqja e komandave të vjetra GitLab Runner Helper në shfaqjen e mbulimit të kodit në diferencat e kërkesave për bashkim — një veçori që është pritur shumë gjatë në komunitetin GitLab. Ky është një kontribut vërtet i rëndësishëm me ndryshime jo triviale që kërkuan bashkëpunim konstant me anëtarët e ekipit të GitLab dhe preku shumë fusha të projektit, si UX, frontend dhe backend.

Veçoritë kryesore të lëshimit GitLab 13.4

Përdorni çelësat 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 kaluar çelësa në detyrat CI me ndihmën e përpunuesit të detyrave GitLab (GitLab runner). Tani ne po zgjerim autentikimin me JWT, duke shtuar sintaksën e re secrets në skedarin .gitlab-ci.yml. Kjo do të lehtësojë konfigurimin dhe përdorimin e depozitës HashiCorp me GitLab.

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

Prezantojmë Agjent GitLab Kubernetes

(PREMIUM, ULTIMATE) Faza e ciklit DevOps: Konfiguro

Integrimi i GitLab me Kubernetes ka bërë prej kohësh të mundur vendosjen në klasterë Kubernetes pa nevojën për konfigurim manual. Shumë përdorues e kanë çmuar lehtësinë e përdorimit të këtij kombinimi, ndërsa të tjerët kanë hasur 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ë nga pikëpamjet e sigurisë, përputhshmërisë ose rregullave. Për të tejkaluar këto kufizime, përdoruesit duhej të krijonin mjetet e tyre mbi GitLab, përndryshe ata nuk do të ishin në gjendje ta përdorin këtë mundësi.

Sot ne paraqesim Agjentin GitLab Kubernetes — një mënyrë të re për të vendosur në klasterët Kubernetes. Agjenti funksionon brenda klasterit tuaj, kështu që nuk do t'ju nevojitet ta hapni atë për të gjithë internetin. Agjenti koordinon vendosjen duke kërkuar ndryshime të reja nga GitLab, në vend që GitLab të dërgonte përditësime në klaster. Pavarësisht nga metoda e GitOps që përdorni, GitLab do t'ju përshtatet.

Ju lutemi, vini re se ky është versioni i parë i agjentit. Në këtë moment, ne kemi fokusuar Agjentin GitLab Kubernetes në konfigurimin dhe menaxhimin e vendosjes përmes kodit. Disa funksione ekzistuese të integrimit të Kubernetes, si tablotë e vendosjes dhe aplikacionet e menaxhuara nga GitLab, për momentin nuk mbështeten. Ne supozojmë, se këto mundësi do të shtohen në agjent në versionet e ardhshme, si dhe integrime të reja fokusuar në sigurinë dhe përputhshmërinë.

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

Ofroni përdoruesve të drejta për vendosje pa qasje 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ë përgjegjësitë në ekipin tuaj mes atyre që janë përgjegjës për zhvillimin dhe atyre që janë përgjegjës për vendosjen. Me versionin e GitLab 13.4, mund të jepni autorizimin për miratimin e kërkesave të bashkimit për vendosje, si dhe për vendosjen reale të kodit për njerëzit që nuk shkruajnë kodin, duke mos u dhënë atyre të drejtat e qasjes si maintainer (në lokalizimin në gjuhën shqipe të GitLab “mbikëqyrës”).

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

Qendra e sigurisë

(ULTIMATE, GOLD) Faza e ciklit DevOps: Siguria

Më parë, menaxhimi i dobësive në nivelin e instancës ishte i kufizuar si në funksionalitet ashtu edhe në fleksibilitet. Interfaci përfaqësonte një faqe të vetme që bashkonte detajet e dobësive, grafikët e metrikave 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ë sigurimit.

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

Pjesa speciale për raportin e dobësive tani ka më shumë hapësirë për të treguar detaje të rëndësishme. Këtu janë mbledhur dobësitë që aktualisht janë në listën e dobësive të projektit. Shkarkimi i widgetëve me metrikat e dobësive në një seksion të veçantë krijon një panel menaxhimi sigurie të rehatshëm. Tani është një kanavacë për vizualizime të ardhshme — jo vetëm për menaxhimin e dobësive, por edhe për çdo metrikë që lidhet 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ë nivelin e instancës, jo vetëm për menaxhimin e dobësive.

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

Funksionalitetet e mundshme tani në GitLab Starter

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

Në GitLab 11.4 u lëshua kënga e parë e funksionaliteteve të mundshme. Në 12.2 ne e prezantuam strategjinë për to përqindja e përdoruesve dhe nga ID-të e përdoruesve, ndërsa 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 angazhimin për të transferuar 18 funksionalitete në kodin e hapur. Në këtë lëshim përfunduam transferimin e funksionaliteteve të mundshme në planin Starter dhe do të vazhdojmë transferimin e tyre në Core me GitLab 13.5. Ne 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.

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

Navigimi i shpejtë nga shiritin e kërkimit

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

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

Me panelin e kërkimit global, mund të kaloni shpejt në tiketët, grupet, projektet, konfigurimet dhe seksionet e ndihmës më të fundit. Madje mund të përdorni çelësin e shpejtë /, për të zhvendosur kursorin në panelin e kërkimit, për të lundruar edhe më efektivisht në GitLab!

Dokumentacioni për plotësimin automatik në kërkimin dhe biletën origjinale.

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

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

Gjatë rishikimit të një kërkese për bashkim, mund të jetë e vështirë të përcaktoni nëse kodi i ndryshuar është mbuluar me teste njësie. 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ë konfirmojnë kërkesën për bashkim. Kjo mund të sjellë një qasje të paorganizuar në shkruarjen e testeve, e cila në të vërtetë nuk do të përmirësojë cilësinë e kodit ose mbulimin e tij me teste.

Tani, kur shikoni diferencën e kërkesës për bashkim, do të shihni një paraqitje vizuale të mbulimit të kodit. Shënimet e reja do të lejojnë të kuptoni shpejt nëse kodi i ndryshuar është mbuluar me një test njësie, gjë që do të ndihmojë në përshpejtimin e rishikimit të kodit dhe kohës së bashkimit dhe shpërndarjes së kodit të ri.

anonim kommentatorit Fabio Huser dhe Siemens për këtë funksionalitet!

Dokumentacioni për paraqitjen e mbulimit të kodit me teste dhe biletën origjinale.

Më shumë ambiente dhe projekte në panelin e ambienteve

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

Që nga lëshimi i GitLab 12.5, me panelin e ambienteve keni qenë në gjendje të ndihmoni në gjendjen e ambienteve, por jo më shumë se shtatë ambiente në tre projekte. 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ë menaxhoni dhe mbani ambientet tuaja në shkallë të madhe. Tani mund të shihni më shumë ambiente në më shumë projekte.

Dokumentacioni për panellin e ambienteve dhe biletën origjinale.

GitLab ka pranuar menaxhimin e ofruesit GitLab Terraform

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

Së fundmi ne morrën të drejtat e mbajtësve në ofruesin GitLab Terraform dhe planifikojmë për ta përmirësuar në lëshimet e ardhshme.Në muajin e fundit, kemi pranuar 21 kërkesa për bashkim dhe kemi mbyllur 31 tikete, duke përfshirë disa gabime të vjetra dhe funksionalitete që mungonin, si mbështetje për klasterët e instancave.Mund të merrni më shumë informacion 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 me specifikimet OpenAPI ose një skedë HAR

(ULTIMATE, GOLD) Faza e ciklit DevOps: Siguria

Testimi i fuzzing-ut të API është një mënyrë e shkëlqyer për të identifikuar gabimet dhe dobësitë në aplikacionet tuaja web dhe API-të që skanera dhe metoda të tjera të testimit mund t'i humbasin.

Testimi i fuzzing-ut të API në GitLab lejon ofrimin e specifikimit OpenAPI v2 ose skedari HAR të aplikacionit tuaj, dhe pastaj automatikisht gjeneron të dhëna hyrëse të rastësishme të destinuara për të provuar rastet kufitare dhe për të identifikuar gabimet. Rezultat e menjëhershme shfaqen brenda konvjerit tuaj.

Kjo është lëshimi ynë i parë i testimit të fuzzing-ut për API dhe do të na pëlqente të dinim çfarë mendoni. Për testimin e fuzzing-ut kemi në plan akoma shumë ide, të cilat do të bazohen në këtë lëshim të veçorisë.

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

Pamja e re e grafikëve në panelin e metrikeve

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

Më parë, krijimi i grafikëve në panelin e metrikeve në GitLab ishte një detyrë e komplikuar. Pasi të kishit krijuar një metrikë në skedarin YAML të panelit, duhet të bënit ndryshime në master, pa pasur mundësinë të kontrolloni se si funksiononte grafiku i sapo krijuar. Duke filluar nga ky lëshim mund të parashikoni ndryshimet në kohë reale ndërsa krijoni grafikun, duke marrë një pamje të rezultatit përpara se të dërgoni ndryshimet në skedarin YAML të panelit.

Dokumentacioni për shtimin e grafikëve të rinj në panel dhe biletën origjinale.

Të dhënat mbi mbulimin e kodit nga testet në të gjitha projektet e grupit

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

Kur menaxhoni një numër të madh projektesh në GitLab, ju nevojitet një burim i vetëm informacioni për të kuptuar si ndryshon mbulimi i kodit me kalimin e kohës në të gjithë projektet. Më parë, paraqitja e këtyre informacionit kërkonte shumë punë të lodhshme dhe manuale: duhej të shkarkonit të dhënat e mbulimit të kodit nga testet nga çdo projekt dhe t'i bashkoni ato në një tabelë.

Në lëshimin 13.4, u bë e mundur mbledhja e lehtë dhe e shpejtë në .csv një skedar të gjitha të dhënat e mbulimit të kodit për të gjithë projektet e grupit ose për një mostrë projektesh. Kjo veçori është një MVC, dhe do të pasojë mundësia për të krijuar një grafik të mbulimit mesatar me kalimin e kohës.

Dokumentacioni për analizën e repozitoreve 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: Siguria

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

Tani aktualisht mund të vlerësoni të gjitha mundësitë e testimit me fuzz në aplikacionet tuaja në Java, Rust dhe Swift dhe të gjeni gabimet dhe vakantet që metodologjitë e tjera të skanimit dhe testimit mund të humbasin.

Dokumentacioni për gjuhët e mbështetura për testimin me fuzz dhe epiku origjinal.

Njoftimet në faqen kryesore të ambientit

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

Faqja e ambienteve tregon gjendjen e përgjithshme të ambienteve tuaja. Në këtë version, ne përmirësuam këtë faqe duke shtuar shfaqjen e njoftimeve. Njoftimet e nxitura së bashku me statusin e ambienteve tuaja do t'ju ndihmojnë të merrni masa më shpejt për të zgjidhur situatat e paraqitura.

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

Kanavacë të ndërlikuara tani mund të nisin kanavacë të tyre të ndërlikuara

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

Duke përdorur kanavacë të ndërlikuara, tani është e mundur të nisni kanavacë të reja brenda kanavacave fëmijë. Një nivel shtesë thellësie mund të jetë i dobishëm nëse keni nevojë për fleksibilitet për të gjeneruar një numër variabël kanavacash.

Më parë, duke përdorur kanavacë të ndërlikuara, çdo kanavacë fëmijë kërkonte një detyrë-aktivizues, të vendosur manualisht në kanavacën prind. Tani mund të krijoni kanavacë të ndërlikuara, të cilat do të nisin dinamikisht çdo numër të ri të kanavacave të ndërlikuara. Për shembull, nëse keni një monorepozitor, mund të krijoni dinamikisht kanavacën e parë të ndërlikuar, e cila vetë do të krijojë numrin e nevojshëm të kanavacave të reja, në bazë të ndryshimeve në degë.

Dokumentacioni për kanavacat e ndërlikuara dhe biletën origjinale.

Navigimi më i përmirësuar midis kanavacave prind dhe të ndërlikuara

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

Të lëvizni midis kanavacave prind dhe të ndërlikuara më parë ishte jo shumë e lehtë — kërkonte shumë klikime për të arritur në kanavacën e kërkuar. Po ashtu ishte e vështirë të kuptoje se cila detyrë e kishte aktivizuar këtë kanavacë. Tani do të jetë shumë më e lehtë të shihni lidhjet midis kanavacave prind dhe të ndërlikuara.

Dokumentacioni për kanavacat e ndërlikuara dhe biletën origjinale.

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

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

Nëse keni përdorur matricën e detyrave, mund të keni vënë re se ishte e vështirë të përcaktohej se cili variabël i matricës ishte përdorur për një detyrë të caktuar, pasi emrat e detyrave dukeshin si matrix 1/4. Në lëshimin 13.4 do të shihni vlera relevante 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, atëherë 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ë mund të lidhin llogaritë e tyre GitLab me llogarinë Atlassian Cloud. Kjo do të mundësojë autentifikimin në GitLab me kredencialet e Atlassian, si dhe do të krijojë bazat 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.

Eksportimi i listës së të gjitha komiteve të bashkimeve

(ULTIMATE, GOLD) Faza e ciklit DevOps: Menaxho

Organizatat që synojnë të respektojnë kërkesat kanë nevojë për një mënyrë për t'u treguar auditorëve një pamje të plotë të komponimeve të lidhura me çdo ndryshim të caktuar në prodhim. Brenda GitLab, kjo do të thotë se duhet të mbledhim në një vend të vetëm gjithçka: kërkesat e bashkimit, ticketat, tubacionet, skanimet e sigurisë dhe të dhëna të tjera rreth komitit. Deri tani, ju keni qenë të detyruar ose ta mbledhni atë manualisht në GitLab, ose të konfiguroni mjetet tuaja për mbledhjen e informacionit, që ka qenë jo shumë efikase.

Tani ju mund të mblidhni dhe eksportoni këto të dhëna në mënyrë programore për të përmbushur kërkesat e auditit ose për të kryer analizat e tjera. Për të eksportuar listën e të gjitha komiteve të bashkimeve për grupin aktual, ju duhet të shkoni te paneli i përputhshmërisë dhe të klikoni në butonin Lista e të gjitha komiteteve të bashkimeve. Skedari i rezultuar do të përmbajë të gjitha komitetet e kërkesës për bashkim, autorin e tyre, ID-në e kërkesës lidhëse, grupin, projektin, miratuesit dhe informacion të tjetër.

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

Shfaqja e listës dhe menaxhimi i tokeneve personale të accesit përmes API

(ULTIMATE, GOLD) Faza e ciklit DevOps: Menaxho

Menaxhimi i aksesit në hapësirën e emrave GitLab është një pjesë e rëndësishme e aktivitetit për përputhjen me kërkesat. Nga parimet e privilegjeve minimale deri në çaktivizimin e aksesit sipas orarit — mund të ketë disa kërkesa që lidhen me tokenet personale të aksesit në GitLab. Për ta bërë më të lehtë mbështetje dhe menaxhimin e këtyre kredencialeve të përdoruesve në hapësirën tuaj, ne kemi ofruar mundësinë për të shfaqur listën e të gjitha tokeneve personale të aksesit dhe opsionalisht ndalimi i aksesit nëpërmjet API.

Këto përmirësime në API GitLab u japin përdoruesve mundësinë për të nxjerrë listën dhe për të anuluar tokenet e tyre personale të aksesit, ndërsa administratorëve u mundësojnë të nxjerrin listën dhe të anulojnë tokenet e përdoruesve të tyre. Tani administratorët do të kenë më lehtë të shohin ata që kanë akses në emrin e tyre të hapësirës, të marrin vendime mbi ofrimin 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 ose që kalojnë kufijtë e politikave të menaxhimit të aksesit të kompanisë.

Dokumentacioni mbi tokenet personale të aksesit dhe biletën origjinale.

Tiketa të lidhura dhe funksione të tjera tani në GitLab Core

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

Disa muaj më parë shpallëm planin për transferimin e 18 funksioneve në kodin e hapur. Duke punuar për të përmbushur këtë premtim, ne bëmë tiketa të lidhura, eksportimin e tiketeve në CSV dhe regjimi i fokusit në tabelën e detyrave (në lokalizimin në rusë të GitLab, "tabela e diskutimeve") të disponueshme 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 me pagesë.

Dokumentacioni mbi tiketat e lidhura dhe biletën origjinale.

Shfaqja e emrit të degës origjinale në anën e panelit të kërkesës për bashkim

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

Gjatë shqyrtimit të ndryshimeve të kodit, diskutimeve dhe komiteteve të kërkesës për bashkim, shpesh është e dëshirueshme të bëni një checkout lokal të degës për një shqyrtim më të thellë. Sidoqoftë, gjetja e emrit të degës po bëhet gjithnjë e më e vështirë ndërsa përmbajtja në përshkrimin e kërkesës për bashkim rritet, dhe duhet të shfletoni më tej faqen.

Ne shtuam emrin e degës në anën e panelit të kërkesës për bashkim, duke e bërë atë të disponueshëm në çdo kohë dhe duke eliminuar nevojën për të shfletuar të gjithë faqen. Ashtu siç është lidhja me kërkesën për bashkim, seksioni me degën origjinale përmban një buton të rehatshëm 'kopa'.

anonim kommentatorit Ethan Reesor për kontributin e tij të madh në zhvillimin e kësaj funksioni!

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

Shënimi i pranishëm të skedarëve të palosur në dallimet e kërkesës për bashkim

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

Mërg-requests që shtojnë ndryshime në disa skedarë, herë pas here përmbledhin ndryshimet e skedarëve të mëdhenj për të përmirësuar performancën e shfaqjes. Kur kjo ndodh, mund të kaloni rastësisht një skedar gjatë rishikimit, veçanërisht në mërg-requests me numër të madh skedarësh. Duke filluar nga versioni 13.4, mërg-requests do të shënojnë ndryshimet që përmbajnë skedarë të përmbledhur, kështu që nuk do të kaloni këta skedarë gjatë procesit të rishikimit të kodit. Për më shumë qartësi, planifikojmë të shtojmë ndriçimin e këtyre skedarëve në versionin e ardhshëm. Rrini të informuar për azhurnimet në ticket gitlab#16047.

Dokumentacioni për skedarët e përmbledhur në ndryshimin e mërg-requests dhe biletën origjinale.

Kujtesë për praninë e skedarëve të përmbledhur në ndryshimin e mërg-requests

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

Në seksionin me ndryshimet e mërg-requests, skedarët e mëdhenj përmblidhen për të rritur performancën. Megjithatë, gjatë rishikimit të kodit disa skedarë mund të kalohen, kur rishikuesi shfleton listën e skedarëve, pasi të gjitha skedarët e mëdhenj janë të përmbledhur.

Ne kemi shtuar një paralajmërim të dukshëm në krye të faqeve të ndryshimit të mërg-requests për të informuar përdoruesit se në këtë seksion ka një skedar të përmbledhur. Kështu, nuk do të kaloni asnjë ndryshim në mërg-requests gjatë rishikimit.

Dokumentacioni për skedarët e përmbledhur në ndryshimin e mërg-requests dhe biletën origjinale.

Rivendosja automatike e depozitës së klasterit Gitaly

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

Më parë, kur nodi kryesor i klasterit Gitaly ndalej, depozitat në këtë nod ishin shënuar si të disponueshme vetëm për lexim. Kjo parandalonte humbjen e të dhënave në situata kur në nod kishte ndryshime që ende nuk ishin replikuar. Kur nodi ri u lidh, GitLab nuk rivendosej automatikisht dhe administratorët duhej të nisnin manualisht procesin e sinkronizimit ose të pranonin humbjen e të dhënave. Situata të tjera, të tilla si dështimi i përfundimit të një detyre replikimi në nodin dytësor, gjithashtu mund të çonin në krijimin e depozitave të vjetra ose të disponueshme vetëm për lexim. Në këtë rast, depozita mbetej e vjetër derisa të kryhej operacioni i ardhshëm i shkruar që do të niste detyrën e replikimit.

Për të adresuar këtë problem Praefect Tani plani tani planifikon një detyrë replikimi, kur ai zbulon një depo të vjetruar në një nod dhe versionin më të fundit të depozitës në një nod tjetër. Kjo detyrë replikimi e bën automatikisht depozitat aktuale, çka eliminojnë nevojën për të rikuperuar të dhënat manualisht. Rikuperimi automatik gjithashtu siguron rikthimin e shpejtë në gjendjen e përditësuar të nodëve të dyta, nëse detyra e replikimit dështojnë, në vend që të priten operacione të ardhshme të shkrimit. Duke pasur parasysh se shumë klasterë Gitaly mbajnë një numër të madh depozitash, kjo ndihmon ndjeshëm në uljen e kohës që administratorët dhe inxhinierët e sigurisë kalojnë për të rikuperuar të dhënat pas një dështimi.

Për më tepër, riparimi automatik nis replikimin e depozitave në çdo nod të ri Gitaly që i shtohet klasterit, çka eliminojnë punën manuale kur shtoni nodë të re.

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

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

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

Komunikimi efikas në GitLab bazohet në listat e detyrave to-do. Nëse je përmendur në një koment, është jashtëzakonisht e rëndësishme të kesh mundësinë për të kaluar te detyra dhe ose të fillosh të bësh diçka, ose ta shënosh atë si të përfunduar. Gjithashtu, është e rëndësishme të kesh mundësinë për t'i caktuar vetes një detyrë kur duhet të punosh mbi diçka ose të kthehesh në të më vonë.

Më parë nuk ishte e mundur të shtonit detyra ose t'i shënoni ato si të përfunduar kur punonit me dizajne. Kjo e prishte rëndësisht efikasitetin e komunikimit mes ekipeve të produkteve, pasi detyrat to-do janë një element kritik i procesit të punës në GitLab.

Në versionin 13.4, dizajnet arrijnë komentet për tiket që përdorin detyrat, çka e bën punën me to më të qartë dhe efektive.

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

Udhëzime të përmirësuara për zgjidhjen e problemeve për CI/CD

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

Ne kemi përmirësuar udhëzimet për zgjidhjen e problemeve për GitLab CI/CD, duke shtuar informacion shtesë rreth problemeve të zakonshme që mund të hasni. Shpresojmë që dokumentacioni i përmirësuar të jetë një burim i vlefshëm që do t'ju ndihmojë të konfiguroni dhe të filloni shpejt dhe lehtësisht GitLab CI/CD.

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

Mënyrat e bashkimit nuk bllokohen më nga radha e bashkimit

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

Më parë, mënyrat e bashkimit mund të ishin bllokuar nga radha e bashkimit rastësisht për shkak të komenteve të vonshme. Nëse një mënyrë bashkimi ishte tashmë në radhë, dhe dikush shtonte një koment që krijonte një diskutim të ri të pazgjidhur, mënyra bashkimi konsiderohej e papërshtatshme për bashkim dhe dilte nga radhë. Tani, pasi që mënyra bashkimi shtohet në radha, mund të shtoni komente të reja pa frikën e ndërprerjes së procesit të bashkimit.

Dokumentacioni i radhës së bashkimit dhe biletën origjinale.

Shfaqja e vlerës së mbulimit të kodit në mënyrën e bashkimit për detyrë

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

Zhvilluesit duhet të kenë mundësinë të shohin vlerën e mbulimit të kodit pas përfundimit të pipeline-it — madje edhe në skenarë të komplikuar siç është punimi i pipeline-it me disa detyra që duhet të analizohen për të llogaritur vlerën e mbulimit. Më parë, widget-i i mënyrës së bashkimit tregonte vetëm mesataren e këtyre vlerave, që do të thoshte se duhej të shkonit në faqen e detyrës dhe prapa tek mënyra bashkimi 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ë tepërt, ne kemi bërë që widget-i të shfaqë mesataren e mbulimit, ndryshimin e tij midis degës së synuar dhe asaj origjinale dhe një këshillë që tregon vlerën e mbulimit për çdo detyrë, mbi të cilën është llogaritur mesatara.

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

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

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

Regjistri i pacjeve të GitLab është vendi për ruajtjen dhe shpërndarjen e pacjeve në formate të ndryshme. Kur në projektin tuaj ose grupin tuaj ka shumë paketa, ju nevojitet të identifikoni shpejt paketat e papërdorura dhe t'i fshini ato, që të mos i shkarkojnë njerëzit. Ju mund të fshini paketat nga regjistri juaj përmes API-së së pacjeve ose përmes ndërfaqes së përdoruesit të regjistrit të pacjeve. Megjithatë, deri tani nuk keni mundur të fshini paketat kur shikoni grupin përmes ndërfaqes së përdoruesit. Si rezultat, ju keni pasur nevojë të fshini paketat e tepërta veç e veç për çdo projekt, që ishte e papërshtatshme.

Tani mund të fshini paketat kur shikoni regjistrin e pacjeve të grupit. Thjesht shkoni në faqen e regjistrit të pacjeve të grupit, filtroni paketat sipas emrit dhe fshini të gjitha ato të padëshiruara.

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

Shkallëzimi i pakove Conan në nivel projekti

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

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

Tani mund të shkallëzoni pakot Conan në nivel projekti, duke lejuar një publikim dhe shpërndarje të lehtë të varësive të projekteve tuaja.

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

Mbështetje për menaxherët e rinj të pakove dhe gjuhëve për skanimin e varësive

(ULTIMATE, GOLD) Faza e ciklit DevOps: Siguria

Jemi të gëzuar të shtojmë skanimin e varësive për projekte me kod në C, C++, C# dhe .Net, që përdorin NuGet 4.9+ ose menaxherët e pakove Conan në listën tonë gjuhëve dhe kornizave të mbështetura. Tani ju mund të përfshini skanimin e varësive si pjesë e fazës Secure, për të kontrolluar varësitë për dobësitë e njohura, të shtuara përmes menaxherëve të pakove. Dobësitë e gjetura do të shfaqen në kërkesën tuaj të bashkimit bashkë me nivelin e rrezikshmërisë, që t'ju bëjnë të ditur para se të kryeni bashkimin, se çfarë rreziqesh sjell varësia e re. Ju gjithashtu mund të konfiguroni projektin tuaj për të kërkuar miratimin e kërkesës së bashkimit për varësitë me dobësi me nivel kritik (Critical), të lartë (High) ose të panjohur (Unknown).

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

Njoftimet kur ndryshon cilësimi i kërkesës së bashkimit në ‘Bashko kur përfundon me sukses pipeline’

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

Më parë, kur caktohej cilësimi i kërkesës së bashkimit Bashko, kur përfundon pipeline (Merge When Pipeline Succeeds, MWPS) nuk dërgohej asnjë njoftim me email. Ju detyroheshit të kontrollonit manualisht statusin ose të prisni njoftimin për përfundimin e bashkimit. Në këtë lëshim, ne jemi të gëzuar 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ë nënshkruar në kërkesën e bashkimit, kur rishikuesi ndryshon cilësimin e bashkimit në MWPS.

Dokumentacioni për njoftimet e ngjarjeve të kërkesave të bashkimit dhe biletën origjinale.

Krijimi i klastereve EKS me versionin e Kubernetes të caktuar 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 nga EKS; mund të zgjidhni midis versioneve 1.14–1.17.

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

Krijimi i incidentëve si lloje biletesh

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

Jo çdo problem që lind çon menjëherë në dërgimin e njoftimeve: përdoruesit raportojnë për ndërprerje të shërbimit, ndërsa anëtarët e ekipeve shqyrtojnë problemet me performancën. Tani incidentet janë një lloj bilete, kështu që ekipet tuaja do të jenë në gjendje t'i krijojnë ato shpejt në kuadër të procesit të zakonshëm të punës. Klikoni Detyrë e re nga çdo vend në GitLab, dhe në fushën Lloji zgjidhni Incidenti.

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

Përmendja e njoftimeve të GitLab në Markdown

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

Ne përmirësuam njoftimet e GitLab duke shtuar një lloj të ri përmendjeje posaçërisht për to në versionin Markdown të GitLab, duke lejuar ndarjen më të lehtë të njoftimeve dhe përmendjen e tyre. Përdorni ^alert#1234, për të përmendur një njoftim 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, 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 që është kritik për diagnostikimin e ndërprerjeve dhe rikuperimin, dhe ky informacion duhet të jetë lehtësisht i aksesueshëm, në mënyrë që të mos ju duhet të kaloni nëpër vegla ose skeda ndërsa punoni për zgjidhjen e incidentit. Incidentet e krijuara nga njoftimet shfaqin përshkrimin e plotë të njoftimit në skedën Detajet e Njoftimit.

75% më shpejt kërkim i avancuar

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

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

Dokumentacioni për kërkimin më të shpejtë të avancuar 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ë shtyrë fshirjen e projektit u introduktua në 12.6. Megjithatë, më parë nuk ka pasur mundësi për të parë në një vend të vetëm të gjitha projektet që prisnin të fshiheshin. Tani administratorët e instancave përdorues të GitLab mund të shikojnë të gjitha projektet që prisnin të fshiheshin në një vend — së bashku me butona për rivendosjen e lehtë të këtyre projekteve.

Kjo mundësi u lejon administratorëve të kontrollojnë më mirë fshirjen e projekteve, duke mbledhur të gjitha informacionet e nevojshme në një vend dhe duke ofruar mundësinë për të anulluar veprimet e padëshiruara për fshirjen.

anonim kommentatorit Ashesh Vidyut (@asheshvidyut7) për këtë funksionalitet!

Dokumentacioni 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 shtytje mund të konfiguroheshin vetëm duke vizituar çdo grup individualisht përmes ndërfaqes përdoruese të GitLab dhe duke aplikuar këto rregulla. Tani mund të menaxhoni këto rregulla përmes API për të mbështetur mjetet tuaja përdoruese dhe automatizimin e GitLab.

Dokumentacioni për rregullat e grupit për shtytje dhe biletën origjinale.

Revokimi i tokeneve personale të aksesit për magazinat e vet-menaxhuara të kredencialeve

(ULTIMATE) Faza e ciklit DevOps: Menaxho

Magazina e kredencialeve ofron informacionin e nevojshëm për administratorët për të menaxhuar kredencialet e përdoruesve në instancën e tyre GitLab. Duke qenë se organizatat që janë të orientuara ndaj përputhshmërisë ndryshojnë në ashpërsinë e rregullave të tyre për menaxhimin e kredencialeve, ne kemi shtuar një buton që u lejon administratorëve të revokojnë, nëse dëshirojnë, token e personalizuar të aksesit të përdoruesit (PAT). Tani administratorët mund të revokojnë lehtësisht PAT që mund të jenë kompromentuara. Ky funksionalitet është i dobishëm për organizatat që kanë nevojë për mundësi më fleksibile për të siguruar përmbushjen e kërkesave, për të minimizuar shpërqendrimet e përdoruesve të tyre.

Dokumentacioni për magazinën 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: Krijo

Në GitLab 13.4 ne prezantojmë një mënyrë të re për konfigurimin e redaktuesit të faqeve statike. Ndërsa skedari i konfigurimit nuk ruan dhe nuk merr asnjë parametër në këtë publikim, ne po vendosim bazat për konfigurimin e ardhshëm të sjelljes së redaktuesit. Në publikimet në vazhdim ne do të shtojmë në skedar .gitlab/static-site-editor.yml parametra për të vendosur adresën bazë të faqes, ku janë ruajtura imazhet e ngarkuara në redaktues., përcaktimi i cilësimeve të sintaksës Markdown dhe cilësimeve të tjera të redaktorit.

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

Redaktimi i seksionit hyrës të skedës me redaktorin e faqeve statike.

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

Seksioni hyrës (front matter) është një mënyrë fleksibile dhe e përshtatshme për të përcaktuar variablat e faqes në skedat e të dhënave që janë destinuar për t'u përpunuar nga gjeneratori i faqeve statike. Zakonisht përdoret për të vendosur titullin e faqes, shablonin e dizajnit ose autorin, por mund të përdoret gjithashtu për të dërguar çdo lloj metadate në gjenerator gjatë renderizimit të faqes në HTML. Duke u përfshirë në krye të çdo skede të dhënash, seksi hyrës zakonisht formatizohet si YAML ose JSON dhe kërkon një sintaksë të saktë dhe të qëndrueshme. Përdoruesit, të pa njohur me rregullat specifike të sintaksës, mund të futin pa dashje markup të pavlefshëm, i cili mund të shkaktojë probleme me formatimin ose madje dështime gjatë ndërtimit.

Mënyra e redaktimit WYSIWYG e redaktorit të faqeve statike tashmë e heq seksionin hyrës nga redaktori për të parandaluar këto gabime formatimi. Sidoqoftë, kjo nuk ju lejon të ndryshoni vlerat e ruajtura në këtë pjesë pa u rikthyer në redaktimin në mënyrën e kodit burimor. Në GitLab 13.4, ju mund të accedoni çdo fushë dhe të redaktoni vlerën e saj në një ndërfaqe të njohur të bazuar në forma. Duke klikuar butonin Cilësimet (Settings) do të hapet një panel, ku shfaqet një fushë forme për çdo çelës të përcaktuar në fillim. Fushat plotësohen me vlerën aktuale, dhe për të redaktuar ndonjë nga to, mjafton të shkruani në formën në internet. Kjo redaktim i seksionit hyrës lejon shmangien e vështirësive me sintaksën dhe ju ofron kontroll të plotë mbi përmbajtjen, duke siguruar një formatim të njëtrajtshëm të rezultatit përfundimtar.

Dokumentacioni për redaktorin 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: Krijo

Për përdoruesit e Jira në GitLab: aplikacioni GitLab për Jira. dhe DVCS Connector lejojnë paraqitjen e informacionit mbi commit-et dhe merge-request-et e GitLab direkt në Jira. Në kombinim me integrimin tonë të ndërtuar në Jira, ju mund të lëvizni lehtësisht midis dy aplikacioneve gjatë punës.

Këto funkcione, më parë, ishin të disponueshme vetëm në planin tonë Premium, por tani ato janë të disponueshme 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: Krijo

Klusteri Gitaly lejon replikimin e depozitave Git në disa nodet 'të ngrohta' Gitaly. Kjo rrit disponueshmërinë duke eliminuar piketat e vetme të dështimit. Operacione transaksionale, të prezantuara në GitLab 13.3, shkaktojnë transmetimin masiv të ndryshimeve në të gjitha nodet Gitaly në klaster, por vetëm nodet Gitaly që votojnë në pajtim me noden kryesore ruajnë ndryshimet në disk. Nëse të gjitha nodet-replika nuk arrijnë një marrëveshje, 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ë rrit disponueshmërinë, duke kërkuar pajtimin e shumicës së nodave (e jo të gjitha) para se të ruajnë ndryshimet në disk. Nëse ky funksion i kaluar është aktivizuar, regjistrimi duhet të përfundojë me sukses në disa nodë. Nodet e mospajtuara sinkronizohen automatikisht me anë të replikimit asinkron me ato nodë që formojnë kuorum.

Dokumentacioni për konfigurimin e pajtueshmërisë 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: Krijo

Projeketet, ku njerëzit shkruajnë konfiguracione në formatin JSON ose YAML, shpesh janë të ekspozuara ndaj problemeve, sepse është e lehtë të bësh një gabim dhe të dështosh diçka. Mund të shkruhen mjete kontrollimi që kapin këto probleme në pipeline-n CI, por përdorimi i një skeme JSON mund të jetë e dobishme për të ofruar dokumentacion dhe këshilla.

Anëtarët e projektit mund të përcaktojnë në depozitën 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 për kontrollim. Kur ngarkohet një skedar i caktuar në Web IDE, do të shihet një reagim dhe verifikim shtesë që do të ndihmojë në krijimin e skedarit.

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

Kufiri i degës së grafit të drejtuar aciklik (DAG) është rritur në 50

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

Nëse po përdorni pipeline me grafin e drejtuar aciklik (Directed Acyclic Graph (DAG)), mund të keni zbuluar se kufiri prej 10 detyrash, që një detyrë mund të tregojë në necesitet:, shumë e ashpër. Në 13.4 kufiri i paracaktuar u rrit nga 10 në 50, për të mundësuar rrjete më komplekse lidhjesh midis detyrave në pipelines tuaj.

Nëse jeni administrator i instancës së përdoruesit të GitLab, mund të ngrini këtë kufi edhe më lart duke konfiguruar një veçori të aktivizueshme, megjithatë 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: Verify

Në disa raste, një detyrë e humbur në pipeline mund të konsiderohej gabimisht si e suksesshme për varësitë e deklaruara në needs, duke shpërndarë kështu detyrat e tjera, çka nuk duhej të ndodhte. Ky sjellje është korrigjuar në versionin 13.4, dhe needs tani trajton në mënyrë korrekte rastet e detyrave të humbura.

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

Bllokoni 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: Verify

GitLab tani automatikisht bllokon artefaktin e fundit të një detyre dhe pipeline në çdo degë aktive, kërkesë bashkimi ose etiketë për të parandaluar fshirjen e tij pas skadimit të afatit. Behet më e lehtë të vendosni rregulla më agresive për skadimin për pastrimin e artefakteve të vjetra. Kjo ndihmon në uljen e konsumit të hapësirës disk dhe siguron që të keni gjithmonë një kopje të artefaktit të fundit nga pipeline.

Dokumentacioni për skadimin e artefakteve dhe biletën origjinale.

Udhëzuesi për CI/CD për optimizimin e pipeline

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

Optimizimi i funksionimit të pipeline CI/CD mund të rrisë shpejtësinë e shpërndarjes 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 pipeline tuaj.

Dokumentacioni për përmirësimin e efikasitetit të pipeline-ve dhe biletën origjinale.

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

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

Raporti për testet e njësive — është një mënyrë e thjeshtë për të parë rezultatet e të gjitha testeve në pipeline. Megjithatë, me një numër të madh testesh, gjetja e testeve të dështuar mund të zgjasë shumë. Probleme të tjera që e bëjnë të vështirë përdorimin e raportit përfshijnë vështirësitë në rulimin e daljeve të gjata të gjurmimit dhe rrethimin e kohës në zero për testet që ekzekutohen nën 1 sekondë. Tani, si parazgjedhje, raporti i testeve rendit së pari testet e dështuar në fillim të raportit dhe pastaj rendit testet sipas kohëzgjatjes. Kjo e lehtëson gjetjen e dështimeve dhe testeve me kohë të gjatë. Për më tepër, kohëzgjatja e testeve tani shfaqet në milisekonda ose sekonda, kështu që është bërë shumë më e lehtë për t'u lexuar, dhe gjithashtu janë zgjidhur problemet e mëparshme me rullitjen.

Dokumentacioni mbi raportet e testeve të njësive dhe biletën origjinale.

Kufizimet për madhësinë e skedarëve të ngarkuar në regjistrin e pakove

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

Tani ka kufizime për madhësinë e skedarëve të pakove që mund të ngarkohen në regjistrin e pakove GitLab. Kufizimet janë shtuar 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ë skedarëve janë:

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

Për instancat e përdoruesve të GitLab, vlerat e parazgjedhura janë të njëjta. Sidoqoftë, administratori mund të azhurnojë kufizimet me anë të konsolës Rails.

Dokumentacioni mbi kufizimet për madhësinë e skedarëve dhe biletën origjinale.

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

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

Mund të përdorni regjistrin GitLab PyPI për të krijuar, publikuar dhe ndarë paketa Python së bashku me kodin burim dhe ciljet CI/CD. Sidoqoftë, më parë nuk mund të autentikoheshit në regjistrin me anë të një variabli të paracaktuar të ambientit CI_JOB_TOKEN. Si rezultat, ju duhej të përdornit kredencialet tuaja personale për të azhurnuar regjistrin PyPI, ose ndoshta keni vendosur të mos përdorni fare regjistrin.

Tani është bërë më e lehtë për të përdorur GitLab CI/CD për të publikuar dhe instaluar paketa PyPI me anë të një variabli të paracaktuar të ambientit CI_JOB_TOKEN.

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

Profili i skanerit DAST me kërkesë

(ULTIMATE, GOLD) Faza e ciklit DevOps: Siguria

Për skanimin DAST me kërkesë, që u introduktua në versionin e mëparshëm, janë shtuar profilat e skanerit DAST. Këta rrisin kapacitetet e konfigurimit të këtij skanimi, duke lejuar krijimin e shpejtë të disa profileve për të mbuluar disa lloje skanimi. Në versionin 13.4, profili i skanerit përfshin fillimisht parametrin e kohës së skadimit të robotit të kërkimit, i cili përcakton se sa gjatë duhet të punojë robotin DAST, kur përpiqet të zbulojë të gjitha faqet e faqes që po skanohet. Profili gjithashtu përfshin parametrin e kohës së skadimit të faqes që synohet, për të përcaktuar se sa gjatë skaneri duhet të presë derisa faqja të bëhet e aksesueshme, përpara se të ndalojë skanimin nëse faqja nuk përgjigjet me kodin e statusit 200 ose 300. Ndërsa do të vazhdojmë të përmirësojmë këtë funksion në versionet e ardhshme, do të shtohen parametra të tjerë konfigurimi në profilin e skanerit.

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

Një skedar i thjeshtë konfigurimi për ridirektimet në GitLab Pages

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

Nëse përdorni GitLab Pages dhe dëshironi të menaxhoni më mirë ndryshimet në URL, mund të keni vënë re se ishte e pamundur të menaxhohen ridirektimet në faqen tuaj GitLab Pages. GitLab tani ju lejon të konfiguroni rregulla për ridreksionimin e një URL në një tjetër për faqen tuaj Pages, duke shtuar një skedar konfigurimi në depo. Ky funksion u bë i mundur falë kontributit të Kevin Barnett (@PopeDrFreud), Eric Eastwood (@MadLittleMods) dhe ekipit të GitLab. Faleminderit të gjithëve për kontributin tuaj.

Dokumentacioni për ridirektet dhe biletën origjinale.

Statusi i Terraform-it, i menaxhuar nga GitLab

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

Qasja në versionet e mëparshme të statusit të Terraform-it është e nevojshme si për përputhshmërinë ashtu edhe për debugimin kur është e nevojshme. Mbështetje për menaxhimin e versioneve të statusit të Terraform-it, të menaxhuar nga GitLab, është në dispozicion që nga GitLab 13.4. Menaxhimi i versioneve aktivizohet automatikisht për skedarët e rinj të statusit të Terraform-it. Skedarët ekzistues të statusit të Terraform-it do të transferohen automatikisht në një magazinë me mbështetje për versionet në një version të mëvonshëm.

Dokumentacioni për statuset e Terraform-it, të menaxhuar nga GitLab dhe biletën origjinale.

Detaje të rëndësishme mbi njoftimin për incidentet

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

Gjatë trajtimit të incidenteve, është e nevojshme që të identifikoni lehtë sa kohë ka qenë e hapur alarmi dhe sa herë është ndodhur ngjarja. Këto detaje shpesh kanë rëndësi vendimtare për të përcaktuar ndikimin ndaj klientit dhe atë çka ekipi juaj duhet të merret me prioritet. Në panelin e ri të detajeve të incidenteve, ne shfaqim kohën e fillimit të alarmit, numrin e ngjarjeve dhe një lidhje me alarmin origjinal. Këto informacione janë të disponueshme për incidentet që krijohen nga alarmet.

Dokumentacioni për menaxhimin e incidenteve dhe epiku origjinal.

Vendosja dhe redaktimi i parameterit të rëndësisë së incidentit

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

Parametri "rëndësia e incidentit" lejon profesionistët e reagimit dhe palët e interesuara të përcaktojnë pasojat e ndërprerjeve të shërbimeve, si dhe metodat dhe urgjencën e reagimit. Ndërsa ekipi juaj ndan rezultatet gjatë zgjidhjes së incidentit dhe rikthen funksionalitetin, ata mund të bëjnë ndryshime në këtë parameter. Tani mund të redaktoni rëndësinë e incidentit në panelin e djathtë të faqes "Detaje rreth incidentit", dhe shkalla e rëndësisë shfaqet 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 kontejnerët

(ULTIMATE, GOLD) Faza e ciklit DevOps: Mbrojtja

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

Dokumentacioni për redaktorin e rregullave të rrjetit dhe epiku origjinal.

Mbështetje për magazinën e blob-objekteve Azure

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

Si GitLab ashtu edhe GitLab Runner tani mbështesin magazinën e blob-objekteve Azure, e cila lehtëson ekzekutimin e shërbimeve GitLab në Azure.

Instancat e GitLab mbështesin Azure për të gjitha llojet e magazinave të objekteve, përfshirë skedarët LFS, artefaktet CI dhe kopje rezervë. Për të konfiguruar magazinën e blob-objekteve Azure, ndiqni udhëzimet për instalimin e Omnibus ose Helm chart.

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

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

Paketat Omnibus ARM64 për Ubuntu dhe OpenSUSE

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

Në përgjigje të kërkesës në rritje për mbështetje për funksionimin e GitLab për arkitekturën 64-bit ARM, ne jemi të lumtur të njoftojmë disponimin e paketës zyrtare ARM64 Ubuntu 20.04 Omnibus. Një falënderim të madh për Zitai Chen dhe Guillaume Gardet për kontributin e tyre të jashtëzakonshëm - 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, vizitoni faqen tonë të instalimit dhe zgjidhni Ubuntu.

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

Mbështetje për autentifikimin përmes kartave smart për diagramin GitLab Helm

(PREMIUM, ULTIMATE) Disponueshmëria

Kartat smart, siç janë kartat e qasshëm (CAC), tani mund të përdoren për autentifikimin në instancën GitLab të vendosur përmes diagramit Helm. Kartat smart autentifikohen në databazën lokale duke përdorur certifikata X.509. Për pasojë, mbështetja për kartat smart në diagramin Helm tani është në përputhje me mbështetjen për kartat smart, të disponueshme në vendosjet Omnibus.

Dokumentacioni për konfigurimet e autentifikimit me karta smart dhe biletën origjinale.

Detajet për release dhe udhëzimet për përditësim/instalim mund të lexohen në postimin origjinal në anglisht: GitLab 13.4 u publikua me Vault për variablat CI dhe Agjentin Kubernetes.

Për përkthimin nga anglishtja punuan cattidourden, maryartkey, ainoneko dhe rishavant.

Burimi: habr.com