Shkaktari i shpejtë i rrjedhjeve të sekreteve
Duket si një gabim i vogël — të dërgosh aksidentalisht kredencialet në një depotë të përbashkët. Megjithatë, pasojat mund të jenë serioze. Sapo një keqbërës të marrë fjalëkalimin tuaj ose çelësin API, ai do të pushtojë llogarinë tuaj, do t'ju bllokojë dhe do t'i përdorë paratë në mënyrë mashtruese. Për më tepër, efekti domino mund të ndodhi: qasja në një llogari hap qasje në të tjera. Rreziku është i lartë, prandaj është jashtëzakonisht e rëndësishme të zbuloni një rrjedhje sekretesh sa më shpejt të jetë e mundur.
Në këtë version ofrojmë opsionin si pjesë e funksionalitetit tonë SAST. Çdo komit skanohet në detyrën CI/CD për sekrete. Ka një sekret — dhe zhvilluesi merr një paralajmërim në kërkesën për bashkim. Ai në vend e anulon kredencialet e rrjedhura dhe krijon të reja.
Sigurimi i menaxhimit të duhur të ndryshimeve
Me rritjen dhe komplikimin e organizatës, është gjithnjë e më e vështirë të mbash konsistencën midis pjesëve të ndryshme. Sa më shumë përdorues të ketë aplikacioni dhe sa më të lartë të jetë të ardhurat, aq më serioze janë pasojat e bashkimit të kodit të gabuar ose të pasigurt. Për shumë organizata, sigurimi i një procesi të duhur verifikimi para bashkimit të kodit është një kërkesë strikte, pasi rreziqet janë shumë të larta.
Në GitLab 11.9, më shumë kontroll dhe një strukturë më efektive — falë . Më parë, për të marrë miratim, ishte e mjaftueshme të përmendej një individ ose grup (secili anëtar mund të jepte miratimin). Tani është e mundur të shtohen disa rregulla, kështu që kërkesa për bashkim kërkon 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 karakteristika e Pronarëve të Kodit, e cila lehtëson identifikimin e individit që jep miratimin.
Kjo u mundëson organizatave të zbatojnë procese të ndërlikuara miratimi, duke mbajtur njëkohësisht thjeshtësinë e aplikacionit të vetëm GitLab, ku detyrat, kodi, pipeline dhe të dhënat e monitorimit janë të dukshme dhe të arritshme për marrjen e vendimeve dhe përshpejtimin e procesit të miratimit.
ChatOps tani ka një kod të hapur
GitLab ChatOps është një mjet efektiv automatizimi, i cili lejon ekzekutimin e çdo pune CI/CD dhe kërkimin e statusit të saj direkt në aplikacione të tilla bisedash si Slack dhe Mattermost. , ChatOps ishte pjesë e abonimit GitLab Ultimate. Duke u bazuar në и , ndonjëherë ne zhvendosim tiparet poshtë dhe kurrë lart.
Në rastin e ChatOps ne kuptuam se kjo funksionalitet mund të jetë e dobishme për të gjithë, dhe se pjesëmarrja e komunitetit mund të sjellë përfitime për vetë funksionalitetin.
Në GitLab 11.9 ne , dhe kështu, tani është falas e disponueshme për t'u përdorur në GitLab Core dhe në GitLab.com dhe është e hapur për komunitetin.
Dhe shumë më tepër!
Në këtë version ka shumë funksione të mrekullueshme: për shembull, , и , — prandaj mezi presim t'i tregojmë!
Punonjësi më i çmuar () i këtij muaji është njohur Marsel Amiro ()
Marsel vazhdoi të na ndihmojë për të përmirësuar dokumentacionin e GitLab. Ai për të rritur cilësinë dhe lehtësinë e përdorimit të dokumenteve tona. Domo arigato [faleminderit shumë (jap.) — shën. përkth.] Marsel, ne e vlerësojmë sinqerisht këtë!
Veçoritë kryesore të shtuara në versionin GitLab 11.9
Zbulimi i sekreteve dhe kredencialeve në depo
(ULTIMATE, GOLD)
Zhvilluesit ndonjëherë pa vetëdije i transferojnë sekrete dhe kredenciale në depo të largëta. Nëse njerëz të tjerë kanë qasje në këtë burim, ose nëse projekti është i hapur, informata konfidenciale publikohet dhe mund të përdoret nga aktorë të dëmshëm për qasje në burime të tilla si ambientet e dakordimit.
GitLab 11.9 ka një test të ri — “Detektimi i Sekreteve”. Ai skanon përmbajtjen e depozitës për çelësa API dhe informacione të tjera që nuk duhet të jenë këtu. GitLab tregon rezultatet në një raport SAST në widgetin e kërkesës për bashkim, raportet e pipeline dhe në panot e sigurisë.
Nëse tashmë keni aktivizuar SAST për aplikacionin tuaj, atëherë nuk keni nevojë të bëni asgjë, thjesht shfrytëzoni përfitimet e kësaj veçorie të re. Ajo gjithashtu është e përfshirë në konfigurim si të paracaktuar.
Rregullat e miratimit të kërkesave për bashkimin
(PREMIUM, ULTIMATE, SILVER, GOLD)
Rishikimi i kodit është një element thelbësor i çdo projekti të suksesshëm, por nuk është gjithmonë e qartë se kush duhet të merret me rishikimin e ndryshimeve. Shpesh është e dëshirueshme pjesëmarrja e rishikuesve nga ekipe të ndryshme: ekipi i zhvilluesve, ekipi i ndërveprimit me përdoruesit, ekipi prodhues.
Rregullat e miratimit lejojnë përmirësimin e procesit të ndërlidhjes mes personave që marrin pjesë në rishikimin e kodit: përcaktohet grupi i personave të autorizuar për miratim dhe numri minimal i miratimeve. Rregullat e miratimit paraqiten në widget-in e kërkesës për bashkim, kështu që mund të caktojmë shpejt rishikuesin e duhur.
Në GitLab 11.8 rregullat e miratimit ishin të çaktivizuara me parazgjidhje. Duke filluar nga versioni GitLab 11.9 ato janë në dispozicion si parazgjidhje. Në GitLab 11.3 ne kemi futur opsionin për të përcaktuar anëtarët e ekipit që janë përgjegjës për kode të veçanta brenda projektit. Funksioni Pronari i Kodit është i integruar në rregullat e miratimit, kështu që gjithmonë mund të gjeni shpejt njerëzit e nevojshëm për të rishikuar ndryshimet.
Shkarkimi i ChatOps në Core
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Fillimisht e futur në GitLab Ultimate 10.6, ChatOps është shkarkuar në GitLab Core. GitLab ChatOps ofron mundësinë për të ekzekutuar detyra GitLab CI përmes Slack me ndihmën e funksionit .
Ne po hapim kodin burimor të këtij funksioni në përputhje me . Duke u përdorur më shpesh, komuniteti do të kontribuojë më shumë.
Auditimi i parametrave të funksioneve
(PREMIUM, ULTIMATE, SILVER, GOLD)
Operacionet 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 ndodhi një ngjarje e papërshtatshme dhe dëshironi të shihni çfarë është ndryshuar kohët e fundit? Apo thjesht duhet të verifikoni si janë ndryshuar parametrat e funksioneve për qëllime auditi? Tani është shumë e lehtë ta bëni këtë.
Eliminimi i dobësive në kërkesat e bashkimit
(ULTIMATE, GOLD)
Për të eliminuar shpejt dobësitë në kod, procesi duhet të jetë i thjeshtë. Është e rëndësishme të thjeshtohet rregullimi i problemeve të sigurisë, duke lejuar zhvilluesit të përqendrohen në detyrat e drejtpërdrejta. Në GitLab 11.7 ne , por ajo duhet të ngarkohej, të aplikohej në nivelin lokal dhe më pas të transferoheshin ndryshimet në depozitat e largëta.
Në GitLab 11.9 ky proces është automatizuar. Rregulloni dobësitë pa u larguar nga ndërfaqja e uebit të GitLab. Një kërkesë për bashkim krijohet direkt nga dritarja e informacionit mbi dobësitë, dhe kjo degë e re do të përmbajë tashmë një rregullim. Pasi të keni verifikuar zgjidhjen e problemit, shtoni rregullimin në degën origjinale nëse pipeline është në rregull.
Të dhënat e skanimit të konteinerëve në panelin e sigurisë së grupit
(ULTIMATE, GOLD)
Paneleti i sigurisë së grupit lejon specialistët të përqendrohen në çështjet më të rëndësishme për punën, duke ofruar një përmbledhje të qartë dhe të detajuar të të gjitha dobësive të mundshme që mund të ndikojnë në aplikacionet. Kjo është arsyeja pse është e rëndësishme që paneli të përmbajë të gjitha informacionet e nevojshme në një vend dhe të lejojë përdoruesit të shkarkojnë të dhënat para se të rregullojnë dobësitë.
Në GitLab 11.9 rezultatet e skanimit të konteinerëve janë shtuar në panelin e instrumenteve, përveç rezultatve ekzistuese të SAST dhe skanimeve të varësive. Tani gjithë përmbledhja është në një vend, pa marrë parasysh burimin e problemit.
Modelet CI/CD për punët e sigurisë
(ULTIMATE, GOLD)
Funksionet e sigurisë të GitLab po evoluojnë shumë shpejt dhe kërkojnë vazhdimisht përditësime për të mbajtur efikasitetin dhe mbrojtjen e kodit. Të ndryshosh përkufizimin e punës është e vështirë, kur menaxhon disa projekte. Dhe ne gjithashtu e kuptojmë: askush nuk dëshiron të rrezikojë duke përdorur versionin më të fundit të GitLab pa qenë i sigurt për përputhshmërinë e saj 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 me anë të .
Duke filluar nga GitLab 11.9 do t'u ofrojmë shabllone të integruar për të gjitha punët e sigurisë: për shembull, sast и dependency_scanning, - të përputhshme me versionin përkatës të GitLab.
Shtoni ato direkt në konfigurimin tuaj, dhe ato do të përditësohen së bashku me sistemin në çdo përditësim në një version të ri të GitLab. Konfigurimet e pipeline nuk ndryshojnë në këtë rast.
Mënyra e re e përcaktimit të punëve të sigurisë është zyrtare dhe nuk mbështet përkufizime të tjera të mëparshme të punëve ose fragmente të kodit. Duhet të përditësohet sa më shpejt të jetë e mundur për të përdorur fjalën e re
template. Mbështetje për çdo sintaksë tjetër mund të hiqet në GitLab 12.0 ose në publikime 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ërdoruesi që shkruan komentarin fillestar duhet të vendosë që në fillim nëse i nevojitet diskutimi.
Ne e kemi lehtësuar këtë kufizim. Merrni çfarëdo komenti në GitLab (për detyra, kërkesa për bashkimin dhe epika) dhe përgjigjuni atij, duke filluar kështu diskutimin. Kështu ekipet ndërveprojnë më organizuar.
Shabllonat e projekteve për .NET, Go, iOS dhe Pages
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Për të lehtësuar krijimin e projekteve të reja për përdoruesit, ne ofrojmë disa shabllone të reja projekti:
- Fillestar , duke përfshirë një aplikacion bazë me CI.
- Shablloni i gatshëm për punë, duke kombinuar dhe GitLab CI/CD.
- , i gatshëm për personalizim fillestar në GitLab. Vini re se, pasi ndihmohet nga një runner i dedikuar MacOS, do t'ju duhet të ofroni serverin tuaj të ndërtimit, nëse dëshironi ta përdorni me GitLab CI/CD.
- janë konfiguruar për të punuar me Netlify.
Kërkoni miratim për kërkesat për bashkim nga Pronësitë e Kodit
(PREMIUM, ULTIMATE, SILVER, GOLD)
Nuk është gjithmonë e qartë se kush miraton kërkesën për bashkim.
Tani GitLab mbështet kërkesën për të miratuar kërkesat për bashkim, në varësi të skedareve që ndryshon kërkesa, përmes . Pronësitë e Kodit caktohen përmes një skedari të quajtur CODEOWNERS, formati është i ngjashëm me gitattributes.
Mbështetje për caktojnë automatikisht Pronësitë e Kodit si përgjegjës për miratimin e kërkesës për bashkimin është shtuar që në .
Lëvizja e skedarëve në Web IDE
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Tani, duke rinomuar një skedar ose katalog, mund ta lëvizni atë nga Web IDE në repozitorin në një rrugë të re.
Etiketat në rend alfabetik
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Etiketat e GitLab janë jashtëzakonisht universale, dhe ekipet vazhdojnë të gjejnë përdorime të reja për to. Kështu, përdoruesit shpesh shtojnë shumë etiketa në një detyrë, kërkesë për bashkimin ose epik.
Në GitLab 11.9, ne e kemi thjeshtuar pak përdorimin e etiketave. Në detyra, kërkesa për bashkimin dhe epika, etiketat që shfaqen në panelin anësor janë renditur alfabetikisht. Kjo i përfshin edhe shikimi i listës së këtyre objekteve.
Komentet e shpejta gjatë filtrimit të aktiviteteve sipas detyrës
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Kohë më parë, ne kemi introduktuar një veçori që përdoruesit të filtrojnë kanalin e aktiviteteve sipas detyrave, merge request-eve ose epikëve, duke lejuar kështu përqendrimin vetëm në komentet ose shënimet sistematike. Ky parametër ruhet për çdo përdorues në sistem, dhe ndonjëherë ndodh që përdoruesi të mos e kuptojë se, kur shikon një detyrë disa ditë më vonë, ai po sheh një kanal të filtruar. Të duket se nuk është e mundur të lësh një koment.
Ne e kemi përmirësuar këtë ndërveprim. Tani përdoruesit mund të kalojnë shpejt në një modalitet që u lejon atyre të lëshojnë komente pa e shikuar përsëri kanalin deri në krye. Kjo i përket detyrave, merge request-eve dhe epikëve.
Ndryshimi i rendit të epikëve fëmijë
(ULTIMATE, GOLD)
Kohë më parë, ne lançuam , të cilat lejojnë përdorimin e epikëve të epikëve (përveç detyrave fëmijë të epikëve).
Tani është e mundur të ndryshoni rendin e epikëve fëmijë përmes tërheqjes dhe tërheqjes, ashtu siç bëhet me detyrat fëmijë. Ekipet mund të përdorin rendin për të reflektuar prioritetin ose për të përcaktuar rendin e realizimit të punëve.
Mesazhet sistematike të përdoruesit për koken dhe fundin në internet dhe në email
(CORE, STARTER, PREMIUM, ULTIMATE)
Më parë, ne kemi shtuar një veçori që lejon mesazhet sistematike për koken dhe fundin të shfaqen në çdo faqe në GitLab. Ajo u prit me ngrohtësi, dhe ekipet e përdorin atë për të shpërndarë informacion të rëndësishëm: për shembull, mesazhe sistematike që lidhen me instancën e tyre të GitLab.
Ne jemi të lumtur ta prezantojmë këtë veçori në Core, kështu që tani mund ta përdorin edhe më shumë njerëz. Për më tepër, ne lejojmë përdoruesit të shfaqin me dëshirë të njëjtin mesazh në çdo email që dërgohet përmes GitLab, për të siguruar një qëndrim të njëjtë me pikën tjetër të ndërveprimit të përdoruesit me GitLab.
Filtri për detyrat konfidenciale
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Detyrat konfidenciale janë një mjet i dobishëm për ekipet, duke lejuar diskutime të mbyllura mbi tema delikate brenda një projekti të hapur. Në veçanti, ato janë ideale për të punuar mbi dobësitë e sigurisë. Deri tani, menaxhimi i detyrave konfidenciale nuk ka qenë shumë i lehtë.
Në GitLab 11.9, lista e detyrave në GitLab tani filtrohet sipas detyrave të besueshme ose të pabesueshme. Kjo ndikon gjithashtu në kërkimin e detyrave përmes API-së.
Faleminderit për kontributin e Robert Shillingut ()!
Editimi i domenit Knative pas shpërndarjes
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Caktimi i një domene të personalizuar gjatë instalimit të Knative lejon shërbimin e aplikacioneve/funksioneve të ndryshme pa server me një pikë përfundimtare unike.
Tani integrimi i Kubernetes në GitLab lejon ndryshimin përditësimin e domenit të personalizuar pas shpërndarjes së Knative në klasën Kubernetes.
Kontrolli i formatit të certifikatës CA të Kubernetes
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Duke shtuar një klasë ekzistuese Kubernetes, GitLab tani kontrollon që certifikata CA e dhënë ka një format të vlefshëm PEM. Kjo shmang gabimet e mundshme me integrimin e Kubernetes.
Zgjerimi i utilitarit të krahasimit të kërkesave për bashkim në të gjithë skedarin
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Duke shqyrtuar ndryshimet në kërkesën për bashkim, tani mund të zgjeroni utilitarin e krahasimit për çdo skedar për të treguar skedarin e plotë për më shumë kontekst dhe për të lënë komente në rreshtat e paprekura.
Ekzekutimi i detyrave specifike për kërkesat e bashkimit vetëm kur ndodhin ndryshime në skedarët e caktuar
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Në GitLab 11.6 u shtua mundësia për përcaktimin e për detyrat në pipelines, në mënyrë që përdoruesit të mund të ekzekutojnë detyra specifike vetëm gjatë krijimit të një kërkese për bashkim.
Tani ne po zgjeroni këtë funksionalitet: është shtuar logjika e lidhjes , dhe përdoruesit mund të ekzekutojnë detyra specifike vetëm për kërkesat e bashkimit dhe vetëm kur ndodhin ndryshime në skedarët e caktuar.
Faleminderit për kontributin e Hiroyuki Sato ()!
Monitorimi automatik i GitLab me Grafana
(CORE, STARTER, PREMIUM, ULTIMATE)
Grafana tani është pjesë e paketës sonë Omnibus, e cila e bën më të lehtë kuptimin e funksionimit të instancës tuaj.
Konfiguroni grafana['enable'] = true në gitlab.rb, dhe Grafana do të jetë e disponueshme në adresën: https://your.gitlab.instance/-/grafana. Në të ardhmen e afërt ne gjithashtu "nga kuti".
Shikimi i epikëve kryesorë në panelin anësor të epikëve
(ULTIMATE, GOLD)
Së fundmi ne prezantuam , që lejojnë përdorimin e epikëve të epikëve.
Në GitLab 11.9 ne kemi thjeshtuar mekanizmin për të parë këtë lidhje. Tani nuk është vetëm epiku amë i epikut të caktuar i dukshëm, por gjithashtu e gjithë pema e epikëve është e dukshme në panelin anësor të djathtë. Tani dallohet nëse këta epikë janë të mbyllur apo jo, dhe mund të kaloni direkt tek ata.
Lidhja me një detyrë të re nga një detyrë e transferuar dhe e mbyllur
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Në GitLab, është e lehtë të zhvendosësh një detyrë në projektin tjetër përmes panelit anësor ose një veprimi të shpejtë. Pas skenës, detyra ekzistuese mbyllet dhe në projektin e destinuar krijohet një detyrë e re me të gjithë të dhënat e kopjuara, përfshirë shënimet sistemore dhe atributet e panelit anësor. Kjo është një veçori e shkëlqyer.
Duke marrë parasysh se ka një shënim sistemor për zhvendosjen, përdoruesit, kur shikojnë një detyrë të mbyllur, ndihen të hutuar: nuk mund ta kuptojnë se detyra është mbyllur për shkak të zhvendosjes.
Në këtë version, tregojmë drejtpërdrejt në ikonën në krye të faqes së detyrës të mbyllur se ajo është zhvendosur, dhe përfundojmë me një lidhje të integruar për detyrën e re, në mënyrë që kushdo që ka hyrë në të vjetrën të mund të kalojë shpejt në të rejën.
Integrimi i YouTrack
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
GitLab integrohet me shumë sisteme të jashtme për ndjekjen e detyrave, duke e bërë më të lehtë për ekipet të përdorin GitLab për funksione të tjera ndërsa ruajnë mjetin e tyre të menaxhimit të detyrave të zgjedhura.
Në këtë version, ne shtuam mundësinë e integrimit të YouTrack nga JetBrains.
Faleminderit për kontributin e Kotau Yauhen ()!
Ndryshimi i madhësisë së pemës së skedarëve në merdž-reqest
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Kur shikoni ndryshimet e merdž-reqestit, tani është e mundur të ndryshoni madhësinë e pemës së skedarëve për të treguar emra skedarësh të gjatë ose për të kursyer hapësirë në ekranet e vogla.
Kalimi te panelat e fundit të detyrave
(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 panelat që ju interesojnë.
Në GitLab 11.9 gjithashtu prezantuam seksionin Recent në listën e rënies. Kështu, mund të kaloni shpejt në panele me të cilat keni ndërvepruar kohët e fundit.
Mundësia për zhvilluesit të krijojnë degë të mbrojtura
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Degët e mbrojtura nuk lejojnë zhvendosjen apo merdžimin e kodit të pa rishikuar. Sidoqoftë, nëse askujt nuk i lejohet të zhvendosë 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 e mbrojtura tashmë përmes GitLab ose API-së. Përdorimi i Git për të zhvendosur një degë të re të mbrojtur është ende i kufizuar — për të shmangur krijimin aksidental të degëve të reja të mbrojtura.
Deduplication of Git objects for open branches (Beta)
(CORE, STARTER, PREMIUM, ULTIMATE)
Branching allows anyone to participate in open source projects: without write permission, simply by copying the repository to a new project. Storing full copies of frequently branched Git repositories is inefficient. Now, using Git alternatives branches share common objects from the upstream project in the object pool to reduce disk storage requirements.
Object pools for branches are created only for open projects if a hashed storage is enabled. Object pools are enabled via the function parameter object_pools.
Filtering the list of merge requests by assigned approvers
(STARTER, PREMIUM, ULTIMATE, BRONZE, SILVER, GOLD)
Code review is a common practice for any successful project, but it can be challenging for a reviewer to track merge requests.
In GitLab 11.9, the list of merge requests is filtered by the assigned approver. This way, you can find merge requests assigned to you as a reviewer.
Thanks for the contribution of Glavin Wiechert ()!
Keyboard shortcuts for the next and previous file in the merge request
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
While reviewing changes in a merge request, you can quickly switch between files using ]или j to go to the next file and [ или k to go to the previous file.
Simplification .gitlab-ci.yml for serverless projects
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Created based on functionality GitLab CI, serverless template gitlab-ci.yml has been significantly simplified. To introduce new features in future releases, there is no need to modify this file.
Support for Ingress host names
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
During the deployment of the Kubernetes Ingress controller, some platforms revert to the IP address (e.g., GKE from Google), while others revert to the DNS name (e.g., EKS from AWS).
Our Kubernetes integration now supports both types of endpoints for display in the clusters project.
Thanks for the contribution of Aaron Walker ()!
Access restriction for JupyterHub login only for group/project members
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Deploying JupyterHub using GitLab's integration with Kubernetes is a great way to manage and use Jupyter Notebook in large groups. It is also useful to control access when sharing confidential or personal data.
Në GitLab 11.9, mundësia e hyrjes në instancat JupyterHub, të vendosura përmes Kubernetes, është e kufizuar për pjesëmarrësit e projektit me nivelin e aksesit "zhvillues" (nëpërmjet grupit ose projektit).
Intervalet e kohës së personalizuara për skemat e panelit të sigurisë
(ULTIMATE, GOLD)
Paneli i sigurisë së grupit përfshin një skemë të vulnerabiliteteve për të shqyrtuar statusin aktual të sigurisë së projekteve të grupit. Kjo është shumë e dobishme për drejtorët e sigurisë në përshtatjen e proceseve dhe kuptimin e mekanizmave të punës së ekipit.
Në GitLab 11.9 tani mund të zgjidhni intervalin kohor të kësaj skeme vulnerabilitetesh. Siç default, ky është 90 ditët e fundit, por mund të vendosni një periudhë prej 60 ose 30 ditëve, në varësi të nivelit të nevojshëm të detajeve.
Kjo nuk ndikon në të dhënat në numratorët ose në listë, vetëm në pikat e të dhënave që shfaqen në skemë.
Shtimi i një operatori ndërtimi Auto DevOps për etiketat
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Faza e ndërtimit automatik Auto DevOps krijon një ndërtim të 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-n e etiketave, merr një emër në përputhje me emrat tradicionale të imazheve duke përdorur etiketën e komitit në vend të SHA të komitit.
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 dhe projektit tuaj.
Në GitLab 11.9 kemi përditësuar motorin në versionin më të fundit (), për të ofruar avantazhet e gjuhës shtesë dhe mbështetjes së analizës statike për Cilësinë e Kodit GitLab.
Faleminderit për kontributin e anëtarit të ekipit GitLab Core Takuya Noguchi ()!
Shtimi dhe rrotullimi i panelit të metrikeve
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Kur hulumtoni anomali të performancës, shpesh është e dobishme të shikoni me vëmendje pjesët e veçanta të një metri të caktuar.
Me GitLab 11.9, përdoruesit do të jenë në gjendje të zmadhojnë periudha të veçanta të kohës në panelin e metrikeve, të rrotullojnë të gjithë intervalin kohor, si dhe lehtësisht të kthehen në pamjen e intervalit origjinal të kohës. Kjo lejon hulumtimin e lehtë dhe të shpejtë të ngjarjeve të nevojshme.
SAST për TypeScript
(ULTIMATE, GOLD)
është një gjuhë programimi relativisht e re e bazuar në .
Në GitLab 11.9, funksioni i Testimit të Sigurisë Statike të Aplikacionit (SAST) analizon dhe zbulon dobësitë në kodin TypeScript, duke i treguar ato në widgetin e kërkesës për bashkim, në nivelin e pipeline dhe në panelin e sigurisë. Përcaktimi aktual i punës sast nuk duhet të ndryshohet, dhe ajo gjithashtu aktivizohet automatikisht në .
SAST për projektet shumëmodul të Maven
(ULTIMATE, GOLD)
Projektet Maven shpesh organizohen që të bashkojnë në një repozitor. Më parë, GitLab nuk mund të skanonte saktë këto projekte, dhe zhvilluesit dhe specialistët e sigurisë nuk merrnin raporte mbi dobësitë.
GitLab 11.9 ofron mbështetje të zgjeruar për funksionin SAST për këtë konfigurim specifik projekti, duke e bërë të mundur testimin e tyre për dobësi në gjendjen burimore. Falë fleksibilitetit të analizuesve, konfigurimi përcaktohet automatikisht, dhe ju nuk duhet të ndryshoni asgjë për të parë rezultatet për aplikacionet shumëmodul të Maven. Ashtu si zakonisht, përmirësime të ngjashme janë gjithashtu në dispozicion brenda .
GitLab Runner 11.9
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Sot ne gjithashtu kemi lëshuar GitLab Runner 11.9! GitLab Runner është një projekt me kod të hapur dhe përdoret për të regjistruar detyra CI/CD dhe për të dërguar rezultatet prapa në GitLab.
Më poshtë janë disa ndryshime në GitLab Runner 11.9:
- .
- и .
- . Kjo gjithashtu .
- për mbështetje , që do të shfaqen në GitLab 11.10.
- .
- .
- Shkarkimi i disa skenarëve - duke përfshirë и - në Go.
- .
- .
- .
Lista e plotë e ndryshimeve mund të gjendet në regjistrin e ndryshimeve të GitLab Runner: .
Përmirësime të skemës GitLab
(CORE, STARTER, PREMIUM, ULTIMATE)
Në grafikun GitLab janë bërë përmirësime të mëposhtme:
- Shtuar mbështetje për Google Cloud Memorystore.
- Caktimet e punës Cron , sepse përdoren nga disa shërbime.
- Regjistri u përditësua në versionin 2.7.1.
- Shtuar 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 instanca GitLab të çdo madhësie. Ja disa përmirësime në GitLab 11.9:
- .
- .
- .
- .
Përmirësimet 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, përmirësim të performancës së imazheve dhe shumë më tepër. Ky version gjithashtu përfshin ; rekomandohet përditësimi.
- Shtuar 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. - Regjistri i GitLab tani eksporton metrikat Prometheus dhe kontrollohet automatikisht nga .
- Shtuar mbështetje për Google Cloud Memorystore, e cila kërkon .
openssle përditësuar 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.
Karakteristikat e vjetra
GitLab Geo do të sigurojë ruajtje të koduar në GitLab 12.0
GitLab Geo kërkon për të lehtësuar garën (race condition) në node të dytë. Kjo u vërejt në .
Në GitLab ne e shpallëm këtë kërkesë në dokumentacionin Geo: .
Në GitLab sudo gitlab-rake gitlab: geo: check kontrollon nëse ruajtja e koduar është e aktivizuar dhe nëse të gjithë projektet po transferohen. Shih. . Nëse po përdorni Geo, Ju lutemi, ekzekutoni këtë kontroll dhe migroni sa më shpejt të jetë e mundur.
Në GitLab në mënyrë të vazhdueshme të çaktivizuar paralajmërimi do të shfaqet në faqen Admin Area › Geo › Nodes, nëse kontrollimet e lartpërmendura nuk janë lejuar.
Në GitLab Geo do të përdorë kërkesat për ruajtje të koduar. Shih. .
Data e heqjes: 22 Qershor 2019.
Integrimi Hipchat
Hipchat . Për më tepër, në versionin 11.9 .
Data e heqjes: 22 Mars 2019.
Mbështetje për CentOS 6 për GitLab Runner me ndihmën e Docker executor
GitLab Runner nuk e mbështet CentOS 6, kur përdoret Docker në GitLab 11.9. Kjo është rezultat i përditësimit të bibliotekës themelore të Docker, e cila nuk e mbështet më CentOS 6. Më shumë informacion gjeni në .
Data e heqjes: 22 Mars 2019.
Rrugët e vjetra të kodit legacy të GitLab Runner
Deri me GitLab 11.9, GitLab Runner përdor për klonimin/thirrjen e repositorit. Aktualisht, GitLab Runner do të përdorë metodën e vjetër, nëse e reja nuk mbështetet.
Në GitLab 11.0 ne e ndryshuam formatin 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ë detaje gjeni në . Dhe më shumë detaje në .
Në versionin 11.3, GitLab Runner filloi të mbështesë , e cila çoi në konfigurime të reja për . Në të paraqitura në tabelën e ndryshimeve dhe udhëzimeve për kalimin në konfigurimin e ri. Më shumë informacion gjeni në .
Këto rrugë nuk janë më të disponueshme në GitLab 12.0. Si përdorues, nuk ju nevojitet të ndryshoni asgjë, vetëm sigurohuni që instanca e GitLab funksionon me versionin 11.9+ kur kaloni në GitLab Runner 12.0.
Data e heqjes: 22 Qershor 2019.
Parametri i vjetruar për funksionin e pikës hyrëse për GitLab Runner
Në 11.4, GitLab Runner prezanton parametrin e funksionit për të zgjidhur probleme të tilla si и .
Në GitLab 12.0 ne do të kalojmë në sjelljen e duhur, ashtu siç do të ishte parametri i funksionit i çaktivizuar. Më shumë informacion gjeni në .
Data e heqjes: 22 Qershor 2019.
Mbështetje e vjetër për shpërndarjet Linux që kanë arritur EOL për GitLab Runner
Disa shpërndarje Linux, në të cilat 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 në ato shpërndarje Linux. Lista e plotë e shpërndarjeve që nuk mbështeten më mund të gjendet në . Faleminderit Javier Ardo () për kontributin e tij. !
Data e heqjes: 22 Qershor 2019.
Në kuadër të përpjekjeve për të mbështetur
Windows Docker executor helper image .
. Më shumë informacion gjeni në Zhvilluesit mund të fshijnë etiketat Git në GitLab 11.10 .
Data e heqjes: 22 Qershor 2019.
Heqja ose redaktimi i shënimeve të versionit për etiketat Git në degët e pambrojtura historikisht ka qenë e kufizuar vetëm për
mbështetësit dhe pronarët. .
Për shkak se zhvilluesit mund të shtojnë etiketa, si dhe të ndryshojnë dhe fshijnë degë të pambrojtura, zhvilluesit duhet të kenë mundësinë të fshin etiketat Git. Në GitLab 11.10 në modelin tonë të lejeve për të përmirësuar fluksin e punës dhe për të ndihmuar zhvilluesit të përdorin më mirë dhe më efektivisht etiketat.
Nëse dëshironi të ruani këtë kufizim për mbikëqyrësit dhe pronarët, përdorni .
Data e heqjes: 22 prill 2019
Mbështetje për Prometheus 1.x në Omnibus GitLab
Deri me GitLab , versioni e integruar i Prometheus 1.0 është përjashtuar nga Omnibus GitLab. . Megjithatë, formati i metrikave nuk është në përputhje me versionin 1.0. Versionet ekzistuese mund të përditësohen në 2.0 dhe, nëse është e nevojshme, të transferohen të dhënat .
Në GitLab versioni do të instalohet automatikisht Prometheus 2.0, nëse nuk ka pasur përditësime. Të dhënat nga Prometheus 1.0 do të humbasin, pasi nuk do të transferohen.
Data e heqjes: 22 Qershor 2019.
TLS v1.1
Deri me GitLab për të rritur sigurinë. Kjo eliminon shumë probleme, përfshirë Heartbleed, dhe e bën GitLab ‘nga kutia’ përputhshëm me standardin PCI DSS 3.1.
Për të çaktivizuar menjëherë TLS v1.1, vendosni nginx['ssl_protocols'] = "TLSv1.2" në gitlab.rband dhe nisni gitlab-ctl reconfigure.
Data e heqjes: 22 Qershor 2019.
Shablloni OpenShift për instalimin e GitLab
Zyrtar — metoda e rekomanduar për funksionimin e GitLab në Kubernetes, duke përfshirë .
për instalimin e GitLab është i vjetruar dhe nuk do të mbështetet më në .
Data e heqjes: 22 Qershor 2019.
Definimet e mëparshme të punëve të sigurisë
Me përmirësimin e të gjitha definimet e mëparshme të punëve do të bëhen të vjetruara dhe do të fshihen në GitLab 12.0 ose më vonë.
Përditësoni definimet e punëve për të përdorur sintaksën e re dhe për të shfrytëzuar të gjitha veçoritë e reja të sigurisë që ofron GitLab.
Data e fshirjes: 22 qershor 2019.
Sekcioni Informacione mbi Sistemin në panelin e administratorit
GitLab paraqet informacionin 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ë të përdorni .
Data e heqjes: 22 Qershor 2019.
Burimi: habr.com
