GitLab 11.10 na may mga pipeline ng dashboard, mga pipeline ng pinagsanib na resulta, at mga suhestyon sa maraming linya sa mga kahilingan sa pagsasama.
Maginhawang impormasyon tungkol sa kalusugan ng mga pipeline sa iba't ibang proyekto
Patuloy na pinapataas ng GitLab ang transparency ng ikot ng buhay ng DevOps. Sa edisyong ito sa control panel nagdagdag ng pangkalahatang-ideya ng katayuan ng mga pipeline.
Ito ay maginhawa kahit na pinag-aaralan mo ang pipeline ng isang proyekto, ngunit ito ay lalong kapaki-pakinabang kung ilang proyekto, - at kadalasang nangyayari ito kung gumagamit ka ng mga microservice at gusto mong magpatakbo ng pipeline para sa pagsubok at pagbibigay ng code mula sa iba't ibang mga repositoryo ng proyekto. Ngayon ay makikita mo kaagad ang pagganap mga pipeline sa control panelsaan man sila ginaganap.
Pagpapatakbo ng mga pipeline para sa mga pinagsama-samang resulta
Sa paglipas ng panahon, ang pinagmulan at target na mga sangay ay nag-iiba, at maaaring mayroong isang sitwasyon kung saan sila ay makakayanan nang hiwalay, ngunit hindi nagtutulungan. Kaya mo na ngayon magpatakbo ng mga pipeline para sa mga pinagsamang resulta bago pagsamahin. Kaya mabilis mong mapapansin ang mga error na lilitaw lamang kung madalas kang maglilipat ng mga pagbabago sa pagitan ng mga sangay, na nangangahulugan na mas mabilis mong aayusin ang mga error sa pipeline at magiging mas mahusay sa paggamit Runner ng GitLab.
Karagdagang pag-optimize ng pakikipagtulungan
Ang GitLab 11.10 ay nagdadala ng higit pang mga tampok para sa madaling pakikipagtulungan at mga pinasimple na daloy ng trabaho. SA nakaraang isyu ipinakilala namin ang mga suhestiyon sa kahilingan sa pagsama-sama, kung saan maaaring magmungkahi ang isang tagasuri ng pagbabago sa isang linya sa isang komento ng kahilingan sa pagsama-sama, at maaari itong direktang gawin nang direkta mula sa thread ng komento. Nagustuhan ito ng aming mga user at hiniling na palawakin ang feature na ito. Ngayon ay maaari kang mag-alok mga pagbabago para sa maraming linya, na tumutukoy kung aling mga linya ang aalisin at kung alin ang idaragdag.
Ang dashboard sa GitLab ay nagpapakita ng impormasyon tungkol sa mga proyekto sa buong GitLab instance. Magdadagdag ka ng mga indibidwal na proyekto nang paisa-isa at mapipili kung aling proyekto ang interesado ka.
Sa release na ito, nagdagdag kami ng impormasyon sa status ng pipeline sa dashboard. Ngayon ay makikita ng mga developer ang pagganap ng mga pipeline sa lahat ng kinakailangang proyekto - sa isang interface.
Mga pipeline para sa mga pinagsamang resulta
PREMIUM, ULTIMATE, SILVER, GOLD
Karaniwan, sa paglipas ng panahon, ang pinagmulang sangay ay lumilihis mula sa target na sangay, maliban kung palagi kang naglilipat ng mga pagbabago sa pagitan nila. Bilang resulta, berde ang mga pipeline ng pinagmulan at target na mga sanga at walang mga pagsasalungat sa pagsasanib, ngunit nabigo ang pagsasanib dahil sa mga hindi tugmang pagbabago.
Kapag ang pipeline ng kahilingan sa pagsasanib ay awtomatikong gumagawa ng bagong link na naglalaman ng pinagsamang resulta ng pagsasama ng pinagmulan at mga target na sangay, maaari naming patakbuhin ang pipeline sa link na iyon at matiyak na gumagana ang pangkalahatang resulta.
Kung gumagamit ka ng merge request pipelines (sa anumang kapasidad) at gumagamit ng pribadong GitLab runners na bersyon 11.8 o mas luma, kailangan nilang ma-update para maiwasan ang isyu gitlab-ee#11122. Hindi ito makakaapekto sa mga user ng pampublikong GitLab runner.
Kapag nakikipagtulungan sa mga kahilingan sa pagsasama, madalas kang makakita ng mga problema at makabuo ng mga solusyon. Dahil ang GitLab 11.6 ay sinusuportahan namin baguhin ang panukala para sa isang linya.
Sa bersyon 11.10, ang mga komento sa isang merge request diff ay maaaring magmungkahi ng mga pagbabago para sa maraming linya, at pagkatapos ay sinumang may pahintulot na sumulat sa orihinal na sangay ay maaaring gumawa ng mga ito sa isang solong push. Salamat sa bagong feature, maiiwasan mo ang copy-paste, tulad ng sa mga nakaraang bersyon.
Mga shortcut sa isang lugar
PREMIUM, ULTIMATE, SILVER, GOLD
Gamit ang mga label sa parehong saklaw, maaaring maglapat ang mga team ng mga label na magkaparehong eksklusibo (sa parehong saklaw) sa isang isyu, kahilingan sa pagsasanib, o epiko sa mga senaryo na may mga custom na field o custom na estado ng daloy ng trabaho. Na-configure ang mga ito gamit ang espesyal na syntax na may colon sa header ng label.
Sabihin nating kailangan mo ng custom na field sa mga gawain upang masubaybayan ang operating system ng platform na tina-target ng iyong mga function. Ang bawat gawain ay dapat na nabibilang lamang sa isang platform. Maaaring gumawa ng mga shortcut platform::iOS, platform::Android, platform::Linux at iba pa kung kinakailangan. Ang paglalapat ng isang ganoong shortcut sa isang gawain ay awtomatikong magtatanggal ng isa pang umiiral na shortcut na nagsisimula sa platform::.
Sabihin nating mayroon kang mga label workflow::development, workflow::review ΠΈ workflow::deployed, na nagsasaad ng status ng workflow sa iyong team. Kung ang gawain ay mayroon nang label workflow::development, at gustong ilipat ng developer ang gawain sa entablado workflow::review, inilalapat lang nito ang bagong shortcut at ang luma (workflow::development) ay awtomatikong nabubura. Umiiral na ang gawi na ito kapag inilipat mo ang mga gawain sa pagitan ng mga listahan ng label sa task board, na kumakatawan sa daloy ng trabaho ng iyong team. Ang mga miyembro ng team na hindi direktang gumagana sa task board ay maaari na ngayong baguhin ang workflow state sa mga gawain mismo.
Sa normal na paggamit ng isang container registry na may mga CI pipeline, nagsusumite ka ng maraming hiwalay na pagbabago sa iisang tag. Dahil sa pagpapatupad ng pamamahagi ng Docker, ang default na gawi ay i-save ang lahat ng mga pagbabago sa system, ngunit nauuwi ang mga ito sa pagkuha ng maraming memorya. Kung gagamitin mo ang parameter -m Ρ registry-garbage-collect, maaari mong mabilis na tanggalin ang lahat ng nakaraang pagbabago at magbakante ng mahalagang espasyo.
Pagbili ng Karagdagang CI Runner Minutes
BRONSE, SILVER, GOLD
Ang mga user na may mga bayad na plano ng GitLab.com (Gold, Silver, Bronze) ay maaari na ngayong bumili ng karagdagang CI Runner minuto. Dati, kinakailangang manatili sa loob ng quota na ibinigay ng plano. Sa pagpapahusay na ito, maaari kang bumili ng ilang minuto ng over-quota upang maiwasan ang mga pagkaantala dahil sa mga pag-shutdown ng pipeline.
Ngayon, ang 1000 minuto ay nagkakahalaga ng $8 at maaari kang bumili ng marami hangga't gusto mo. Magsisimulang maubos ang mga dagdag na minuto kapag ginamit mo ang buong buwanang quota, at ang natitirang mga dagdag na minuto ay dadalhin sa susunod na buwan. SA pagpapalabas sa hinaharap gusto din naming idagdag ang feature na ito sa mga libreng plano.
Sa Auto DevOps, halos walang kahirap-hirap ang paglipat ng mga team sa modernong mga kasanayan sa DevOps. Simula sa GitLab 11.10, ang bawat trabaho sa Auto DevOps ay ibinibigay bilang malayang pattern. Maaaring gamitin ng mga gumagamit ΡΡΠ½ΠΊΡΠΈΡ includes sa GitLab CI upang paganahin ang hiwalay na mga yugto ng Auto DevOps at gamitin pa rin ang iyong custom na file gitlab-ci.yml. Sa ganitong paraan maaari mo lamang isama ang mga trabahong kailangan mo at tamasahin ang mga benepisyo ng upstream update.
Awtomatikong pamahalaan ang mga miyembro ng grupo sa GitLab.com gamit ang SCIM
PILAK GINTO
Noong nakaraan, ang mga membership ng grupo sa GitLab.com ay kailangang manual na pamahalaan. Maaari mo na ngayong gamitin ang SAML SSO at pamahalaan ang membership sa SCIM para gumawa, magtanggal, at mag-update ng mga user sa GitLab.com.
Ito ay lalong kapaki-pakinabang para sa mga kumpanyang may malaking bilang ng mga user at sentralisadong tagapagbigay ng pagkakakilanlan. Ngayon ay maaari kang magkaroon ng iisang pinagmulan ng katotohanan tulad ng Azure Active Directory at awtomatikong gumawa at magtanggal ng mga user sa pamamagitan ng identity provider sa halip na manu-mano.
Mag-login sa GitLab.com sa pamamagitan ng isang SAML provider
PILAK GINTO
Dati, kapag gumagamit ng SAML SSO para sa mga grupo, kailangang mag-sign in ang user gamit ang mga kredensyal ng GitLab at isang identity provider. Maaari ka na ngayong direktang mag-log in sa pamamagitan ng SSO bilang isang user ng GitLab na nauugnay sa naka-configure na grupo.
Hindi na kailangang mag-sign in nang dalawang beses ang mga user, kaya mas maginhawa para sa mga kumpanya na gumamit ng SAML SSO para sa GitLab.com.
Iba pang mga pagpapabuti sa GitLab 11.10
Schema ng mga epiko ng bata
ULTIMATE, GINTO
Sa nakaraang release, nagdagdag kami ng child epics (epics of epics) para mas madali para sa iyo na pamahalaan ang quest distribution structure. Ang mga child epic ay ipinapakita sa parent epic page.
Sa release na ito, ang parent epic page ay nagpapakita ng outline ng child epics para makita ng mga team ang child epic timeline at mapamahalaan ang mga dependency sa oras.
Sa release na ito, ipinapakilala namin ang mga screen na nagbibigay-kaalaman na lumalabas kapag nag-hover ka sa isang link ng kahilingan sa pagsasama. Dati, ipinakita lang namin ang pamagat ng kahilingan sa pagsama-sama, ngunit ngayon ay ipinapakita na rin namin ang status ng kahilingan sa pagsasama, ang katayuan ng pipeline ng CI, at ang maikling URL.
Ang mga daloy ng trabaho sa Git para sa pagpapalabas o pamamahagi ng software ay kadalasang nagsasangkot ng maraming pangmatagalang sangay upang magdala ng mga pag-aayos sa mga nakaraang bersyon (halimbawa, stable-11-9) o ang paglipat mula sa kalidad ng kasiguruhan sa produksyon (halimbawa, integration), ngunit hindi madaling makahanap ng mga kahilingan sa pagsasanib para sa mga sangay na ito sa maraming bukas na kahilingan sa pagsasama.
Ang listahan ng mga kahilingan sa pagsasanib para sa mga proyekto at mga koponan ay maaari na ngayong i-filter ng target na sangay ng kahilingan sa pagsasama upang gawing mas madaling mahanap ang tama.
Kung gagamitin natin ang paraan ng pag-unlad na nakabatay sa Trunk, dapat nating iwasan ang mga pangmatagalang sangay na pabor sa maliliit na pansamantalang sangay na may isang may-ari. Ang maliliit na pagbabago ay kadalasang direktang itinutulak sa target na sangay, ngunit sa paggawa nito, nanganganib tayong masira ang build.
Sa paglabas na ito, sinusuportahan ng GitLab ang mga bagong pagpipilian sa pag-push sa Git upang awtomatikong buksan ang mga kahilingan sa pagsasama, itakda ang target na sangay, at magbigay ng merge kapag matagumpay na naisakatuparan ang isang pipeline mula sa command line habang nagtutulak sa isang sangay.
Pinahusay na pagsasama sa mga panlabas na dashboard
Maaaring ma-access ng GitLab ang maramihang mga server ng Prometheus (kapaligiran, proyekto, at mga pangkat (inaasahan)), ngunit ang pagkakaroon ng maraming mga endpoint ay maaaring magdagdag ng pagiging kumplikado o hindi suportado ng mga karaniwang dashboard. Sa paglabas na ito, magagamit ng mga team ang parehong Prometheus API, na ginagawang mas madali ang pagsasama sa mga serbisyo tulad ng Grafana.
Pagbukud-bukurin ang mga pahina ng Wiki ayon sa petsa ng paglikha
Sa isang proyektong Wiki, ang mga koponan ay maaaring magbahagi ng dokumentasyon at iba pang mahalagang impormasyon kasama ng source code at mga gawain. Sa release na ito, ang listahan ng mga pahina sa Wiki ay maaaring pagbukud-bukurin ayon sa petsa ng paggawa at pamagat upang mabilis na mahanap ang kamakailang nilikhang nilalaman.
Pagsubaybay sa mga mapagkukunan na hiniling ng cluster
ULTIMATE, GINTO
Tinutulungan ka ng GitLab na subaybayan ang iyong Kubernetes cluster para sa development at production na mga application. Simula sa release na ito, subaybayan ang CPU at memory na hiniling ng cluster upang mapansin ang mga potensyal na isyu bago sila maging mga problema.
Tingnan ang Mga Sukatan ng Load Balancer sa Grafana Dashboard
CORE, STARTER, PREMIUM, ULTIMATE
Napakahalaga na subaybayan ang kalusugan ng halimbawa ng GitLab. Nagbigay kami noon ng mga default na dashboard sa pamamagitan ng built-in na Grafana instance. Simula sa release na ito, nagsama kami ng mga karagdagang dashboard para sa pagsubaybay sa NGINX load balancers.
SAST para sa Elixir
ULTIMATE, GINTO
Patuloy kaming nagpapalawak ng suporta sa wika at nagpapalalim ng mga pagsusuri sa seguridad. Sa release na ito, pinagana namin ang mga pagsusuri sa seguridad para sa mga proyekto sa Elixir at mga proyektong ginawa sa Platform ng Phoenix.
Maramihang mga query sa isang chart
PREMIUM, ULTIMATE, SILVER, GOLD
Binibigyang-daan ka ng GitLab na lumikha ng mga chart upang mailarawan ang mga sukatan na iyong kinokolekta. Kadalasan - halimbawa, kung gusto mong makita ang maximum o average na halaga ng isang sukatan - gusto mong magpakita ng ilang value sa isang chart. Simula sa release na ito, mayroon kang pagpipiliang ito.
Nagreresulta ang DAST sa panel ng seguridad ng grupo
Nagdagdag kami ng mga resulta ng Dynamic Application Security Testing (DAST) sa Team Security Dashboard bilang karagdagan sa SAST, Container Scan, at Dependency Scan.
Pagdaragdag ng Metadata sa isang Container Scan Report
ULTIMATE, GINTO
Sa release na ito, naglalaman ang Container Scan Report ng higit pang metadata - idinagdag namin apektadong sangkap (isang feature ng Clair) sa kasalukuyang metadata: priority, identifier (na may link sa mitre.org) at apektadong antas (halimbawa, debian:8).
Pagdaragdag ng uri ng ulat ng sukatan upang pagsamahin ang mga kahilingan
PREMIUM, ULTIMATE, SILVER, GOLD
Nagbibigay na ang GitLab ng ilang uri ng mga ulat na maaaring direktang isama sa mga kahilingan sa pagsasanib, mula sa mga ulat tungkol sa bilang isang code ΠΈ pagsubok ng yunit sa yugto ng pagpapatunay SAST ΠΈ dast sa yugto ng proteksyon.
At bagama't mahalagang mga ulat ito, kailangan din ang pangunahing impormasyong angkop para sa iba't ibang sitwasyon. Sa GitLab 11.10, nagbibigay kami ng pag-uulat ng mga sukatan sa mismong kahilingan sa pagsasama, na umaasa sa isang simpleng pares ng key-value. Sa ganitong paraan, sinusubaybayan ng mga user ang mga pagbabago sa paglipas ng panahon, kabilang ang mga sukatan ng user, at mga pagbabago sa mga sukatan para sa isang partikular na kahilingan sa pagsasama. Ang paggamit ng memorya, espesyal na pagsubok sa workload, at mga katayuan sa kalusugan ay maaaring ma-convert sa mga simpleng sukatan na direktang matingnan sa mga kahilingan sa pagsasama kasama ng iba pang mga built-in na ulat.
Suporta para sa mga multi-module na proyekto ng Maven para sa pag-scan ng dependency
ULTIMATE, GINTO
Sa paglabas na ito, sinusuportahan ng mga multi-module na proyekto ng Maven ang pag-scan ng dependency sa GitLab. Dati, kung ang isang submodule ay may dependency sa isa pang submodule ng parehong antas, hindi ito maaaring payagang ma-load mula sa central Maven repository. Ngayon ang isang multi-module na proyekto ng Maven ay nilikha na may dalawang module at isang dependency sa pagitan ng dalawang module. Ang dependency sa pagitan ng magkakapatid na mga module ay magagamit na ngayon sa lokal na repositoryo ng Maven upang magpatuloy ang pagbuo.
Bilang default, kino-clone ng GitLab Runner ang proyekto sa isang natatanging subpath sa $CI_BUILDS_DIR. Ngunit para sa ilang mga proyekto, tulad ng Golang, ang code ay kailangang ma-clone sa isang partikular na direktoryo upang maitayo.
Sa GitLab 11.10 ipinakilala namin ang variable GIT_CLONE_PATH, kung saan maaari mong tukuyin ang partikular na landas kung saan kino-clone ng GitLab Runner ang proyekto bago isagawa ang gawain.
Simpleng pag-mask ng mga protektadong variable sa mga log
Nagbibigay ang GitLab ng ilang paraan upang protektahan ΠΈ limitahan ang lugar mga variable sa GitLab CI/CD. Ngunit ang mga variable ay maaari pa ring mapunta sa mga build log nang sinasadya o hindi sinasadya.
Sineseryoso ng GitLab ang pamamahala sa peligro at pag-audit at patuloy na nagdaragdag ng mga feature sa pagsunod. Sa GitLab 11.10, ipinakilala namin ang kakayahang i-mask ang ilang uri ng mga variable sa mga trace log ng trabaho, pagdaragdag ng layer ng proteksyon laban sa hindi sinasadyang pagpasok ng mga nilalaman ng mga variable na ito sa mga log. At ngayon GitLab awtomatikong nag-mask maraming mga built-in na variable ng token.
I-enable o i-disable ang Auto DevOps sa antas ng pangkat
Sa Auto DevOps sa proyekto ng GitLab.com, madali mong matutugunan ang mga modernong DevOps workflow mula sa build hanggang sa paghahatid.
Simula sa GitLab 11.10, maaari mong paganahin at i-disable ang Auto DevOps para sa lahat ng proyekto sa parehong grupo.
Pinasimple at pinahusay na pahina ng lisensya
STARTER, PREMIUM, ULTIMATE
Upang gawing mas madali at mas maginhawa ang pamamahala sa mga susi ng lisensya, muling idinisenyo namin ang pahina ng lisensya sa admin panel at na-highlight ang pinakamahahalagang elemento.
Na-update na shortcut selector para sa mga deployment ng Kubernetes
Ipinapakita ng mga deployment panel ang mga detalye ng lahat ng deployment ng Kubernetes.
Sa release na ito, binago namin ang paraan ng pagmamapa ng mga label sa mga deployment. Available na ang mga laban app.example.com/app ΠΈ app.example.com/env o app. Maiiwasan nito ang pag-filter ng mga salungatan at ang panganib ng mga maling deployment na nauugnay sa proyekto.
Binibigyang-daan ka ng pagsasama ng Kubernetes sa GitLab na gamitin ang feature na RBAC sa isang account ng serbisyo at isang nakalaang namespace para sa bawat proyekto ng GitLab. Simula sa release na ito, para sa maximum na kahusayan, ang mga mapagkukunang ito ay gagawin lamang kapag kinakailangan para sa pag-deploy.
Kapag nagde-deploy ng Kubernetes, gagawin ng GitLab CI ang mga mapagkukunang ito bago i-deploy.
Group runners para sa mga cluster sa antas ng grupo
Sinusuportahan na ngayon ng mga cluster sa antas ng pangkat ang pag-install ng GitLab Runner. Lumilitaw ang mga runner ng Kubernetes sa antas ng pangkat bilang mga may label na runner ng grupo para sa mga proyekto ng bata cluster ΠΈ kubernetes.
Na-deploy ang mga feature na may Walang Server ng GitLab, ngayon ay ipakita ang bilang ng mga tawag na natanggap para sa isang partikular na function. Upang gawin ito, kailangan mong i-install ang Prometheus sa kumpol kung saan naka-install ang Knative.
Kontrol ng parameter git clean para sa mga trabaho sa GitLab CI/CD
Bilang default, ang GitLab Runner ay nagsasagawa git clean sa proseso ng pag-unload ng code kapag nagsasagawa ng trabaho sa GitLab CI / CD. Simula sa GitLab 11.10, makokontrol ng mga user ang mga parameter na ipinasa sa command git clean. Ito ay kapaki-pakinabang para sa mga team na may dedikadong runner, gayundin para sa mga team na nangongolekta ng mga proyekto mula sa malalaking mono-repositories. Ngayon ay maaari na nilang kontrolin ang proseso ng pag-upload bago isagawa ang mga script. Bagong variable GIT_CLEAN_FLAGS default na halaga -ffdx at tinatanggap ang lahat ng posibleng mga parameter ng command [git clean](https://git-scm.com/docs/git-clean).
Ang mga secure na kapaligiran ay maaaring mangailangan ng karagdagang panlabas na mapagkukunan ng pahintulot upang ma-access ang proyekto. Nagdagdag kami ng suporta para sa karagdagang layer ng access control sa 10.6 at nakatanggap ng maraming kahilingan para buksan ang functionality na ito sa Core. Ikinalulugod naming ipakilala ang panlabas na awtorisasyon at isang karagdagang layer ng seguridad para sa mga Core na pagkakataon, dahil ang feature na ito ay kailangan ng mga indibidwal na kalahok.
Kakayahang lumikha ng mga proyekto sa mga pangkat sa Core
Ang tungkulin ng developer ay maaaring gumawa ng mga proyekto sa mga pangkat mula noong bersyon 10.5, at ngayon ay posible na sa Core. Ang paggawa ng proyekto ay isang pangunahing tampok sa pagiging produktibo sa GitLab, at sa pagsasama ng tampok na ito sa Core, mas madali na ngayon para sa mga miyembro na gumawa ng bago.
Ngayon inilabas namin ang GitLab Runner 11.10! Ang GitLab Runner ay isang open source na proyekto na ginagamit upang magpatakbo ng mga trabaho sa CI/CD at itulak ang mga resulta pabalik sa GitLab.
Ang buong listahan ng mga pagbabago ay matatagpuan sa GitLab Runner changelog: CHANGELOG.
Ibinalik ang pag-aayos project_id sa blob search API sa Elasticsearch
STARTER, PREMIUM, ULTIMATE
Nag-ayos kami ng bug sa blob search API ng Elasticsearch na hindi wastong nagbabalik ng 0 para sa project_id. Ito ay kinakailangan muling i-index ang Elasticsearchupang makakuha ng mga tamang halaga project_id pagkatapos i-install ang bersyong ito ng GitLab.
Mga pagpapabuti sa Omnibus
CORE, STARTER, PREMIUM, ULTIMATE
Ginawa namin ang mga sumusunod na pagpapabuti sa Omnibus sa GitLab 11.10:
Patuloy naming pinapahusay ang performance ng GitLab sa bawat release para sa mga instance ng GitLab sa anumang laki. Ilang mga pagpapabuti sa GitLab 11.10:
Ang GitLab Geo ay magdadala ng naka-hash na imbakan sa GitLab 12.0
Kinakailangan ang GitLab Geo na-hash na imbakan upang pagaanin ang kumpetisyon sa mga pangalawang node. Ito ay nabanggit sa gitlab-ce#40970.
Sa GitLab 11.5 idinagdag namin ang kinakailangang ito sa dokumentasyong Geo: gitlab-ee#8053.
Sa GitLab 11.6sudo gitlab-rake gitlab:geo:check sinusuri kung ang naka-hash na storage ay pinagana at kung ang lahat ng mga proyekto ay inilipat. Cm. gitlab-ee#8289. Kung gumagamit ka ng Geo, mangyaring patakbuhin ang pagsusuring ito at mag-migrate sa lalong madaling panahon.
Sa GitLab 11.8 babala na permanenteng may kapansanan gitlab-ee!8433 ay ipapakita sa pahina Lugar ng Admin > Geo > Nodekung ang mga pagsusuri sa itaas ay hindi pinapayagan.
Sa GitLab 12.0 Gagamitin ni Geo ang mga kinakailangan sa naka-hash na storage. Cm. gitlab-ee#8690.
Inihayag ng Canonical ang pagtatapos ng karaniwang suporta para sa Ubuntu 14.04 na may Abril 2019. Pinapayuhan namin ang mga user na mag-upgrade sa isang sinusuportahang bersyon ng LTS: Ubuntu 16.04 o Ubuntu 18.04.
Petsa ng pagtanggal: Ang 22 Mayo 2019 lungsod
Nililimitahan ang maximum na bilang ng mga pipeline na ginawa ng isang pagsusumite
Dati, gumawa ang GitLab ng mga pipeline para sa HEAD bawat sangay sa kargamento. Ito ay kapaki-pakinabang para sa mga developer na nagtutulak ng maraming pagbabago nang sabay-sabay (halimbawa, sa isang feature branch at a develop).
Ngunit kapag itinutulak ang isang malaking repositoryo kung saan maraming aktibong sanga (halimbawa, upang ilipat, salamin o tinidor), hindi mo kailangang lumikha ng isang pipeline para sa bawat sangay. Simula sa GitLab 11.10 na aming nilikha maximum na 4 na pipeline kapag nagpapadala.
Petsa ng pagtanggal: Ang 22 Mayo 2019 lungsod
Mga legacy code path ng GitLab Runner
Dahil ang Gitlab 11.9 GitLab Runner ay gumagamit bagong paraan pag-clone/pagtawag sa repositoryo. Sa kasalukuyan, gagamitin ng GitLab Runner ang lumang paraan kung hindi sinusuportahan ang bago. Tingnan ang higit pa sa ang gawaing ito.
Sa GitLab 11.0, binago namin ang view ng configuration ng server ng sukatan para sa GitLab Runner. metrics_server ay aalisin pabor sa listen_address sa GitLab 12.0. Tingnan ang higit pa sa ang gawaing ito.
Ang mga path na ito ay hindi magiging available sa GitLab 12.0. Bilang isang user, hindi mo kailangang baguhin ang anuman, siguraduhin lang na ang iyong GitLab instance ay tumatakbo sa bersyon 11.9+ kapag nag-upgrade ka sa GitLab Runner 12.0.
Petsa ng pagtanggal: 22 2019 Hunyo, ang
Hindi na ginagamit na opsyon para sa feature na entry point para sa GitLab Runner
Sa GitLab 12.0, lilipat kami sa tamang gawi na parang hindi pinagana ang setting ng feature. Tingnan ang higit pa sa ang gawaing ito.
Petsa ng pagtanggal: 22 2019 Hunyo, ang
Hindi na ginagamit ang suporta para sa isang pamamahagi ng Linux na umabot sa EOL para sa GitLab Runner
Ang ilang mga pamamahagi ng Linux kung saan maaari mong i-install ang GitLab Runner ay nakatulong sa kanilang layunin.
Sa GitLab 12.0, ang GitLab Runner ay hindi na mamamahagi ng mga pakete sa mga distribusyon ng Linux na ito. Ang isang kumpletong listahan ng mga pamamahagi na hindi na sinusuportahan ay makikita sa aming dokumentasyon. Salamat kay Javier ArdoJavier Jardon) sa likod kanyang kontribusyon!
Petsa ng pagtanggal: 22 2019 Hunyo, ang
Pag-alis ng mga lumang command ng GitLab Runner Helper
Pag-alis ng legacy na git clean na mekanismo mula sa GitLab Runner
Sa GitLab Runner 11.10 nagbibigay kami ng pagkakataon i-configure kung paano ipapatupad ng Runner ang isang command git clean. Bilang karagdagan, ang isang bagong diskarte sa paglilinis ay nag-aalis ng paggamit git reset at naglalagay ng utos git clean pagkatapos ng hakbang sa pag-upload.
Dahil maaaring makaapekto ang pagbabago sa gawi na ito sa ilang user, naghanda kami ng setting FF_USE_LEGACY_GIT_CLEAN_STRATEGY. Kung itinakda mo ang halaga true, ibabalik nito ang legacy na diskarte sa paglilinis. Higit pa tungkol sa paggamit ng mga parameter ng function sa GitLab Runner ay matatagpuan sa dokumentasyon.
Sa GitLab Runner 12.0, aalisin namin ang suporta para sa legacy na diskarte sa paglilinis at ang kakayahang ibalik ito gamit ang isang parameter ng function. Tingnan ang higit pa sa ang gawaing ito.
Petsa ng pagtanggal: 22 2019 Hunyo, ang
Seksyon ng Impormasyon ng System sa admin panel
Ang GitLab ay nagpapakita ng impormasyon tungkol sa iyong GitLab instance sa admin/system_info, ngunit maaaring hindi tumpak ang impormasyong ito.
Libre: Walang limitasyong pribadong repositoryo at walang limitasyong mga tagapag-ambag ng proyekto. Ang mga saradong proyekto ay may access sa mga feature na antas LibreMayroon bukas na mga proyekto magkaroon ng access sa mga tampok na antas Ginto (Gold).
Tanso (Bronze): para sa mga team na nangangailangan ng access sa mga advanced na feature ng workflow.
Pilak (Silver): Para sa mga team na naghahanap ng mas matatag na kakayahan sa DevOps, pagsunod, at mabilis na suporta.
Ginto (Gold): Angkop para sa maraming trabaho sa CI/CD. Maaaring gamitin ng lahat ng bukas na proyekto ang mga tampok na Gold nang libre, anuman ang plano.