Ang release 13.4 ay inilabas na may HashiCorp storage para sa mga variable ng CI, Kubernetes Agent at security center, pati na rin ang mga switchable na feature sa Starter
Sa GitLab, lagi naming iniisip kung paano namin matutulungan ang mga user na bawasan ang panganib, pagbutihin ang kahusayan, at pagbutihin ang bilis ng paghahatid sa iyong paboritong platform. Sa buwang ito, nagdagdag kami ng maraming kapaki-pakinabang na bagong feature na nagpapalawak ng mga kakayahan sa seguridad, nagpapababa ng bilang ng mga kahinaan, nagpapataas ng kahusayan, nagpapasimple sa pagtatrabaho sa GitLab, at tumutulong sa iyong team na maghatid ng mga feature nang mas mabilis. Umaasa kami na makikita mo ang mga pangunahing tampok ng paglabas na kapaki-pakinabang, pati na rin 53 iba pang mga bagong tampok, idinagdag sa release na ito.
Advanced na Mga Tampok ng Seguridad
Sinusubukan naming magdagdag ng ilang bagong feature sa GitLab DevSecOps bawat buwan, at ang release na ito ay walang exception. sa loob ng balangkas ng pagpupulong at pag-deploy. Bukod pa rito, maaari na ngayong suportahan ng mga organisasyong gustong suportahan ang paghihiwalay ng mga responsibilidad sa pag-deploy ng code . Ang papel na ito ay tumutugma at magbibigay-daan sa iyong kumpirmahin ang mga kahilingan sa pagsasanib (sa Russian localization ng GitLab na "mga kahilingan sa pagsasanib") at pag-deploy ng code sa mga protektadong kapaligiran, nang hindi nagbibigay ng access upang baguhin ang mismong code.
Ang isa pang paraan upang mabawasan ang mga panganib ay ang paggamit ng bago . Maaaring mag-deploy ang mga operations team ng mga Kubernetes cluster mula sa GitLab nang hindi kinakailangang ilantad ang kanilang cluster sa buong internet. Ipinapakilala din namin ang awtomatikong suporta sa pagkontrol ng bersyon para sa mga bagong Terraform state file na may upang suportahan ang pagsunod at kadalian sa pag-debug. Sa wakas, naging instance security dashboard na may mga ulat sa kahinaan at mga setting ng seguridad.
Mas maginhawa at mahusay na trabaho sa GitLab
Pinahusay namin ang aming pandaigdigang paghahanap upang maisama , na nagbibigay-daan sa iyong madaling mag-navigate sa pinakabagong mga tiket, grupo, proyekto, setting at paksa ng tulong. Nasasabik kaming ipahayag ang GitLab Pages na iyon upang i-redirect ang mga indibidwal na pahina at direktoryo sa loob ng site, na magbibigay-daan sa mga user na mas mahusay na i-deploy ang kanilang mga site. At para sa mga gustong makatanggap ng pinalawak na impormasyon tungkol sa deployment, pinapayagan ng release na ito !
Mga Kontribusyon sa Open Source
Kinakatawan namin na idinagdag ko . Ang mga marka sa saklaw ng unit test ng binagong code ay nagbibigay sa mga developer ng malinaw na ideya ng saklaw ng code sa panahon ng pagsusuri; nakakatulong ang impormasyong ito na mapabilis ang mga pagsusuri at bawasan ang oras para sa pagsasama at pag-deploy ng bagong code. At kami din at plano .
At ito ay simula pa lamang!
Gaya ng nakasanayan, napakaliit ng espasyo sa pangkalahatang pangkalahatang-ideya, ngunit maraming cool na feature sa 13.4 release. Narito ang ilan pa:
- .
Kung gusto mong malaman nang maaga kung ano ang naghihintay sa iyo sa susunod bitawan mo, tingnan mo .
.
sa buwang ito -
Malaki ang naiambag ni Fabio Π² - isang feature na matagal nang hinihintay sa komunidad ng GitLab. Ito ay isang tunay na mahalagang kontribusyon na may mga hindi maliit na pagbabago na nangangailangan ng patuloy na pakikipagtulungan sa mga miyembro ng koponan ng GitLab at nakaapekto sa maraming bahagi ng proyekto tulad ng UX, front-end at back-end.
Mga pangunahing tampok ng paglabas ng GitLab 13.4
Gamitin ang mga HashiCorp Vault key sa mga trabaho sa CI
(PREMIUM, ULTIMATE, SILVER, GOLD)
Sa release 12.10, ipinakilala ng GitLab ang kakayahang tumanggap at maglipat ng mga susi sa mga trabaho sa CI gamit ang GitLab job handler (GitLab runner). Ngayon kami ay lumalawak , pagdaragdag ng bagong syntax secrets mag-file .gitlab-ci.yml. Gagawin nitong mas madali ang pag-set up at paggamit ng repositoryo ng HashiCorp sa GitLab.
ΠΈ .
Ipinapakilala ang GitLab Kubernetes Agent
(PREMIUM, ULTIMATE)
Ang pagsasama ng GitLab sa Kubernetes ay matagal nang naging posible na mag-deploy sa mga kumpol ng Kubernetes nang hindi nangangailangan ng manu-manong pagsasaayos. Maraming mga gumagamit ang nagustuhan ang kadalian ng paggamit ng bundle na ito, habang ang iba ay nakaranas ng ilang mga paghihirap. Para sa kasalukuyang pagsasama, dapat na ma-access ang iyong cluster mula sa Internet upang ma-access ito ng GitLab. Para sa maraming organisasyon, hindi ito posible dahil pinaghihigpitan nila ang pag-access sa mga cluster para sa seguridad, pagsunod, o mga kadahilanang pang-regulasyon. Upang malampasan ang mga paghihigpit na ito, kailangan ng mga user na buuin ang kanilang mga tool sa ibabaw ng GitLab, kung hindi, hindi nila magagamit ang feature na ito.
Ngayon ay ipinapakilala namin ang GitLab Kubernetes Agent, isang bagong paraan para mag-deploy sa mga cluster ng Kubernetes. Ang ahente ay tumatakbo sa loob ng iyong cluster, kaya hindi mo kailangang ilantad ito sa buong Internet. Ang ahente ay nag-coordinate ng deployment sa pamamagitan ng paghiling ng mga bagong pagbabago mula sa GitLab, sa halip na ang GitLab na itulak ang mga update sa cluster. Anuman ang paraan ng GitOps na ginagamit mo, sakop ka ng GitLab.
Pakitandaan na ito ang unang paglabas ng ahente. Ang aming kasalukuyang focus para sa GitLab Kubernetes Agent ay i-configure at pamahalaan ang mga deployment sa pamamagitan ng code. Hindi pa sinusuportahan ang ilang umiiral nang feature ng integration ng Kubernetes, gaya ng mga deployment board at mga pinamamahalaang application ng GitLab. na ang mga kakayahang ito ay idaragdag sa ahente sa mga susunod na release, pati na rin ang mga bagong integrasyon na nakatuon sa seguridad at pagsunod.
ΠΈ .
Bigyan ang mga user ng mga pahintulot sa pag-deploy nang walang access sa code
(PREMIUM, ULTIMATE, SILVER, GOLD)
Dati, pinahirapan ng sistema ng mga pahintulot ng GitLab na maayos na hatiin ang mga responsibilidad sa loob ng iyong koponan sa pagitan ng mga responsable para sa pag-unlad at sa mga responsable para sa pag-deploy. Sa paglabas ng GitLab 13.4, maaari kang magbigay ng pahintulot na aprubahan ang mga kahilingan sa pag-merge para sa deployment, gayundin ang aktwal na pag-deploy ng code sa mga taong hindi sumusulat ng code, nang hindi binibigyan sila ng mga karapatan sa pag-access ng maintainer (sa Russian localization ng GitLab "maintainer" ).
ΠΈ .
Sentro ng seguridad
(ULTIMATE, GOLD)
Dati, ang pamamahala ng kahinaan sa antas ng halimbawa ay limitado sa parehong functionality at flexibility. Ang interface ay isang solong pahina na pinagsasama ang mga detalye ng mga kahinaan, mga graph ng sukatan, at mga setting. Walang gaanong puwang para bumuo ng mga feature na ito o gumamit ng iba pang feature ng seguridad.
Nakagawa kami ng mga pangunahing pagbabago sa kung paano namin pinamamahalaan ang seguridad at transparency sa GitLab. Ang panel ng seguridad ng halimbawa ay ginawang isang buong sentro ng seguridad. Ang pinakamalaking pagbabago ay ang pagpapakilala ng isang bagong istraktura ng menu: sa halip na isang pahina, makikita mo na ngayon ang dashboard ng seguridad, ulat sa kahinaan, at seksyon ng mga setting. Bagama't hindi nagbago ang functionality, ang paghahati-hati nito sa mga bahagi ay magbibigay-daan para sa mga pagpapabuti sa seksyong ito na kung hindi man ay magiging mahirap. Nagtatakda din ito ng yugto para sa pagdaragdag ng iba pang mga kakayahan na nauugnay sa seguridad sa hinaharap.
Ang nakalaang Vulnerability Report na seksyon ay mayroon na ngayong mas maraming espasyo upang ipakita ang mahahalagang detalye. Narito ang mga kahinaan na kasalukuyang nasa listahan ng mga kahinaan ng proyekto. Ang paglipat ng mga widget na may mga sukatan ng kahinaan sa isang hiwalay na seksyon ay lumilikha ng isang maginhawang control panel ng seguridad. Isa na itong canvas para sa mga visualization sa hinaharapβhindi lang para sa pamamahala ng kahinaan, ngunit para sa anumang sukatan na nauugnay sa seguridad. Sa wakas, ang isang hiwalay na lugar ng mga setting ay lumilikha ng isang karaniwang espasyo para sa lahat ng mga setting ng seguridad sa antas ng halimbawa, hindi lamang sa pamamahala ng kahinaan.
ΠΈ .
Nasa GitLab Starter na ngayon ang mga switchable na feature
(STARTER, PREMIUM, ULTIMATE, BRONZE, SILVER, GOLD)
Ang GitLab 11.4 ay inilabas . Sa 12.2 ipinakilala namin ang mga estratehiya para sa kanila ΠΈ , at sa 13.1 idinagdag nila ΠΈ para sa iba't ibang kapaligiran.
Mas maaga sa taong ito, gumawa ng pangako ang GitLab sa open source. Sa release na ito, nakumpleto na namin ang paglipat ng mga naililipat na feature sa Starter plan at patuloy naming ililipat ang mga ito sa Core mula sa . Nasasabik kaming dalhin ang feature na ito sa mas maraming user at gusto naming marinig kung paano mo ito ginagamit.
ΠΈ .
Mabilis na nabigasyon mula sa search bar
(CORE, STARTER, PREMIUM, ULTIMATE, LIBRE, BRONZE, SILVER, GOLD)
Minsan kapag nagna-navigate sa GitLab gusto mong dumiretso sa isang partikular na proyekto kaysa sa pahina ng mga resulta ng paghahanap.
Gamit ang pandaigdigang search bar, mabilis kang makakapag-navigate sa mga pinakabagong ticket, grupo, proyekto, setting, at paksa ng tulong. Maaari ka ring gumamit ng hotkey /upang ilipat ang iyong cursor sa search bar upang mag-navigate sa GitLab nang mas mahusay!
ΠΈ .
Ang pagpapakita ng saklaw ng code sa kahilingan sa pagsasama ay naiiba
(CORE, STARTER, PREMIUM, ULTIMATE, LIBRE, BRONZE, SILVER, GOLD)
Kapag sinusuri ang isang kahilingan sa pagsasama, maaaring mahirap matukoy kung ang binagong code ay sakop ng mga unit test. Sa halip, maaaring umasa ang mga tagasuri sa pangkalahatang saklaw at humiling na ito ay dagdagan bago aprubahan ang isang kahilingan sa pagsasama. Ito ay maaaring humantong sa isang pambihirang diskarte sa pagsusulat ng mga pagsusulit, na hindi talaga magpapahusay sa kalidad ng code o saklaw ng pagsubok.
Ngayon, kapag tinitingnan ang isang merge request diff, makikita mo ang isang visual na pagpapakita ng saklaw ng code. Ang mga bagong marka ay magbibigay-daan sa iyong mabilis na maunawaan kung ang binagong code ay sakop ng isang pagsubok sa yunit, na makakatulong sa pagpapabilis ng pagsusuri ng code at ang oras ng pagsasama at pag-deploy ng bagong code.
salamat at Siemens para sa feature na ito!
ΠΈ .
Higit pang mga kapaligiran at proyekto sa panel ng Mga Kapaligiran
(PREMIUM, ULTIMATE, SILVER, GOLD)
Mula nang ilabas ang GitLab 12.5 gamit ang maaari mong subaybayan ang estado ng mga kapaligiran, ngunit hindi hihigit sa pitong mga kapaligiran sa tatlong mga proyekto. Pinahusay namin ang panel na ito sa release 13.4 sa pamamagitan ng pag-page nito upang matulungan kang mapanatili at pamahalaan ang iyong mga kapaligiran sa sukat. Ngayon ay makakakita ka ng mas maraming kapaligiran sa mas maraming proyekto.
ΠΈ .
Kinokontrol ng GitLab ang GitLab Terraform provider
(CORE, STARTER, PREMIUM, ULTIMATE, LIBRE, BRONZE, SILVER, GOLD)
Kamakailan lang kami at plano . Sa nakalipas na buwan, tumanggap kami ng 21 kahilingan sa pagsasanib at nagsara ng 31 tiket, kabilang ang ilang matagal nang bug at nawawalang feature gaya ng . Maaari mong sa dokumentasyon ng Terraform.
ΠΈ .
Fuzzing API testing gamit ang mga detalye ng OpenAPI o HAR file
(ULTIMATE, GOLD)
Ang API fuzzing testing ay isang mahusay na paraan upang makahanap ng mga bug at kahinaan sa iyong mga web application at API na maaaring makaligtaan ng iba pang mga scanner at pamamaraan ng pagsubok.
Binibigyang-daan ka ng API fuzzing testing sa GitLab na magbigay o iyong application at pagkatapos ay awtomatikong bumubuo ng random na data ng pag-input na idinisenyo upang subukan ang mga edge case at maghanap ng mga bug. Ang mga resulta ay makikita kaagad sa loob ng iyong pipeline.
Ito ang aming unang release ng API fuzz testing at gusto naming marinig kung ano ang iniisip mo. Marami pa kaming stock para sa fuzz testing , na ibabatay namin sa pagpapalabas ng tampok na ito.
ΠΈ .
I-preview ang mga bagong graph sa panel ng mga sukatan
(CORE, STARTER, PREMIUM, ULTIMATE, LIBRE, BRONZE, SILVER, GOLD)
Dati, hindi madaling gawain ang paggawa ng graph sa dashboard ng mga sukatan sa GitLab. Pagkatapos mong gawin ang sukatan sa dashboard YAML file, gumawa ka ng mga pagbabago sa master, nang hindi ma-verify na ang bagong likhang graph ay gumagana nang eksakto tulad ng kailangan mo. Simula sa release na ito, maaari mong i-preview ang mga pagbabago habang ginagawa mo ang graph, pagkuha ng ideya ng resulta bago ipadala ang mga pagbabago sa dashboard YAML file.
ΠΈ .
Data sa saklaw ng code sa pamamagitan ng mga pagsubok para sa lahat ng proyekto ng pangkat
(PREMIUM, ULTIMATE, SILVER, GOLD)
Kapag pinamamahalaan mo ang isang malaking bilang ng mga proyekto sa GitLab, kailangan mo ng isang mapagkukunan ng impormasyon tungkol sa kung paano nagbabago ang saklaw ng code sa paglipas ng panahon sa lahat ng mga proyekto. Dati, ang pagpapakita ng impormasyong ito ay nangangailangan ng nakakapagod at nakakaubos ng oras na manu-manong trabaho: kailangan mong mag-download ng data ng saklaw ng code mula sa bawat proyekto at pagsamahin ito sa isang talahanayan.
Sa release 13.4, naging posible na mabilis at madaling mag-ipon .csv file kasama ang lahat ng data sa saklaw ng code para sa lahat ng proyekto ng grupo o para sa isang seleksyon ng mga proyekto. Ang tampok na ito ay MVC, ito ay susundan ng kakayahan .
ΠΈ .
Suporta para sa mga bagong wika para sa buong fuzz testing
(ULTIMATE, GOLD)
Ang release na ito ay nagpapakilala ng suporta para sa ilang bagong wika para sa fuzz testing na naglalayong ganap na saklaw.
Ngayon ay maaari mong suriin ang buong kakayahan ng fuzzing testing sa iyong Java, Rust, at Swift na mga application at makahanap ng mga error at kahinaan na maaaring makaligtaan ng ibang mga scanner at mga paraan ng pagsubok.
ΠΈ .
Mga alerto sa pangunahing pahina ng kapaligiran
(PREMIUM, ULTIMATE, SILVER, GOLD)
Ipinapakita ng pahina ng Mga Kapaligiran ang pangkalahatang kalagayan ng iyong mga kapaligiran. Sa paglabas na ito, pinahusay namin ang pahinang ito sa pamamagitan ng pagdaragdag ng pagpapakita ng alerto. Ang mga na-trigger na alerto kasama ang katayuan ng iyong mga kapaligiran ay makakatulong sa iyong mabilis na kumilos upang iwasto ang mga sitwasyong lumitaw.
ΠΈ .
Ang mga nested pipeline ay maaari na ngayong magpatakbo ng sarili nilang mga nested pipeline
(CORE, STARTER, PREMIUM, ULTIMATE, LIBRE, BRONZE, SILVER, GOLD)
Sa pamamagitan ng paggamit ng mga nested pipeline, posible na ngayong magpatakbo ng mga bagong pipeline sa loob ng mga child pipeline. Ang dagdag na antas ng lalim ay maaaring maging kapaki-pakinabang kung kailangan mo ng kakayahang umangkop upang bumuo ng isang variable na bilang ng mga pipeline.
Dati, kapag gumagamit ng mga nested pipeline, ang bawat pipeline ng bata ay nangangailangan ng trigger job na manu-manong tukuyin sa parent pipeline. Maaari ka na ngayong gumawa ng mga nested pipeline na dynamic na maglulunsad ng anumang bilang ng mga bagong nested pipeline. Halimbawa, kung mayroon kang monorepository, maaari mong dynamic na buuin ang unang subpipeline, na gagawa mismo ng kinakailangang bilang ng mga bagong pipeline batay sa mga pagbabago sa sangay.
ΠΈ .
Pinahusay na nabigasyon sa pagitan ng parent at nested pipelines
(CORE, STARTER, PREMIUM, ULTIMATE, LIBRE, BRONZE, SILVER, GOLD)
Dati, hindi masyadong maginhawa ang pag-navigate sa pagitan ng parent at nested pipeline - kailangan mo ng maraming pag-click para makarating sa gustong pipeline. Hindi rin madaling malaman kung aling trabaho ang nagsimula ng pipeline. Ngayon ay magiging mas madaling makita ang mga koneksyon sa pagitan ng parent at nested pipelines.
ΠΈ .
Ang mga parallel matrix na trabaho ay nagpapakita ng mga nauugnay na variable sa titulo ng trabaho
(CORE, STARTER, PREMIUM, ULTIMATE, LIBRE, BRONZE, SILVER, GOLD)
Kung ginamit mo , maaaring napansin mo na mahirap matukoy kung aling matrix variable ang ginamit para sa isang partikular na trabaho, dahil ang mga pangalan ng trabaho ay parang matrix 1/4. Sa release 13.4, makikita mo ang mga nauugnay na variable value na ginamit sa trabahong iyon sa halip na ang generic na pangalan ng trabaho. Halimbawa, kung ang iyong layunin ay i-debug ang x86 architecture, kung gayon ang trabaho ay tatawagin matrix: debug x86.
ΠΈ .
Iba pang mga pagpapabuti sa GitLab 13.4
Pagkonekta ng isang Atlassian account
(CORE, STARTER, PREMIUM, ULTIMATE)
Ang mga gumagamit ng GitLab ay magagawa na ngayong ikonekta ang kanilang mga GitLab account sa kanilang Atlassian Cloud account. Papayagan ka nitong mag-log in sa GitLab gamit ang iyong mga kredensyal sa Atlassian, at maglalatag din ng batayan para sa mga pagpapabuti sa pagsasama sa hinaharap. at sa iba pang mga produkto mula sa linya ng Atlassian.
ΠΈ .
Ang pag-export ng listahan ng lahat ng merge commit
(ULTIMATE, GOLD)
Ang mga organisasyong nakatuon sa pagsunod ay nangangailangan ng paraan upang ipakita sa mga auditor ang isang holistic na pagtingin sa mga bahaging nauugnay sa anumang partikular na pagbabago sa produksyon. Sa GitLab, nangangahulugan ito ng pagkolekta ng lahat sa isang lugar: pagsamahin ang mga kahilingan, tiket, pipeline, pag-scan ng seguridad, at iba pang commit data. Hanggang ngayon, kailangan mong manu-manong kolektahin ito sa GitLab o i-configure ang iyong mga tool upang mangolekta ng impormasyon, na hindi masyadong mahusay.
Maaari mo na ngayong kolektahin at i-export ang data na ito sa pamamagitan ng program upang matugunan ang mga kinakailangan sa pag-audit o magsagawa ng iba pang mga pagsusuri. Para mag-export ng listahan ng lahat ng merge commit para sa kasalukuyang grupo, kailangan mong pumunta sa at mag-click sa pindutan Listahan ng lahat ng merge commit. Ang magreresultang file ay maglalaman ng lahat ng mga commit ng kahilingan sa pagsasama, kanilang may-akda, ID ng nauugnay na kahilingan sa pagsasama, pangkat, proyekto, mga nagkukumpirma at iba pang impormasyon.
ΠΈ .
Ilista at pamahalaan ang mga personal na token ng pag-access sa pamamagitan ng API
(ULTIMATE, GOLD)
Ang pamamahala ng access sa GitLab namespace ay isang mahalagang bahagi ng mga pagsusumikap sa pagsunod. Mula sa mga prinsipyo ng hindi bababa sa pribilehiyo hanggang sa hindi pagpapagana ng naka-time na pag-access, maaaring may ilang kinakailangan na nauugnay sa mga personal na token ng pag-access sa GitLab. Upang gawing mas madaling mapanatili at pamahalaan ang lahat ng mga kredensyal ng user na ito sa loob ng iyong namespace, nagbigay kami ng kakayahang ilista ang lahat ng mga personal na token ng pag-access at opsyonal. sa pamamagitan ng API.
Ang mga pagpapahusay na ito sa GitLab API ay nagbibigay-daan sa mga user na ilista at bawiin ang kanilang mga personal na token ng pag-access, at ang mga admin na ilista at bawiin ang mga token ng kanilang mga user. Magiging mas madali na ngayon para sa mga administrator na makita kung sino ang may access sa kanilang namespace, gumawa ng mga pagpapasya sa pag-access batay sa data ng user, at bawiin ang mga personal na token ng pag-access na maaaring nakompromiso o nasa labas ng mga patakaran sa pamamahala ng access ng kumpanya.
ΠΈ .
Ang mga kaugnay na isyu at iba pang feature ay nasa GitLab Core na ngayon
(CORE, STARTER, PREMIUM, ULTIMATE, LIBRE, BRONZE, SILVER, GOLD)
Ilang buwan na ang nakararaan nag-anunsyo kami ng plano . Sa pamamagitan ng pagsisikap na tuparin ang pangakong ito, ginawa namin , ΠΈ (sa Russian localization ng GitLab βdiscussion boardβ) na available sa Core plan. Nalalapat lang ito sa mga relasyong "naka-link sa"; nananatili sa mga bayad na plano ang mga relasyong "block" at "naka-block".
ΠΈ .
Ipinapakita ang pinanggalingan na pangalan ng sangay sa sidebar ng kahilingan sa pagsasanib
(CORE, STARTER, PREMIUM, ULTIMATE, LIBRE, BRONZE, SILVER, GOLD)
Kapag sinusuri ang mga pagbabago sa code, mga talakayan, at kahilingan sa pagsasama, kadalasang kanais-nais na magsagawa ng lokal na pag-checkout ng sangay para sa mas malalim na pagsusuri. Gayunpaman, lalong nagiging mahirap ang paghahanap ng pangalan ng thread dahil mas maraming nilalaman ang idinaragdag sa paglalarawan ng kahilingan sa pagsasama at kailangan mong mag-scroll pa pababa ng pahina.
Idinagdag namin ang pangalan ng sangay sa sidebar ng kahilingan sa pagsasanib, ginagawa itong naa-access anumang oras at inaalis ang pangangailangang mag-scroll sa buong pahina. Tulad ng link sa kahilingan sa pagsasama, naglalaman ang seksyon ng source branch ng isang maginhawang "kopya" na buton.
salamat para sa iyong malaking kontribusyon sa pagbuo ng tampok na ito!
ΠΈ .
Magkaiba ang indikasyon ng pagkakaroon ng mga na-collapse na file sa kahilingan sa pag-merge
(CORE, STARTER, PREMIUM, ULTIMATE, LIBRE, BRONZE, SILVER, GOLD)
Ang mga kahilingan sa pagsasama-sama na nagdaragdag ng mga pagbabago sa maraming file kung minsan ay i-collapse ang mga pagkakaiba ng malalaking file upang mapabuti ang pagganap ng pag-render. Kapag nangyari ito, posibleng hindi sinasadyang laktawan ang isang file sa panahon ng pagsusuri, lalo na sa mga kahilingan sa pagsasanib na may malaking bilang ng mga file. Simula sa bersyon 13.4, ang mga kahilingan sa pagsasanib ay mag-flag ng mga diff na naglalaman ng mga naka-fold na file, upang hindi mo makaligtaan ang mga file na ito sa panahon ng pagsusuri ng code. Para sa higit na kalinawan, plano naming magdagdag ng pag-highlight sa mga file na ito sa isang release sa hinaharap. Manatiling nakatutok para sa mga update sa .
ΠΈ .
Babala tungkol sa pagkakaroon ng mga na-collapse na file sa diff ng isang kahilingan sa pagsasama
(CORE, STARTER, PREMIUM, ULTIMATE, LIBRE, BRONZE, SILVER, GOLD)
Sa seksyon ng merge request diffs, ang malalaking file ay ibinabagsak upang mapabuti ang pagganap. Gayunpaman, kapag nire-review ang code, maaaring makaligtaan ang ilang file kapag nag-scroll ang tagasuri sa listahan ng mga file, dahil ang lahat ng malalaking file ay na-collapse.
Nagdagdag kami ng nakikitang babala sa tuktok ng diff page ng kahilingan sa pagsama-sama upang ipaalam sa mga user na mayroong pinagsamang file sa seksyong ito. Sa ganitong paraan, hindi mo mapalampas ang anumang mga pagbabago sa kahilingan sa pagsasama habang sinusuri.
ΠΈ .
Awtomatikong pagbawi ng Gitaly cluster repository
(CORE, STARTER, PREMIUM, ULTIMATE, LIBRE, BRONZE, SILVER, GOLD)
Noong nakaraan, kapag ang pangunahing node ng isang Gitaly cluster ay nag-offline, ang mga repository sa node na iyon ay minarkahan bilang read-only. Pinipigilan nito ang pagkawala ng data sa mga sitwasyon kung saan may mga pagbabago sa node na hindi pa ginagaya. Nang bumalik ang node sa online, hindi awtomatikong naibalik ang GitLab, at kailangang manu-manong simulan ng mga administrator ang proseso ng pag-synchronize o tanggapin ang pagkawala ng data. Ang iba pang mga sitwasyon, gaya ng pagkabigo ng isang replication job sa pangalawang node, ay maaari ding magresulta sa mga lipas o read-only na repository. Sa kasong ito, nanatiling lipas ang repository hanggang sa maganap ang susunod na operasyon ng pagsulat, na magsisimula sa trabaho ng pagtitiklop.
Upang malutas ang problemang ito nag-iskedyul na ngayon ng trabaho sa pagtitiklop kapag nakakita ito ng lumang repositoryo sa isang node at ang pinakabagong bersyon ng repositoryo sa isa pa. Ang replication job na ito ay nagpapanatili sa repositoryo na awtomatikong napapanahon, na inaalis ang pangangailangan na manu-manong ibalik ang data. Tinitiyak din ng awtomatikong pagbawi na ang mga pangalawang node ay mabilis na na-update kung ang isang trabaho sa pagtitiklop ay nabigo, sa halip na maghintay para sa susunod na operasyon ng pagsulat. Dahil maraming mga cluster ng Gilaly ang nag-iimbak ng malaking bilang ng mga repository, makabuluhang binabawasan nito ang oras na ginugugol ng mga administrator at reliability engineer sa pagbawi ng data pagkatapos ng isang error.
Bilang karagdagan, ang awtomatikong pag-aayos ay magsisimula ng pagtitiklop ng mga repositoryo sa anumang bagong Gitaly node na idinagdag sa cluster, na inaalis ang manu-manong trabaho kapag nagdaragdag ng mga bagong node.
ΠΈ .
Markahan ang isang gawaing dapat gawin bilang nakumpleto sa pahina ng disenyo
(CORE, STARTER, PREMIUM, ULTIMATE, LIBRE, BRONZE, SILVER, GOLD)
Ang epektibong komunikasyon sa GitLab ay batay sa mga listahan ng gagawin. Kung binanggit ka sa isang komento, mahalaga na magawang tumalon sa isang gawain at magsimulang gumawa ng isang bagay o markahan ito bilang nakumpleto. Mahalaga rin na makapagtalaga ng isang gawain sa iyong sarili kapag kailangan mong gumawa ng isang bagay o bumalik dito sa ibang pagkakataon.
Dati, hindi ka maaaring magdagdag ng mga gawain o markahan ang mga ito bilang nakumpleto kapag nagtatrabaho sa mga disenyo. Ito ay seryosong nakagambala sa kahusayan ng komunikasyon sa pagitan ng mga pangkat ng produkto, dahil ang mga dapat gawin ay isang kritikal na elemento ng daloy ng trabaho sa GitLab.
Sa release 13.4, ang mga disenyo ay nakakahabol sa mga komento ng tiket sa paggamit ng mga gawain, na ginagawang mas pare-pareho at mahusay ang pakikipagtulungan sa kanila.
ΠΈ .
Pinahusay na gabay sa pag-troubleshoot para sa CI/CD
(CORE, STARTER, PREMIUM, ULTIMATE, LIBRE, BRONZE, SILVER, GOLD)
Pinahusay namin ang gabay sa pag-troubleshoot para sa GitLab CI/CD na may higit pang impormasyon tungkol sa mga karaniwang isyu na maaari mong makaharap. Umaasa kami na ang pinahusay na dokumentasyon ay magiging isang mahalagang mapagkukunan sa pagtulong sa iyong bumangon at magpatakbo ng GitLab CI/CD nang mabilis at madali.
ΠΈ .
Ang mga kahilingan sa pagsamahin ay hindi na nahuhulog sa pila ng pagsasama
(PREMIUM, ULTIMATE, SILVER, GOLD)
Dati, ang mga kahilingan sa pagsasanib ay maaaring mahulog sa merge queue nang hindi sinasadya dahil sa mga huling komento. Kung ang isang kahilingan sa pagsama-sama ay nasa pila na at may nagdagdag ng komento dito na lumikha ng isang bagong hindi nalutas na talakayan, ang kahilingan sa pagsasama ay itinuturing na hindi karapat-dapat para sa isang pagsasanib at mawawala sa pila. Ngayon, pagkatapos maidagdag ang isang kahilingan sa pagsasanib sa pila ng pagsasanib, maaaring magdagdag ng mga bagong komento nang walang takot na abalahin ang proseso ng pagsasanib.
ΠΈ .
Ipinapakita ang halaga ng saklaw ng code para sa isang trabaho sa isang kahilingan sa pagsasama
(CORE, STARTER, PREMIUM, ULTIMATE, LIBRE, BRONZE, SILVER, GOLD)
Dapat makita ng mga developer ang halaga ng saklaw ng code pagkatapos makumpleto ang pipeline - kahit na sa mga kumplikadong sitwasyon gaya ng pagpapatakbo ng pipeline na may maraming trabaho na kailangang i-parse para makalkula ang halaga ng saklaw. Dati, ipinakita lang ng widget ng kahilingan sa pagsasanib ang average ng mga halagang ito, na nangangahulugang kailangan mong mag-navigate sa pahina ng trabaho at bumalik sa kahilingan sa pagsasama upang makakuha ng mga intermediate na halaga ng saklaw. Upang makatipid ka ng oras at mga karagdagang hakbang na ito, ginawa naming ipakita ng widget ang average na halaga ng saklaw, ang mga pagbabago nito sa pagitan ng target at pinagmulang mga sangay, at isang tooltip na nagpapakita ng halaga ng saklaw para sa bawat trabaho batay sa kung saan kinakalkula ang average.
ΠΈ .
Pag-alis ng mga pakete mula sa pagpapatala ng package kapag tumitingin sa isang grupo
(CORE, STARTER, PREMIUM, ULTIMATE, LIBRE, BRONZE, SILVER, GOLD)
Ang GitLab package registry ay isang lugar upang mag-imbak at mamahagi ng mga pakete sa iba't ibang mga format. Kapag marami kang package sa iyong proyekto o grupo, kailangan mong mabilis na tukuyin ang mga hindi nagamit na package at alisin ang mga ito para pigilan ang mga tao na i-download ang mga ito. Maaari mong alisin ang mga pakete mula sa iyong pagpapatala sa pamamagitan ng o sa pamamagitan ng package registry user interface. Gayunpaman, hanggang ngayon ay hindi mo maalis ang mga package kapag tinitingnan ang isang grupo sa pamamagitan ng UI. Bilang resulta, kinailangan mong alisin ang mga hindi kinakailangang pakete sa bawat proyekto, na hindi epektibo.
Maaari mo na ngayong alisin ang mga pakete kapag tinitingnan ang pagpapatala ng package ng isang grupo. Pumunta lang sa page ng package registry ng grupo, i-filter ang mga package ayon sa pangalan, at alisin ang anumang hindi mo kailangan.
ΠΈ .
Pag-scale ng mga pakete ng Conan sa antas ng proyekto
(CORE, STARTER, PREMIUM, ULTIMATE, LIBRE, BRONZE, SILVER, GOLD)
Maaari mong gamitin ang Conan repository sa GitLab para i-publish at ipamahagi ang mga dependency ng C/C++. Gayunpaman, ang mga dating package ay maaari lamang i-scale sa antas ng instance, dahil ang pangalan ng package ng Conan ay maaari lamang maging maximum na 51 character. Kung gusto mong mag-publish ng package mula sa isang subgroup, halimbawa gitlab-org/ci-cd/package-stage/feature-testing/conan, halos imposible itong gawin.
Maaari mo na ngayong i-scale ang mga pakete ng Conan hanggang sa antas ng proyekto, na ginagawang madali ang pag-publish at pamamahagi ng mga dependency ng iyong mga proyekto.
ΠΈ .
Suporta para sa mga bagong manager ng package at mga wika para sa pag-scan ng dependency
(ULTIMATE, GOLD)
Nasasabik kaming magdagdag ng mga dependency scan para sa mga proyekto ng C, C++, C# at .Net code na gumagamit ng NuGet 4.9+ o Conan package managers sa aming listahan . Maaari mo na ngayong paganahin ang pag-scan ng dependency bilang bahagi ng Secure na yugto upang suriin ang mga kilalang kahinaan sa mga dependency na idinagdag sa pamamagitan ng mga manager ng package. Ang mga kahinaan na makikita ay ipapakita sa iyong kahilingan sa pagsasama kasama ng kanilang antas ng kalubhaan, upang malaman mo bago isagawa ang pagsasama kung ano ang mga panganib na dala ng bagong dependency. Maaari mo ring i-configure ang iyong proyekto upang mangailangan para sa mga dependency na may mga kahinaan na may kritikal (Kritikal), mataas (Mataas) o hindi alam (Hindi alam) na antas ng kalubhaan.
ΠΈ .
Mga abiso kapag binabago ang setting ng kahilingan sa pagsasanib sa 'Pagsamahin kapag matagumpay na nakumpleto ang pipeline'
(CORE, STARTER, PREMIUM, ULTIMATE, LIBRE, BRONZE, SILVER, GOLD)
Dati, kapag nagtatakda ng mga setting ng kahilingan sa pagsasama Pagsamahin kapag natapos na ang pipeline (Merge When Pipeline Succeeds, MWPS) walang email notification na ipinadala. Kailangan mong manu-manong suriin ang katayuan o maghintay para sa isang abiso sa pagsasanib. Sa paglabas na ito, nalulugod kaming itampok ang mga kontribusyon ng user , na lumutas sa problemang ito sa pamamagitan ng pagdaragdag ng mga awtomatikong notification sa lahat ng naka-subscribe sa isang kahilingan sa pagsasama kapag binago ng isang reviewer ang setting ng pagsasama sa MWPS.
ΠΈ .
Paggawa ng mga EKS cluster na may bersyon ng Kubernetes na tinukoy ng user
(CORE, STARTER, PREMIUM, ULTIMATE, LIBRE, BRONZE, SILVER, GOLD)
Ang mga gumagamit ng GitLab ay maaari na ngayong pumili ng bersyon ng Kubernetes na ibibigay ng EKS; maaari kang pumili sa pagitan ng mga bersyon 1.14β1.17.
ΠΈ .
Paglikha ng mga insidente bilang mga uri ng tiket
(CORE, STARTER, PREMIUM, ULTIMATE, LIBRE, BRONZE, SILVER, GOLD)
Hindi lahat ng problemang lumalabas ay agad na nagti-trigger ng mga alerto: ang mga user ay nag-uulat ng mga outage at ang mga miyembro ng team ay nag-iimbestiga sa mga isyu sa performance. Ang mga insidente ay isa na ngayong uri ng tiket, kaya mabilis na magagawa ng iyong mga koponan ang mga ito bilang bahagi ng kanilang normal na daloy ng trabaho. I-click Bagong gawain mula sa kahit saan sa GitLab, at sa field Uri piliin Nagkataon.
ΠΈ .
Pagbanggit ng Mga Alerto sa GitLab sa Markdown
(CORE, STARTER, PREMIUM, ULTIMATE, LIBRE, BRONZE, SILVER, GOLD)
Pinahusay namin ang mga alerto sa GitLab sa pamamagitan ng pagdaragdag ng bagong uri ng pagbanggit na partikular para sa kanila sa Markdown ng GitLab, na ginagawang mas madali ang pagbabahagi at pagbanggit ng mga alerto. Gamitin ^alert#1234upang banggitin ang alerto sa anumang field ng Markdown: sa mga insidente, ticket, o mga kahilingan sa pagsasama. Makakatulong din ito sa iyo na matukoy ang mga trabahong nilikha mula sa mga alerto sa halip na mga tiket o mga kahilingan sa pagsasama.
ΠΈ .
Pagtingin sa alert load ayon sa insidente
(CORE, STARTER, PREMIUM, ULTIMATE, LIBRE, BRONZE, SILVER, GOLD)
Ang paglalarawan ng alerto ay naglalaman ng impormasyong mahalaga sa pag-troubleshoot at pagbawi, at ang impormasyong ito ay dapat na madaling ma-access upang hindi mo kailangang lumipat ng mga tool o tab habang nagtatrabaho ka upang malutas ang isang insidente. Ang mga insidenteng ginawa mula sa mga alerto ay nagpapakita ng buong paglalarawan ng alerto sa tab Mga Detalye ng Alerto.
75% mas mabilis na advanced na paghahanap
(STARTER, PREMIUM, ULTIMATE, BRONZE, SILVER, GOLD)
Ang GitLab, bilang iisang application, ay may natatanging kakayahang gumawa ng pagtuklas ng nilalaman sa iyong buong daloy ng trabaho sa DevOps nang mabilis. Sa GitLab 13.4, ang advanced na paghahanap ay nagbabalik ng mga resulta ng 75% na mas mabilis kapag ito , tulad ng sa GitLab.com.
ΠΈ .
Pagtingin sa mga tinanggal na proyekto para sa mga administrator
(CORE, STARTER, PREMIUM, ULTIMATE)
Nagkaroon ng opsyon na ipagpaliban ang pagtanggal ng proyekto . Gayunpaman, dati ay hindi posible na makita ang lahat ng mga proyekto na naghihintay ng pagtanggal sa isang lugar. Maaari na ngayong tingnan ng mga administrator ng user instance ng GitLab ang lahat ng nakabinbing proyekto sa pagtanggal sa isang lugar, kasama ang mga button upang madaling maibalik ang mga proyektong iyon.
Ang tampok na ito ay nagbibigay sa mga administrator ng higit na kontrol sa pagtanggal ng proyekto sa pamamagitan ng pagkolekta ng lahat ng may-katuturang impormasyon sa isang lugar at pagbibigay ng kakayahang i-undo ang mga hindi gustong pagtanggal ng mga aksyon.
salamat para sa tampok na ito!
ΠΈ .
Nagdagdag ng suporta para sa mga panuntunan sa pagtulak ng grupo sa API
(STARTER, PREMIUM, ULTIMATE, BRONZE, SILVER, GOLD)
Dati, ang mga panuntunan sa pagtulak ng grupo ay maaari lamang i-configure sa pamamagitan ng pagbisita sa bawat pangkat nang paisa-isa sa pamamagitan ng GitLab UI at paglalapat ng mga panuntunang iyon. Maaari mo na ngayong pamahalaan ang mga panuntunang ito sa pamamagitan ng isang API para suportahan ang iyong mga custom na tool at automation ng GitLab.
ΠΈ .
Pagbawi ng mga token ng personal na access para sa self-managed na storage ng kredensyal
(ULTIMATE)
Nagbibigay sa mga administrator ng impormasyong kailangan nila para pamahalaan ang mga kredensyal ng user para sa kanilang GitLab instance. Dahil iba-iba ang mga organisasyong nakatuon sa pagsunod sa kahigpitan ng kanilang mga patakaran sa pamamahala ng kredensyal, nagdagdag kami ng button na nagbibigay-daan sa mga administrator na opsyonal na bawiin ang personal access token (PAT) ng isang user. Madali na ngayong bawiin ng mga administrator ang mga posibleng nakompromisong PAT. Kapaki-pakinabang ang feature na ito para sa mga organisasyong gustong mas nababaluktot ang mga opsyon sa pagsunod upang mabawasan ang pagkaantala sa kanilang mga user.
ΠΈ .
Configuration file para sa static na editor ng site
(CORE, STARTER, PREMIUM, ULTIMATE, LIBRE, BRONZE, SILVER, GOLD)
Sa GitLab 13.4, ipinapakilala namin ang isang bagong paraan upang i-customize ang static na editor ng site. Bagama't hindi nagse-save o nakakatanggap ang configuration file ng anumang mga setting sa release na ito, inilalagay namin ang batayan para sa hinaharap na pag-customize ng gawi ng editor. Sa mga susunod na release ay idaragdag namin sa file .gitlab/static-site-editor.yml mga parameter para sa pag-install , kung saan , overriding ang Markdown syntax setting at iba pang setting ng editor.
ΠΈ .
Pag-edit ng panimulang bahagi ng isang file gamit ang isang static na editor ng site
(CORE, STARTER, PREMIUM, ULTIMATE, LIBRE, BRONZE, SILVER, GOLD)
Ang front matter ay isang nababaluktot at maginhawang paraan upang tukuyin ang mga variable ng page sa mga file ng data para sa pagproseso ng static na site generator. Karaniwan itong ginagamit upang itakda ang pamagat ng pahina, template ng layout, o may-akda, ngunit maaaring gamitin upang ipasa ang anumang uri ng metadata sa generator kapag nire-render ang pahina sa HTML. Kasama sa pinakatuktok ng bawat file ng data, ang panimulang bahagi ay karaniwang naka-format bilang YAML o JSON at nangangailangan ng pare-pareho at tumpak na syntax. Ang mga user na hindi pamilyar sa mga partikular na panuntunan ng syntax ay maaaring hindi sinasadyang magpasok ng di-wastong markup, na maaaring magdulot ng mga problema sa pag-format o maging ng mga pagkabigo.
Inaalis na ng WYSIWYG mode ng pag-edit ng static na editor ng site ang intro mula sa editor upang maiwasan ang mga error sa pag-format na ito. Gayunpaman, pinipigilan ka nitong baguhin ang mga halaga na nakaimbak sa bahaging ito nang hindi bumalik sa pag-edit sa source mode. Sa GitLab 13.4, maaari mong i-access ang anumang field at i-edit ang halaga nito sa isang pamilyar na interface na nakabatay sa mga form. Kapag pinindot ang pindutan Mga Setting (Setting) magbubukas ang isang panel na nagpapakita ng field ng form para sa bawat key na tinukoy sa simula. Ang mga patlang ay napuno ng kasalukuyang halaga, at ang pag-edit ng alinman sa mga ito ay kasing simple ng pagpasok nito sa web form. Ang pag-edit ng intro sa ganitong paraan ay maiiwasan ang kumplikadong syntax at nagbibigay sa iyo ng kumpletong kontrol sa nilalaman habang tinitiyak na ang panghuling resulta ay palaging na-format.
ΠΈ .
Ang GitLab para sa Jira at DVCS Connector ay nasa Core na ngayon
(CORE, STARTER, PREMIUM, ULTIMATE, LIBRE, BRONZE, SILVER, GOLD)
Para sa mga gumagamit ng Jira sa GitLab: ΠΈ nagbibigay-daan sa iyo na magpakita ng impormasyon tungkol sa GitLab commit at merge ng mga kahilingan nang direkta sa Jira. Kasama ng aming built-in na Jira integration, madali kang makakalipat sa pagitan ng dalawang app habang nagtatrabaho ka.
Ang mga feature na ito ay dating available lang sa aming Premium plan, ngunit available na ngayon sa lahat ng user!
ΠΈ .
Karamihan sa pagboto para sa mga transaksyon sa cluster ng Gitaly (beta)
(CORE, STARTER, PREMIUM, ULTIMATE)
Binibigyang-daan ka ng isang Gitaly cluster na kopyahin ang mga Git repository sa maraming "mainit" na Gitaly node. Pinatataas nito ang fault tolerance sa pamamagitan ng pag-aalis ng mga solong punto ng kabiguan. , na ipinakilala sa GitLab 13.3, ay nagiging sanhi ng mga pagbabago na mai-broadcast sa lahat ng mga Gitaly node sa cluster, ngunit ang mga Gitaly node lamang na bumoto sa pagsang-ayon sa pangunahing node ay nagse-save ng mga pagbabago sa disk. Kung hindi sumasang-ayon ang lahat ng replica node, isang kopya lang ng pagbabago ang maiimbak sa disk, na lumilikha ng isang punto ng pagkabigo hanggang sa makumpleto ang asynchronous replication.
Ang pagboto ng karamihan ay nagpapabuti sa pagpapahintulot sa pagkakamali sa pamamagitan ng pag-aatas ng pahintulot ng karamihan ng mga node (hindi lahat) bago i-save ang mga pagbabago sa disk. Kung naka-enable ang toggle feature na ito, dapat magtagumpay ang pagsulat sa maraming node. Awtomatikong isi-synchronize ang mga dissenting node gamit ang asynchronous replication mula sa mga node na nakabuo ng isang quorum.
ΠΈ .
Suporta sa custom na schema para sa pagpapatunay ng JSON sa Web IDE
(PREMIUM, ULTIMATE, SILVER, GOLD)
Ang mga proyekto kung saan nagsusulat ang mga tao ng mga configuration sa JSON o YAML ay kadalasang madaling kapitan ng mga problema dahil madaling gumawa ng typo at masira ang isang bagay. Posibleng magsulat ng mga tool sa inspeksyon upang mahuli ang mga isyung ito sa pipeline ng CI, ngunit ang paggamit ng JSON schema file ay maaaring maging kapaki-pakinabang upang magbigay ng dokumentasyon at mga pahiwatig.
Maaaring tukuyin ng mga kalahok ng proyekto sa kanilang imbakan ang landas patungo sa isang custom na schema sa isang file .gitlab/.gitlab-webide.yml, na tumutukoy sa schema at path sa mga file na susuriin. Kapag nag-load ka ng isang partikular na file sa Web IDE, makakakita ka ng karagdagang feedback at pagpapatunay upang matulungan kang lumikha ng file.
ΠΈ .
Tumaas sa 50 ang limitasyon sa pagsasanga ng Directed Acyclic Graph (DAG).
(CORE, STARTER, PREMIUM, ULTIMATE, LIBRE, BRONZE, SILVER, GOLD)
Kung gumagamit ka ng mga conveyor (Directed Acyclic Graph (DAG)), maaari mong makita na mayroong limitasyon ng 10 trabaho na maaaring tukuyin ng isang trabaho sa needs:, masyadong marahas. Sa 13.4, ang default na limitasyon ay tinaasan mula 10 hanggang 50 upang payagan ang mga mas kumplikadong network ng mga relasyon sa pagitan ng mga trabaho sa iyong mga pipeline.
Kung isa kang administrator ng isang custom na halimbawa ng GitLab, maaari mong taasan ang limitasyong ito nang mas mataas sa pamamagitan ng pag-set up ng feature na toggle, bagama't hindi kami nag-aalok ng opisyal na suporta para dito.
ΠΈ .
Pinahusay na pag-uugali needs para sa mga hindi nakuhang takdang-aralin
(CORE, STARTER, PREMIUM, ULTIMATE, LIBRE, BRONZE, SILVER, GOLD)
Sa ilang mga kaso, ang isang napalampas na trabaho sa isang pipeline ay maaaring maling ituring na matagumpay para sa mga dependency na tinukoy sa needs, na naging dahilan upang tumakbo ang mga kasunod na trabaho, na hindi dapat nangyari. Ang pag-uugali na ito ay naayos sa bersyon 13.4, at needs ngayon ay wastong humahawak ng mga kaso ng mga hindi nasagot na gawain.
ΠΈ .
I-pin ang last quest artifact para maiwasang ma-delete ito
(CORE, STARTER, PREMIUM, ULTIMATE, LIBRE, BRONZE, SILVER, GOLD)
Awtomatikong ni-lock ng GitLab ang huling matagumpay na trabaho at pipeline artifact sa anumang aktibong sangay, kahilingan sa pag-merge, o tag upang maiwasan itong matanggal pagkatapos mag-expire. Nagiging mas madali ang magtakda ng mas agresibong mga panuntunan sa pag-expire upang linisin ang mga lumang artifact. Nakakatulong ito na bawasan ang pagkonsumo ng espasyo sa disk at tinitiyak na palagi kang may kopya ng pinakabagong artifact mula sa pipeline.
ΠΈ .
CI/CD na Gabay sa Pag-optimize ng Pipeline
(CORE, STARTER, PREMIUM, ULTIMATE, LIBRE, BRONZE, SILVER, GOLD)
Ang pag-optimize sa iyong pipeline ng CI/CD ay maaaring mapabuti ang bilis ng paghahatid at makatipid ng pera. Pinahusay namin ang aming dokumentasyon upang magsama ng mabilis na gabay para masulit ang pag-optimize ng iyong mga pipeline.
ΠΈ .
Ang ulat ng pagsubok ay pinagsunod-sunod ayon sa katayuan ng pagsubok
(CORE, STARTER, PREMIUM, ULTIMATE, LIBRE, BRONZE, SILVER, GOLD)
ay isang madaling paraan upang makita ang mga resulta ng lahat ng mga pagsubok sa isang pipeline. Gayunpaman, sa isang malaking bilang ng mga pagsubok, ang paghahanap ng mga nabigong pagsusulit ay maaaring tumagal ng mahabang panahon. Ang iba pang mga isyu na maaaring magpahirap sa ulat na gamitin ay kinabibilangan ng kahirapan sa pag-scroll sa mga mahahabang trace na output at pag-ikot ng oras sa zero para sa mga pagsubok na tumatakbo nang wala pang 1 segundo. Ngayon, bilang default, kapag nagbubukod-bukod ng isang pagsubok na ulat, inilalagay muna nito ang mga nabigong pagsubok sa simula ng ulat, at pagkatapos ay pinagbubukod-bukod ang mga pagsubok ayon sa tagal. Ginagawa nitong mas madali ang paghahanap ng mga pagkabigo at mahabang pagsubok. Bukod pa rito, ipinapakita na ngayon ang mga tagal ng pagsubok sa mga millisecond o segundo, na ginagawang mas mabilis itong basahin, at nalutas na rin ang mga nakaraang isyu sa pag-scroll.
ΠΈ .
Mga limitasyon sa laki ng mga file na na-upload sa package registry
(CORE, STARTER, PREMIUM, ULTIMATE, LIBRE, BRONZE, SILVER, GOLD)
Mayroon na ngayong mga limitasyon sa laki ng mga package file na maaaring i-upload sa GitLab package registry. Nagdagdag ng mga paghihigpit upang ma-optimize ang pagganap ng pagpapatala ng package at maiwasan ang pang-aabuso. Ang mga limitasyon ay nag-iiba depende sa format ng package. Para sa GitLab.com, ang mga maximum na laki ng file ay:
- Conan: 250MB
- Maven: 3GB
- NPM: 300MB
- NuGet: 250MB
- PyPI: 3GB
Para sa mga custom na pagkakataon sa GitLab, pareho ang mga default. Gayunpaman, maaaring i-update ng administrator ang mga paghihigpit gamit .
ΠΈ .
Gamitin ang CI_JOB_TOKEN para mag-publish ng mga PyPI package
(CORE, STARTER, PREMIUM, ULTIMATE, LIBRE, BRONZE, SILVER, GOLD)
Maaari mong gamitin ang GitLab PyPI repository para gumawa, mag-publish, at magbahagi ng mga Python package kasama ng source code at CI/CD pipelines. Gayunpaman, dati ay hindi ka makapag-authenticate sa repository gamit ang isang paunang natukoy na variable ng kapaligiran CI_JOB_TOKEN. Bilang resulta, kinailangan mong gamitin ang iyong mga personal na kredensyal upang i-update ang repositoryo ng PyPI, o maaaring nagpasya kang huwag nang gamitin ang repositoryo.
Mas madali na ngayong gamitin ang GitLab CI/CD para mag-publish at mag-install ng mga package ng PyPI gamit ang isang paunang natukoy na variable ng kapaligiran CI_JOB_TOKEN.
ΠΈ .
Mga profile ng DAST scanner kapag hiniling
(ULTIMATE, GOLD)
Sa on-demand na DAST scan noon , ang mga profile ng DAST scanner ay naidagdag. Pinapalawak nila ang mga kakayahan sa pagsasaayos ng mga pag-scan na ito, na nagbibigay-daan sa iyong mabilis na lumikha ng maraming profile upang masakop ang maraming uri ng pag-scan. Sa 13.4, native na kasama sa profile ng crawler ang setting ng timeout ng crawler na nagtatakda kung gaano katagal dapat tumakbo ang DAST crawler habang sinusubukan nitong tuklasin ang lahat ng page ng isang na-crawl na site. Kasama rin sa profile ang setting ng pag-timeout ng target na site upang itakda kung gaano katagal dapat maghintay ang crawler para maging accessible ang isang site bago i-abort ang pag-crawl kung hindi tumugon ang site gamit ang 200 o 300 na status code. Habang patuloy naming pinapahusay Ang feature na ito ay magiging idinagdag sa profile ng scanner sa mga release sa hinaharap; idadagdag ang mga karagdagang parameter ng configuration.
ΠΈ .
Isang simpleng redirect configuration file para sa GitLab Pages
(CORE, STARTER, PREMIUM, ULTIMATE, LIBRE, BRONZE, SILVER, GOLD)
Kung gumagamit ka ng Mga Pahina ng GitLab at nais mong mas mahusay na pamahalaan ang mga pagbabago sa URL, maaaring napansin mo na hindi posible ang pamamahala ng mga pag-redirect sa iyong site ng Mga Pahina sa GitLab. Binibigyang-daan ka na ngayon ng GitLab na i-configure ang mga panuntunan upang i-redirect ang isang URL patungo sa isa pa para sa iyong site ng Pages sa pamamagitan ng pagdaragdag ng configuration file sa repository. Ang tampok na ito ay naging posible salamat sa kontribusyon ni Kevin Barnett (), ang aming Eric Eastwood () at mga koponan ng GitLab. Salamat sa lahat para sa iyong input.
ΠΈ .
Terraform state na pinamamahalaan ng GitLab
(CORE, STARTER, PREMIUM, ULTIMATE, LIBRE, BRONZE, SILVER, GOLD)
Ang pag-access sa mga nakaraang bersyon ng estado ng Terraform ay kinakailangan kapwa para sa pagsunod at para sa pag-debug kung kinakailangan. Ang suporta para sa bersyon ng Terraform state na pinamamahalaan ng GitLab ay ibinibigay simula sa GitLab 13.4. Awtomatikong pinapagana ang pag-bersyon para sa mga bagong Terraform state file. Ang mga kasalukuyang file ng estado ng Terraform ay magiging sa susunod na paglabas.
ΠΈ .
Mahalagang Detalye ng Notification ng Insidente
(CORE, STARTER, PREMIUM, ULTIMATE, LIBRE, BRONZE, SILVER, GOLD)
Kapag nagpoproseso ng mga insidente, kailangan mong madaling matukoy kung gaano katagal nakabukas ang isang alerto at kung gaano karaming beses na-trigger ang kaganapan. Ang mga detalyeng ito ay madalas na kritikal sa pagtukoy ng epekto sa customer at kung ano ang dapat unang tugunan ng iyong team. Sa bagong panel ng Mga Detalye ng Insidente, ipinapakita namin ang oras ng pagsisimula ng alerto, ang bilang ng mga kaganapan, at isang link sa orihinal na alerto. Ang impormasyong ito ay magagamit para sa mga insidente na nabuo mula sa mga alerto.
ΠΈ .
Pagtatakda at pag-edit ng parameter ng kalubhaan ng insidente
(CORE, STARTER, PREMIUM, ULTIMATE, LIBRE, BRONZE, SILVER, GOLD)
Ang dimensyon ng Kalubhaan ng Insidente ay nagbibigay-daan sa mga tumutugon at stakeholder na matukoy ang epekto ng isang outage, pati na rin ang paraan at pagkaapurahan ng pagtugon. Habang nagbabahagi ang iyong koponan ng mga resulta sa panahon ng paglutas ng insidente at pagbawi, maaari nilang baguhin ang setting na ito. Maaari mo na ngayong i-edit ang kalubhaan ng isang insidente sa kanang sidebar ng pahina ng Mga Detalye ng Insidente, at ang kalubhaan ay ipinapakita sa listahan ng mga insidente.
ΠΈ .
Paggawa, pag-edit at pagtanggal ng mga panuntunan sa seguridad ng network ng container
(ULTIMATE, GOLD)
Ang pagpapahusay na ito sa Container Network Security Rule Editor ay nagbibigay-daan sa mga user na madaling gumawa, mag-edit, at magtanggal ng kanilang mga panuntunan nang direkta mula sa GitLab user interface. Kasama sa mga feature ng editor .yaml para sa mga may karanasang user at isang editor ng panuntunan na may madaling gamitin na interface para sa mga bago sa mga panuntunan sa network. Makakahanap ka ng mga bagong opsyon sa pamamahala ng mga panuntunan sa seksyon Seguridad at Pagsunod > Pamamahala sa Banta > Mga Panuntunan (Seguridad at Pagsunod > Pamamahala sa Banta > Mga Patakaran).
ΠΈ .
Suporta sa imbakan ng Azure blob
(CORE, STARTER, PREMIUM, ULTIMATE, LIBRE, BRONZE, SILVER, GOLD)
Parehong sinusuportahan na ngayon ng GitLab at GitLab Runner , na ginagawang mas madali ang pagpapatakbo ng mga serbisyo ng GitLab sa Azure.
Sinusuportahan ng mga instance ng GitLab ang Azure para sa lahat ng uri ng mga object store, kabilang ang mga LFS file, CI artifact, at . Upang i-set up ang Azure Blob storage, sundin ang mga tagubilin sa pag-install o .
Sinusuportahan din ng mga tagaproseso ng trabaho ng GitLab ang Azure para sa imbakan . Maaaring i-configure ang Azure storage gamit ang seksyon .
ΠΈ .
Omnibus ARM64 packages para sa Ubuntu at OpenSUSE
(CORE, STARTER, PREMIUM, ULTIMATE)
Bilang tugon sa lumalaking pangangailangan para sa suporta para sa pagpapatakbo ng GitLab sa 64-bit na arkitektura ng ARM, ikinalulugod naming ipahayag ang pagkakaroon ng opisyal na ARM64 Ubuntu 20.04 Omnibus package. Malaking pasasalamat kina Zitai Chen at Guillaume Gardet para sa malalaking kontribusyon na ginawa nila - ang kanilang mga kahilingan sa pagsasanib ay may mahalagang papel dito!
Upang i-download at i-install ang package para sa Ubuntu 20.04, pumunta sa aming at piliin Ubuntu.
ΠΈ .
Suporta sa pagpapatunay ng smart card para sa tsart ng GitLab Helm
(PREMIUM, ULTIMATE)
Magagamit na ngayon ang mga smart card, gaya ng Common Access Cards (CAC), para mag-authenticate sa isang GitLab instance na naka-deploy sa pamamagitan ng Helm chart. Ang mga smart card ay napatotohanan laban sa isang lokal na database gamit ang mga X.509 na sertipiko. Sa pamamagitan nito, ang suporta sa smart card na may Helm chart ay naaayon na ngayon sa suporta sa smart card na available sa mga deployment ng Omnibus.
ΠΈ .
Ang mga detalyadong tala sa paglabas at mga tagubilin sa pag-update/pag-install ay mababasa sa orihinal na post sa Ingles: .
Nagtatrabaho kami sa pagsasalin mula sa Ingles , , ΠΈ .
Pinagmulan: www.habr.com