Zbulimi i shpejtë i rrjedhjeve të sekreteve
Duket si njĂ« gabim i vogĂ«l â tĂ« dĂ«rgosh rastĂ«sisht kredencialet nĂ« njĂ« depo tĂ« pĂ«rbashkĂ«t. MegjithatĂ«, pasojat mund tĂ« jenĂ« serioze. Sa herĂ« qĂ« njĂ« sulmues tĂ« marrĂ« fjalĂ«kalimin tuaj ose çelĂ«sin e API-sĂ«, ai do tĂ« pushtojĂ« llogarinĂ« tuaj, t'ju bllokojĂ« dhe tĂ« pĂ«rdorĂ« paratĂ« nĂ« mĂ«nyrĂ« mashtruese. PĂ«rveç kĂ«saj, efekti domino Ă«shtĂ« i mundshĂ«m: akseset nĂ« njĂ« llogari hapin akses nĂ« tĂ« tjerat. Rreziqet janĂ« tĂ« mĂ«dha, prandaj Ă«shtĂ« thelbĂ«sore tĂ« zbuloni mundĂ«sinĂ« e rrjedhjes sĂ« sekreteve sa mĂ« shpejt tĂ« jetĂ« e mundur.
NĂ« kĂ«tĂ« version ne prezantojmĂ« opsionin si pjesĂ« e funksionalitetit tonĂ« SAST. Ădo commit skanohet nĂ« detyrĂ«n CI/CD pĂ«r sekrete. NjĂ« sekret? Zhvilluesi merr njĂ« paralajmĂ«rim nĂ« kĂ«rkesĂ«n pĂ«r bashkim. Ai anulon menjĂ«herĂ« kredencialet e rrjedhura dhe krijon tĂ« reja.
Sigurimi i menaxhimit të duhur të ndryshimeve
Me rritjen dhe komplimin e organizatave, është gjithnjë e më e vështirë të ruhet konsistenca midis pjesëve të ndryshme të organizatës. Sa më shumë përdorues të jenë në aplikacion dhe sa më të larta të jenë të ardhurat, aq më serioze janë pasojat e bashkimit të kodit të gabuar ose të pasigurta. Për shumë organizata, sigurimi i një procesi të duhur kontrolli para bashkimit të kodit është një kërkesë strikte, pasi rreziqet janë shumë të larta.
NĂ« GitLab 11.9, ka mĂ« shumĂ« kontroll dhe njĂ« strukturĂ« mĂ« efikase â falĂ« . MĂ« parĂ«, pĂ«r tĂ« marrĂ« miratimin, mjaftonte tĂ« specifikoje njĂ« individ ose grup (çdo anĂ«tar i tĂ« cilit mund tĂ« jepte miratim). Tani mund tĂ« shtosh disa rregulla, nĂ« mĂ«nyrĂ« qĂ« kĂ«rkesa pĂ«r bashkim tĂ« kĂ«rkojĂ« miratim nga individĂ« tĂ« veçantĂ« ose madje nga disa anĂ«tarĂ« tĂ« njĂ« grupi tĂ« caktuar. PĂ«r mĂ« tepĂ«r, nĂ« rregullat e miratimit Ă«shtĂ« e integruar veçoria e PronarĂ«ve tĂ« Kodit, e cila lejon tĂ« identifikosh lehtĂ«sisht personin qĂ« ka dhĂ«nĂ« miratimin.
Kjo u jep mundësinë organizatave të realizojnë procese komplekse të zgjidhjes, duke ruajtur thjeshtësinë e një aplikacioni të vetëm GitLab, ku detyrat, kodi, kanalet dhe të dhënat e monitorimit janë të dukshme dhe të aksesueshme për të marrë vendime dhe për të përshpejtuar procesin e zgjidhjes.
ChatOps tani është me burim të hapur
GitLab ChatOps është një mjet efikas automatizimi që lejon të ekzekutoni çdo punë CI/CD dhe të kërkoni statusin e saj direkt në aplikacione chat si Slack dhe Mattermost. , ChatOps ishte një pjesë e abonimit GitLab Ultimate. Duke u bazuar në dhe , ndonjëherë ne zhvendosim funksionet poshtë nivelit dhe kurrë lart.
Në rastin e ChatOps, ne kuptuam se ky funksionalitet mund të jetë i dobishëm për të gjithë dhe se pjesëmarrja e komunitetit mund të sjellë përfitime për funksionin vetë.
Në GitLab 11.9 ne , duke e bërë atë tani të disponueshëm falas për t'u përdorur në GitLab Core të menaxhuar vetë dhe në GitLab.com dhe të hapur për komunitetin.
Dhe shumë më tepër!
NĂ« kĂ«tĂ« version ka shumĂ« funksione tĂ« shkĂ«lqyera nĂ« dispozicion: pĂ«r shembull, , dhe , â çfarĂ« mezi presim tĂ« flasim pĂ«r to!
Punonjësi më i vlefshëm () i këtij muaji është shpallur Marcel Amirault ()
Marcel ka ndihmuar vazhdimisht nĂ« pĂ«rmirĂ«simin e dokumentacionit tĂ« GitLab. Ai pĂ«r tĂ« pĂ«rmirĂ«suar cilĂ«sinĂ« dhe lehtĂ«sinĂ« e pĂ«rdorimit tĂ« dokumenteve tona. Domo arigato [faleminderit shumĂ« (jap.) â sh.j.] Marcel, ne e vlerĂ«sojmĂ« sinqerisht kĂ«tĂ«!
Tiparet kryesore të shtuar në lëshimin GitLab 11.9
Zbulimi i sekreteve dhe të dhënave të identifikimit në depo
(ULTIMATE, GOLD)
Zhvilluesit ndonjëherë pa dashje transmetojnë sekrete dhe kredenciale në depo të largëta. Nëse të tjerët kanë qasje në këtë burim, ose nëse projekti është i hapur, informacioni konfidencial i zbulohet dhe mund të përdoret nga sulmues për të qasje në burime të tilla si mjediset e shpërndarjes.
GitLab 11.9 ka njĂ« test tĂ« ri â âZbulimi i Sekreteveâ. Ai skanon pĂ«rmbajtjen e depos pĂ«r kĂ«rkesa API dhe informacione tĂ« tjera qĂ« nuk duhet tĂ« jenĂ« kĂ«tu. GitLab tregon rezultatet nĂ« raportin SAST nĂ« widget-in e kĂ«rkesĂ«s pĂ«r bashkim, raportet e pipeline dhe nĂ« panelin e sigurisĂ«.
Nëse tashmë e keni aktivizuar SAST për aplikacionin tuaj, nuk keni nevojë të bëni asgjë, thjesht shfrytëzoni përfitimet e kësaj veçorie të re. Ajo është gjithashtu e përfshirë në konfigurim. si dyshim.
Rregullat e miratimit të kërkesave për bashkim
(PREMIUM, ULTIMATE, SILVER, GOLD)
Riktheimi i kodit është një element i pandashëm i çdo projekti të suksesshëm, por shpesh nuk është e qartë se kush duhet të marrë pjesë në rishikimin e ndryshimeve. Shpesh dëshirohet pjesëmarrja e rishikuesve nga ekipe të ndryshme: ekipi i zhvilluesve, ekipi për ndërveprimin me përdoruesit, ekipi i prodhimit.
Rregullat e miratimit lejojnë përmirësimin e procesit të bashkëpunimit midis personave që marrin pjesë në rikthimin e kodit: përcaktohet grupi i personave të autorizuar për të miratuar dhe numri minimal i miratimeve. Rregullat e miratimit shfaqen në widget-in e kërkesës për bashkim, dhe kështu, mund të emërohet shpejt rishikuesi i ardhshëm.
Në GitLab 11.8 rregullat e miratimit ishin të çaktivizuara si parazgjedhje. Duke filluar nga versioni GitLab 11.9 ato janë të disponueshme si parazgjedhje. Në GitLab 11.3 prezenduam opsionin për të identifikuar anëtarët e ekipit përgjegjës për kodet e veçanta brenda një projekti. Funksioni i Pronave të Kodit është i integruar në rregullat e zgjidhjes, duke e bërë gjithmonë të lehtë për të gjetur njerëzit e duhur për të rishikuar ndryshimet.
Shkarkimi i ChatOps në Core
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Fillimisht i futur në GitLab Ultimate 10.6, ChatOps është transferuar në GitLab Core. GitLab ChatOps ofron mundësinë për të ekzekutuar punë GitLab CI përmes Slack me ndihmën e funksionalitetit .
Ne po hapim kodin burimor të këtij funksionaliteti në përputhje me . Duke e përdorur atë më shpesh, komuniteti do të kontribuojë më shumë.
Auditimi i parametrave të funksioneve
(PREMIUM, ULTIMATE, SILVER, GOLD)
Operacione të tilla si shtimi, fshirja ose ndryshimi i parametrave të funksioneve tani regjistrohen në logun e auditit të GitLab, duke ju lejuar të shihni se çfarë dhe kur është ndryshuar. A po ndodhi një aksident dhe duhet të shikoni se çfarë ka ndryshuar së fundmi? Apo thjesht keni nevojë të kontrolloni si janë ndryshuar parametrat e funksioneve për qëllime auditi? Tani është shumë e lehtë të bëni këtë.
Rrëzimi i dobësive të kërkesave për bashkim
(ULTIMATE, GOLD)
PĂ«r tĂ« eliminuar shpejt dobĂ«sitĂ« nĂ« kod, procesi duhet tĂ« jetĂ« i thjeshtĂ«. ĂshtĂ« e rĂ«ndĂ«sishme tĂ« thjeshtĂ«sohen rregullimet e sigurisĂ«, duke i mundĂ«suar zhvilluesve tĂ« pĂ«rqendrohen nĂ« detyrat e tyre kryesore. NĂ« GitLab 11.7 ne , por ai duhej ngarkuar, aplikuar lokalish dhe pastaj tĂ« transferoheshin ndryshimet nĂ« depo tĂ« largĂ«t.
Në GitLab 11.9 ky proces është automatizuar. Eliminoni dobësitë pa dalë nga ndërfaqja e uebit të GitLab. Një kërkesë për bashkim krijohet direkt nga dritarja e informacionit për dobësitë, dhe kjo degë e re do të përmbajë tashmë rregullimin. Pas verifikimit nëse problemi është zgjidhur, shtoni rregullimin në degën origjinale, nëse pipeline është në rregull.
Shfaqja e rezultateve të skanimit të kontejnerëve në panelin e sigurisë së grupit
(ULTIMATE, GOLD)
Paneli i sigurisë së grupit lejon specialistët të përqendrohen në çështjet më të rëndësishme për punën e tyre, duke ofruar një përmbledhje të qartë dhe të detajuar të të gjitha vulnerabiliteteve të mundshme që mund të ndikojnë në aplikacione. Këtu është pse është e domosdoshme që paneli të përmbajë të gjitha informacionet e nevojshme në një vend dhe t'u mundësojë përdoruesve të shqyrtojnë të dhënat para se të adresojnë vulnerabilitetet.
Në GitLab 11.9, rezultatet e skanimit të kontejnerëve janë shtuar në panelin e instrumenteve, përveç rezultateve të SASHT dhe skanimeve të varësive që ishin tashmë të disponueshme. Tani, gjithë përmbledhja është në një vend, pavarësisht nga burimi i problemit.
Shabllonet CI/CD për punët e sigurisë
(ULTIMATE, GOLD)
Funksionet e sigurisë së GitLab po përparojnë shumë shpejt dhe kërkojnë vazhdimisht përditësime për të mbajtur efektivitetin dhe mbrojtjen e kodit. Të ndryshosh përcaktimin e punës është e vështirë kur menaxhon disa projekte. Dhe ne gjithashtu kuptojmë: askush nuk do të dëshirojë të rrezikojë duke përdorur versionin më të fundit të GitLab pa pasur siguri për përputhshmërinë e tij të plotë me instancën aktuale të GitLab.
Pikërisht për këtë arsye ne prezantuam në GitLab 11.7 një mekanizëm të ri për përcaktimin e punëve duke përdorur .
QĂ« nga GitLab 11.9, ne do tĂ« ofrojmĂ« shabllona tĂ« integruara pĂ«r tĂ« gjitha punĂ«t e sigurisĂ«: pĂ«r shembull, sast dhe scanning i varĂ«sive, â tĂ« pĂ«rputhshme me versionin pĂ«rkatĂ«s tĂ« GitLab.
Aktivizoni ato drejtpërdrejt në konfigurimin tuaj, dhe ato do të përditësohen së bashku me sistemin me çdo përditësim në një version të ri të GitLab. Konfigurimet e pipeline nuk ndryshojnë.
Mënyra e re e përcaktimit të punëve të sigurisë është zyrtare dhe nuk mbështet asnjë përcaktim të mëparshëm të punëve ose fragmenteve të kodit. Duhet të përmirësoni sa më shpejt të jetë e mundur përcaktimin për të përdorur fjalën kyçe
template. Mbështetja për çdo sintaksë tjetër mund të hiqet në GitLab 12.0 ose në lëshime të tjera të ardhshme.
Përmirësime të tjera në GitLab 11.9
Përgjigje në koment
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Në GitLab ka diskutime mbi tema. Deri tani, përdorësi që shkruan komentimin fillestar duhet të kishte vendosur që nga fillimi nëse i nevojitet diskutimi.
Ne e kemi zbutur këtë kufizim. Merrni çdo koment në GitLab (në detyra, kërkesa për bashkim dhe epika) dhe përgjigjuni atij, duke filluar kështu diskutimin. kështu ekipet ndërveprojnë më organizuar.
Shabllone projektesh për .NET, Go, iOS dhe Pages
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Për të thjeshtuar krijimin e projekteve të reja për përdoruesit, ne ofrojmë disa shabllone të reja projektesh:
- Fillestar , duke përfshirë një aplikacion bazë me CI.
- Një shabllon i gatshëm për punë, që kombinon dhe GitLab CI/CD.
- , i gatshëm për personalizim fillestar në GitLab. Vini re se, pasi ndihma për ndërtimin e iOS kërkon një runner të dedikuar MacOS, do të nevojitet të sigurohet server i vet për ndërtim, nëse dëshironi ta përdorni atë me GitLab CI/CD.
- janë të konfiguruara për të punuar me Netlify.
Kërkoni miratimin e kërkesave të bashkimit nga Pronarët e Kodit
(PREMIUM, ULTIMATE, SILVER, GOLD)
Nuk është gjithmonë e qartë se kush miraton kërkesat e bashkimit.
Tani GitLab mbështet kërkesën për miratim të kërkesës së bashkimit, në varësi të skedarëve që modifikon kërkesa, me ndihmën e . Pronarët e Kodit emërohen me ndihmën e një skedari të quajtur CODEOWNERS, formati është i ngjashëm me gitattributes.
Mbështetje për emërimin automatik të Pronarëve të Kodit si personat përgjegjës për miratimin e kërkesës së bashkimit është shtuar që në .
Kthimi i skedarëve në Web IDE
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Tani, duke e rinomuar skedarin ose katalogun, mund ta rivendosni atë nga Web IDE në depozitë në një rrugë të re.
Etiketat në rend alfabetik
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Etiketat GitLab janë jashtëzakonisht universale, dhe ekipet vazhdimisht i gjejnë përdorime të reja për to. Për pasojë, përdoruesit shpesh shtojnë shumë etiketa në një detyrë, kërkesë bashkimi ose epikë.
Në GitLab 11.9, ne paksa e thjeshtuam përdorimin e etiketave. Në detyrat, kërkesat e bashkimit dhe epikat, etiketat që shfaqen në panelin anësor janë të renditura në rend alfabetik. Kjo vlen edhe për shikimin e listës së këtyre objekteve.
Komentet e shpejta kur filtrohen veprimet sipas detyrës
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Këto ditë, ne prezantuam një tipar që u lejon përdoruesve të filtrojnë rrjedhën e veprimeve sipas detyrave, kërkesave të bashkimit ose epikave, duke u mundësuar ashtu që të përqendrohen vetëm në komentet ose shënimet sistemore. Ky parametr ruhet për çdo përdorues në sistem, dhe ndodh që përdoruesi mund të mos kuptojë se, duke shikuar një detyrë disa ditë më vonë, ai po sheh një rrjedhë të filtruar. I duket se nuk mund të lërë një koment.
Ne kemi përmirësuar këtë ndërveprim. Tani përdoruesit mund të kalojnë shpejt në modalitetin që lejon lënien e komenteve, pa e rrokullisur fillimisht faqen mbrapa deri në krye. Kjo vlen për detyrat, kërkesat për bashkim dhe epiket.
Ndryshimi i rendit të epikëve të fëmijëve
(ULTIMATE, GOLD)
Kohët e fundit ne publikuan , që lejojnë përdorimin e epikëve të epikëve (përveç detyrave të fëmijëve të epikëve).
Tani është e mundur të ndryshohet rendi i epikëve të fëmijëve thjesht me tërheqje dhe lëshim, siç bëhet me detyrat e fëmijëve. Ekipet mund të përdorin rendin për të reflektuar prioritetin ose për të përcaktuar rendin e zbatimit të punëve.
Mesazhet e sistemit të përdoruesit përfundore dhe të sipërme në internet dhe në e-mail
(CORE, STARTER, PREMIUM, ULTIMATE)
Më parë ne shtuam një veçori që lejon që mesazhet e sistemit përfundore dhe të sipërme të shfaqen në çdo faqe në GitLab. Ata u pritën ngrohtësisht dhe ekipet i përdorin ato për të ndarë informacione të rëndësishme: për shembull, mesazhe sistemore që lidhen me instancën e tyre GitLab.
Kemi me kënaqësi që e kemi sjellë këtë veçori në Core, kështu që tani mund ta shfrytëzojnë një numër edhe më i madh njerëzish. Në përputhje me këtë, lejojmë përdoruesit të shfaqin të njëjtat mesazhe në të gjitha email-et e dërguara përmes GitLab, për të siguruar një qëndrim të njëjtë në çdo pikë interaksioni me GitLab.
Filtri për detyrat e konfidencialitetit
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Detyrat e konfidencialitetit janë një mjet i dobishëm për ekipet, duke lejuar biseda të mbyllura për temat delikate brenda një projekti publik. Në veçanti, ato janë të përshtatshme për punën mbi dobësitë e sigurisë. Deri tani, menaxhimi i detyrave të konfidencialitetit nuk ka qenë shumë i lehtë.
Në GitLab 11.9, lista e detyrave në GitLab tani filtrohet sipas detyrave të konfidencialitetit ose jo-konfidencialitetit. Kjo vlen edhe për kërkimin e detyrave përmes API.
Faleminderit për kontributin e Robert Schilling ()!
Redaktimi i domain-it Knative pas implementimit
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Specified domain during Knative installation allows for serving various serverless applications/functions with a unique endpoint.
Tani integrimi i Kubernetes në GitLab lejon ndryshimin/përditësimin e domain-it të përdoruesit pas deploy-it të Knative në klasterin Kubernetes.
Kontrolli i formatit të certifikatës Kubernetes CA
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Kur shtoni një klaster ekzistues Kubernetes, GitLab tani kontrollon që certifikata CA e dhënë të ketë formatin e pranueshëm PEM. Kjo parandalon mundësinë e gabimeve me integrimin e Kubernetes.
Zgjerimi i mjetit të krahasimit të merge request për të gjithë skedarin
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Ndërsa shikoni ndryshimet në merge request, tani mund të zgjeroni mjetin e krahasimit për çdo skedar, për të treguar të gjithë skedarin për kontekst më të gjerë dhe të lini komente në rreshtat e paprekur.
Ekzekutimi i punëve specifike për merge request vetëm kur ndryshohen skedarë të caktuar
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Në GitLab 11.6 u shtua mundësia për të përcaktuar për punët në pipelines, kështu që përdoruesit mund të ekzekutojnë detyra specifike vetëm kur krijohet një merge request.
Tani ne zgjerrojmë këtë funksionalitet: është shtuar logjika lidhëse , dhe përdoruesit mund të ekzekutojnë punë specifike vetëm për merge request dhe vetëm kur ndryshohen skedarë të caktuar.
Faleminderit për kontributin Hiroyuki Sato ()!
Monitorimi automatik i GitLab me Grafana
(CORE, STARTER, PREMIUM, ULTIMATE)
Grafana tani është përfshirë në paketën tonë Omnibus, duke e bërë më të lehtë kuptimin e funksionimit të instancës tuaj.
Konfiguroni grafana['enable'] = true nĂ« gitlab.rb, dhe Grafana do tĂ« jetĂ« e ĐŽĐŸŃŃŃĐżĐœĐ° nĂ« adresĂ«n: https://your.gitlab.instance/-/grafana. NĂ« tĂ« ardhmen e afĂ«rt ne gjithashtu «siç e merrni».
Shikimi i epikëve të parë në anën e panelit të epikëve
(ULTIMATE, GOLD)
Kohët e fundit prezantuam , duke lejuar përdorimin e epikëve të epikëve.
Në GitLab 11.9, ne e simplifikuam mekanizmin e shikimit të kësaj ndërlidhjeje. Tani shihen jo vetëm epiku prind i epikut të caktuar, por e gjithë struktura e epikëve në anën e panelit të djathtë. Mund të shihni nëse këta epikë janë të mbyllur apo jo, dhe madje të kaloni direkt tek ata.
Linku në një detyrë të re nga një detyrë e lëvizur dhe e mbyllur
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Në GitLab është e lehtë të lëvizni një detyrë në një projekt tjetër përmes panelit të djathtë ose veprimit të shpejtë. Pas skenës, detyra ekzistuese mbyllet dhe në projektin e synuar krijohet një detyrë e re me të gjitha të dhënat e kopjuara, duke përfshirë shënimet sistemike dhe atributet e panelit. Kjo është një veçori e shkëlqyer.
Duke marrë parasysh se ka një shënim sistematik për zhvendosjen, përdoruesit, kur shikojnë një çështje të mbyllur, ndihen të hutuar: nuk mund të kuptojnë se çështja është e mbyllur për shkak të zhvendosjes.
Në këtë version, ne tregojmë një shenjë në pjesën e sipërme të faqes së çështjes të mbyllur që tregon se është zhvendosur, si dhe përfshijmë një lidhje të integruar për çështjen e re, në mënyrë që kushdo që ka mbërritur në të vjetrën të mund të kalojë shpejt në të re.
Integrimi YouTrack
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
GitLab integrohet me shumë sisteme të jashtme të ndjekjes së çështjeve, duke u lehtësuar grupeve përdorimin e GitLab për funksione të tjera, duke mbajtur ende mjetin e tyre të zgjedhur për menaxhimin e çështjeve.
Në këtë version, ne kemi shtuar mundësinë e integrimit YouTrack nga JetBrains.
Faleminderit për kontributin e Kotau Yauhen ()!
Ndryshimi i madhësisë së pemës së skedarëve të kërkesës për bashkim
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Gjatë shikimit të ndryshimeve të kërkesës për bashkim, tani mund të ndryshoni madhësinë e pemës së skedarëve për të shfaqur emra të gjatë skedarësh ose për të kursyer hapësirë në ekrane të vogla.
Shkalla në panelin më të fundit të çështjeve
(STARTER, PREMIUM, ULTIMATE, BRONZE, SILVER, GOLD)
Panelat e detyrave janë shumë të dobishme, dhe ekipet krijojnë disa panele për çdo projekt dhe grup. Së fundi, kemi shtuar një panel kërkimi për të filtruar shpejt të gjitha panelet që ju interesojnë.
Në GitLab 11.9 ne gjithashtu prezantuam seksionin E fundit në listën e rënies. Kështu, mund të kaloni shpejt në panelet me të cilat keni ndërvepruar së fundmi.
Mundësia për të krijuar degë të mbrojtura nga zhvilluesit
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Degët e mbrojtura nuk lejojnë lëvizjen ose bashkimin e kodit të pa rishikuar. Megjithatë, nëse askujt nuk i lejohet të lëvizë degët e mbrojtura, atëherë askush nuk mund të krijojë një degë të re të mbrojtur: për shembull, një degë lëshimi.
NĂ« GitLab 11.9, zhvilluesit mund tĂ« krijojnĂ« degĂ« tĂ« mbrojtura nga degĂ«t qĂ« janĂ« tashmĂ« tĂ« mbrojtura nĂ«pĂ«rmjet GitLab ose API. PĂ«rdorimi i Git pĂ«r lĂ«vizjen e njĂ« dege tĂ« re tĂ« mbrojtur Ă«shtĂ« akoma i kufizuar â pĂ«r tĂ« mos krijuar rastĂ«sisht degĂ« tĂ« reja tĂ« mbrojtura.
Deduplication e objekteve Git për degë të hapura (Beta)
(CORE, STARTER, PREMIUM, ULTIMATE)
Pjesa e derdhjes lejon çdokënd të angazhohet në projekte me kod të hapur: pa autorizim për të shkruar, thjesht duke kopjuar depozitën në një projekt të ri. Ruajtja e kopjeve të plota të depozitave të shpërndara shpesh është e paefikas. Tani me Git alternatives derdhjet ndajnë objekte të përbashkëta nga projekti i lartpërmendur në grupin e objekteve, për të reduktuar kërkesat për ruajtjen e diskut.
Grupet e objekteve për derdhjet krijohen vetëm për projekte të hapura, nëse është e lidhur një ruajtje me hash. Grupi i objekteve aktivizohet me parametrin e funksionit object_pools.
Filtrimi i listës së kërkesave për integrim sipas personave të caktuar për miratim
(STARTER, PREMIUM, ULTIMATE, BRONZE, SILVER, GOLD)
Rishikimi i kodit është një praktikë e zakonshme për çdo projekt të suksesshëm, por rishikuesit ndonjëherë e kanë të vështirë të ndjekin kërkesat për integrim.
Në GitLab 11.9, lista e kërkesave për integrim filtrohet sipas personit të caktuar për miratim. Kështu, mund të gjeni kërkesat për integrim të përcaktuara për ju si rishikues.
Faleminderit për kontributin e Glavin Wiechert ()!
Shkurtore për skedarin e ardhshëm dhe të kaluar në kërkesën për integrim
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Duke hidhni një vështrim në ndryshimet e merdzh-rekquestit, mund të kaloni shpejt mes skedarëve duke përdorur ]ose j për të kaluar në skedarin e ardhshëm dhe [ ose k për të kaluar në skedarin e mëparshëm.
Thjeshtimi .gitlab-ci.yml për projektet serverless
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Krijuar mbi funksionalitetin e GitLab CI, shablloni serverless gitlab-ci.yml është thjeshtuar ndjeshëm. Për të futur funksionalitete të reja në lëshime të ardhshme, nuk është e nevojshme të bëni ndryshime në këtë skedar.
Mbështetje për emrat e hosteve Ingress
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Gjatë desplejimit të kontrolluesit Kubernetes Ingress disa platforma kthehen në adresën IP (p.sh., GKE nga Google), ndërsa të tjera në emrin DNS (p.sh., EKS nga AWS).
Integrimi ynë Kubernetes tani mbështet të dy llojet e pikave të fundit për t'u shfaqur në seksionin clusters projektit.
Faleminderit për kontributin e Aaron Walker ()!
Kufizimi i aksesit në JupyterHub vetëm për anëtarët e grupit/projektit
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Deployimi i JupyterHub me integrimin e GitLab me Kubernetes është një mënyrë e shkëlqyer për të menaxhuar dhe përdorur Jupyter Notebook në grupe të mëdha. Gjithashtu, është e dobishme për të monitoruar qasjen në to kur ndahen të dhëna konfidenciale ose personale.
Në GitLab 11.9, mundësia e hyrjes në instancat JupyterHub të implementuara përmes Kubernetes është e kufizuar për anëtarët e projektit me nivelin e aksesit "zhvillues" (përmes grupit ose projektit).
Intervale kohore të personalizueshme për skemën e panelit të sigurisë
(ULTIMATE, GOLD)
Panairi i sigurisë së grupit përfshin një skemë të dobësive për pasqyrimin e statusit aktual të sigurisë së projekteve të grupit. Kjo është shumë e dobishme për drejtorët e sigurisë për të rregulluar proceset dhe për të kuptuar mekanizmin e punës së ekipit.
Në GitLab 11.9 tani mund të zgjidhni një interval kohor për këtë skemë dobesie. Në mënyrë default, është 90 ditët e fundit, por mund të vendosni një interval prej 60 ose 30 ditësh, në varësi të nivelit të nevojshëm të detajimit.
Kjo nuk ndikon në të dhënat në numërues ose në listë, vetëm në pikët e të dhënave që shfaqen në skemë.
Shtimi i një pune ndërtimi Auto DevOps për etiketat
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Faza e ndërtimit automatik Auto DevOps krijon ndërtimin e aplikacionit tuaj duke përdorur Dockerfile-në e projektit ose paketën e ndërtimit Heroku.
Në GitLab 11.9, imazhi Docker i marrë, i integruar në pipeline-et e etiketimeve, merr një emër në përputhje me emrat tradicionalë të imazheve duke përdorur etiketat e komiteve në vend të SHA-ve të komiteve.
Faleminderit për kontributin e Aaron Walker!
Përditësimi i Code Climate në versionin 0.83.0
(STARTER, PREMIUM, ULTIMATE, BRONZE, SILVER, GOLD)
GitLab përdor për të kontrolluar se si ndryshimet ndikojnë në gjendjen e kodit tuaj dhe projektit.
Në GitLab 11.9, ne përditësuam motorin në versionin më të fundit (), për të ofruar avantazhet e gjuhës shtesë dhe mbështetjes për analizën statike për Cilësinë e Kodit të GitLab.
Faleminderit për kontributin e anëtarit të ekipit të GitLab Core Takuya Noguchi ()!
Shkallëzimi dhe rrotullimi i panelit të metrikave
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Kur shqyrtoni anomalitë e performancës, shpesh është e dobishme të shikoni më ngushtë pjesët e veçanta të një metrike të caktuar.
Me GitLab 11.9, përdoruesit do të jenë në gjendje të shkallëzojnë periudha të veçanta kohore në panelin e metrikave, të rrotullojnë të gjithë intervalin kohor, si dhe të kthehen lehtësisht në pamjen e intervalit të origjinës. Kjo lejon të hetohet lehtësisht dhe shpejt ngjarjet e nevojshme.
SAST për TypeScript
(ULTIMATE, GOLD)
â Ă«shtĂ« njĂ« gjuhĂ« programimi relativisht e re bazuar nĂ« .
Në GitLab 11.9, funksioni i Testimit Statik të Sigurisë së Aplikacioneve (SAST) analizon dhe zbulon dobësi në kodin TypeScript, duke i paraqitur ato në widget-in e kërkesës për bashkim, në nivelin e pipeline-it dhe në panelin e sigurisë. Përcaktimi aktual i punës sast nuk ka nevojë të ndryshohet, dhe ai është gjithashtu automatikisht i aktivizuar në .
SAST për projekte shumëmodulare Maven
(ULTIMATE, GOLD)
Projektet Maven shpesh organizohen për të kombinuar në një depo. Më parë, GitLab nuk mund të skanonte saktësisht këto projekte, dhe zhvilluesit dhe specialistët e sigurisë nuk merrnin raporte për dobësitë.
GitLab 11.9 ofron mbështetje të zgjeruar për funksionin SAST për këtë konfigurim specifik projekti, duke mundësuar testimin e tyre për dobësi në gjendjen e tyre origjinale. Falë fleksibilitetit të analizuesve, konfigurimi përcaktohet automatikisht dhe nuk keni nevojë të ndryshoni asgjë për të parë rezultatet për aplikacionet shumëmodulare Maven. Si zakonisht, përmirësime të ngjashme janë gjithashtu të disponueshme brenda .
GitLab Runner 11.9
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Sot gjithashtu lëshuam GitLab Runner 11.9! GitLab Runner është një projekt me kod të hapur dhe përdoret për të ekzekutuar detyra CI/CD dhe për të dërguar rezultatet përsëri në GitLab.
Më poshtë janë disa ndryshime në GitLab Runner 11.9:
- .
- dhe .
- . Kjo gjithashtu .
- për mbështetje , që do të shfaqen në GitLab 11.10.
- .
- .
- Kaldhizimi i disa skenarĂ«ve â duke pĂ«rfshirĂ« dhe â nĂ« Go.
- .
- .
- .
Listën e plotë të ndryshimeve mund ta gjeni në regjistrin e ndryshimeve të GitLab Runner: .
Përmirësime në skemën e GitLab
(CORE, STARTER, PREMIUM, ULTIMATE)
Në diagramin GitLab janë bërë këto përmirësime:
- ĂshtĂ« shtuar mbĂ«shtetje pĂ«r Google Cloud Memorystore.
- Cilësimet e Cron job , pasi ato përdoren nga disa shërbime.
- Regjistri është përmirësuar në versionin 2.7.1.
- ĂshtĂ« shtuar njĂ« parameter i ri qĂ« siguron kompatibilitetin e regjistrit GitLab me versionet Docker deri nĂ« 1.10. PĂ«r ta aktivizuar vendosni
registry.compatibility.schema1.enabled: true.
Përmirësimi i performancës
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Ne vazhdojmë të përmirësojmë performancën e GitLab me çdo lëshim për instancat e GitLab të çdo madhësie. Ja disa përmirësime në GitLab 11.9:
- .
- .
- .
- .
Përmirësime Omnibus
(CORE, STARTER, PREMIUM, ULTIMATE)
Në GitLab 11.9 janë bërë këto përmirësime Omnibus:
- GitLab 11.9 përfshin , , në lëshimin e fundit të të cilit përfshihen MFA për Team Edition, rritja e performancës së imazheve dhe shumë më tepër. Ky version gjithashtu përfshin ; përditësimi rekomandohet.
- ĂshtĂ« shtuar njĂ« parameter i ri qĂ« siguron kompatibilitetin e regjistrit GitLab me versionet Docker deri nĂ« 1.10. PĂ«r ta aktivizuar vendosni
registry['compatibility_schema1_enabled'] = true në gitlab.rb. - Rejstri GitLab tani eksporton metrikat Prometheus dhe monitorohet automatikisht me .
- U shtua mbështetje për Google Cloud Memorystore, që kërkon .
opensslu pĂ«rmirĂ«sua nĂ« versionin 1.0.2r,nginxâ nĂ« versionin 1.14.2,pythonâ nĂ« versionin 3.4.9,jemallocâ nĂ« versionin 5.1.0,docutilsâ nĂ« versionin 0.13.1,gitlab-monitorâ nĂ« versionin 3.2.0.
Karakteristika të vjetra
GitLab Geo do të sigurojë ruajtje të shënuar në GitLab 12.0
GitLab Geo kërkon për të zbutur garën (race condition) në nodet sekondare. Kjo u shënua në .
Në GitLab kemi shtuar këtë kërkesë në dokumentacionin Geo: .
Në GitLab sudo gitlab-rake gitlab: geo: check kontrollon nëse ruajtja e shënuar është aktivizuar dhe nëse të gjitha projektet po transferohen. Shih. . Nëse përdorni Geo, ju lutemi kryeni këtë kontroll dhe migroni sa më shpejt që të jetë e mundur.
NĂ« GitLab njoftim i pĂ«rhershĂ«m i çaktivizuar do tĂ« shfaqet nĂ« faqen Admin Area âș Geo âș Nodes, nĂ«se kontrollimet e sipĂ«rpĂ«rmendura nuk janĂ« tĂ« lejuara.
Në GitLab Geo do të përdorë kërkesat për ruajtjen e shënuar. Shih. .
Data e fshirjes: 22 qershor 2019.
Integrimi Hipchat
Hipchat . Për më tepër, në versionin 11.9 .
Data e fshirjes: 22 mars 2019
Mbështetje për CentOS 6 për GitLab Runner me ndihmën e Docker executor
GitLab Runner nuk mbështet CentOS 6 kur përdoret Docker në GitLab 11.9. Kjo është pasojë e përditësimit të bibliotekës bazë të Docker, e cila nuk mbështet më CentOS 6. Më shumë informacion shihni në .
Data e fshirjes: 22 mars 2019
Rrugët e vjetra (legacy) të kodit të GitLab Runner
Duke filluar nga GitLab 11.9, GitLab Runner përdor për klonimin/thirrjen e depozitës. Aktualisht, GitLab Runner do të vazhdojë të përdorë metodën e vjetër nëse e reja nuk mbështetet.
Në GitLab 11.0 kemi ndryshuar pamjen e konfigurimit të serverit të metrikeve për GitLab Runner. metrics_server do të hiqet në favor të listen_address në GitLab 12.0. Më shumë informacion shihni në . Dhe disa detaje në .
Në versionin 11.3, GitLab Runner filloi të mbështesë , çka solli konfigurime të reja për . Në është paraqitur një tabelë ndryshimesh dhe udhëzime për kalimin në konfigurim të ri. Më shumë informacion shihni në .
Këto rrugë nuk janë më të disponueshme në GitLab 12.0. Si përdorues, nuk keni nevojë të ndryshoni asgjë, vetëm sigurohuni që instance GitLab të funksionojë me versionin 11.9+ kur azhurnoni në GitLab Runner 12.0.
Data e fshirjes: 22 qershor 2019.
Parametri i vjetëruar për tipin e hyrjes për GitLab Runner
Në versionin 11.4 GitLab Runner është prezantuar me parametrin e funksionit për të korrigjuar probleme të tilla si dhe .
Në GitLab 12.0 ne do të kalojmë në një sjellje të saktë, siç do të ishte nëse parameteri i funksionit ishte i çaktivizuar. Më shumë informacion mund të gjeni në .
Data e fshirjes: 22 qershor 2019.
Mbështetje e vjetëruar për distribucione Linux që kanë arritur EOL për GitLab Runner
Disa distribucione Linux që mund të instaloni GitLab Runner kanë përfunduar jetëgjatësinë e tyre.
Në GitLab 12.0, GitLab Runner nuk do të shpërndajë më paketa për këto distribucione Linux. Një listë e plotë e distribucioneve që nuk mbështeten më mund të gjendet në . Falenderime Javier Ardo () për kontributin e tij !
Data e fshirjes: 22 qershor 2019.
Hiqni komandat e vjetra të GitLab Runner Helper
Si pjesë e përpjekjeve për mbështetje duhet hequr dorë nga disa komanda të vjetra që përdoren për .
Në GitLab 12.0, GitLab Runner ekzekutohet me komanda të reja. Kjo prek vetëm përdoruesit që riaktivizojnë . Më shumë informacion mund të gjeni në .
Data e fshirjes: 22 qershor 2019.
Zhvilluesit mund të fshijnë etiketat Git në GitLab 11.10
Fshirja ose editimi i shënimeve për versionet e etiketave Git në degët e papranuara historikisht është kufizuar vetëm te .
Në GitLab 11.10, zhvilluesit do të jenë në gjendje të fshijnë etiketat Git, pasi ata mund të shtojnë etiketa, si dhe të modifikojnë dhe fshijnë degët e pa mbrojtura. në modelin tonë të lejeve për të përmirësuar fluksin e punës dhe për të ndihmuar zhvilluesit të përdorin etiketat më mirë dhe më efektivisht.
Nëse dëshironi të ruani këtë kufizim për mbajtësit dhe pronarët, përdorni .
Data e fshirjes: 22 prill 2019
Mbështetje për Prometheus 1.x në Omnibus GitLab
Duke filluar nga GitLab , versioni e integruar i Prometheus 1.0 është eliminuar nga Omnibus GitLab. . Megjithatë, formati i metrikeve nuk është i pajtueshëm me versionin 1.0. Versionet ekzistuese mund të përditësohen në 2.0 dhe, nëse është e nevojshme, të transferohen .
Në versionin e GitLab Prometheus 2.0 do të instalohen automatikisht, nëse nuk janë bërë përditësime. Të dhënat nga Prometheus 1.0 do të humbasin, duke qenë se nuk do të transferohen.
Data e fshirjes: 22 qershor 2019.
TLS v1.1
Duke filluar nga GitLab pĂ«r tĂ« pĂ«rmirĂ«suar sigurinĂ«. Kjo eliminon shumĂ« probleme, duke pĂ«rfshirĂ« Heartbleed, dhe e bĂ«n GitLab ânga kutiaâ tĂ« pajtueshĂ«m me standardin PCI DSS 3.1.
Për ta çaktivizuar menjëherë TLS v1.1, vendosni nginx['ssl_protocols'] = "TLSv1.2" në gitlab.rband dhe filloni gitlab-ctl rikonfiguroni.
Data e fshirjes: 22 qershor 2019.
Shablloni OpenShift për instalimin e GitLab
Zyrtare - metoda e rekomanduar për përdorimin e GitLab në Kubernetes, përfshirë .
për instalimin e GitLab është i vjetruar dhe nuk do të mbështetet më në .
Data e fshirjes: 22 qershor 2019.
Përcaktimet e mëparshme të punëve të sigurisë
Me hyrjen e cdo përcaktim i mëparshëm i punëve do të jetë i vjetruar dhe do të hiqet në GitLab 12.0 ose më vonë.
Përditësoni përcaktimet e punëve për të përdorur sintaksin e re dhe për të shfrytëzuar të gjitha veçoritë e reja të sigurisë, të ofruara nga GitLab.
Data e heqjes: 22 qershor 2019.
Sekcioni Informacioni i Sistemit në panelin e administratorit
GitLab paraqet informacion rreth instancës suaj të GitLab në admin/system_info, por ky informacion mund të jetë i pasaktë.
Ne të panelit të administratorit në GitLab 12.0 dhe rekomandojmë përdorimin e .
Data e fshirjes: 22 qershor 2019.
Burimi: habr.com
