GitLab 11.10 me pipeline në panelin e kontrollit, pipeline për rezultate të bashkuara dhe propozime për disa rreshta në kërkesat për bashkim.
Informacione të përshtatshme për funksionimin e pipeline-ve në projekte të ndryshme
GitLab vazhdon të rrisë transparencën e ciklit të jetës DevOps. Në këtë version, është shtuar një përmbledhje e statusit të pipeline-ve.
Kjo Ă«shtĂ« e dobishme, edhe nĂ«se po shqyrtoni njĂ« pipeline tĂ« njĂ« projekti, por veçanĂ«risht e dobishme nĂ«se â siç ndodh shpesh kur pĂ«rdorni microservices dhe dĂ«shironi tĂ« nisni njĂ« pipeline pĂ«r testimin dhe dorĂ«zimin e kodit nga repo tĂ« ndryshme projektesh. Tani e shihni menjĂ«herĂ« funksionalitetin pavarĂ«sisht se ku po ekzekutohen.
Nisja e pipeline-ve për rezultate të bashkuara
Me kalimin e kohës, degët burimore dhe të synuara ndahen, dhe mund të ndodhë që ato të funksionojnë ndaras, por jo së bashku. Tani mund të në këtë mënyrë do ta vini re shpejt çdo gabim që do të shfaqej vetëm me përmirësimin e ndryshimeve mes degëve, dhe kështu do të përmirësoni më shpejt gabimet e pipeline-it dhe do të jeni më efektivë në përdorim. .
Optimizimi i mëtejshem i bashkëpunimit
Në GitLab 11.10, ka më shumë mundësi për bashkëpunim të lehtë dhe procese të thjeshta. Në ne prezantuam propozime për kërkesat për bashkim, kur rishikuesi mund të sugjerojë një ndryshim në një linjë në komentet e kërkesës për bashkim dhe mund të angazhohet menjëherë drejtpërdrejt nga biseda e komenteve. Përdoruesit tanë e pëlqyen këtë, dhe kërkuan që ta zgjerojmë këtë funksion. Tani mund të sugjeroni duke treguar se cilat rreshta duhet të hiqen dhe cilat të shtohen.
Faleminderit për komentet dhe sugjerimet tuaja!
Dhe kjo nuk është gjithçka...
Në këtë version ka kaq shumë funksione mbresëlënëse, si për shembull, pastrim më i detajuar , dhe mundësia Më poshtë detajet për secilën prej tyre.
PunonjĂ«si mĂ« i çmuar i kĂ«tij muaji () â Takuya Noguti
Në këtë muaj, punonjësi më i vlefshëm është Takuya Noguti (). Takuya : kam korrigova defekte, përfundova detyrat e papërfunduara në backend dhe frontend dhe përmirësova ndërfaqen e përdoruesit. Faleminderit!
Karakteristikat Kryesore të GitLab 11.10
Pipeline në Panelin e Kontrollit
PREMIUM, ULTIMATE, SILVER, GOLD
Në panelin e kontrollit të GitLab shfaqen të dhëna për projektet në të gjithë instancën e GitLab. Shtoni projekte të veçanta një nga një dhe zgjidhni cilin projekt dëshironi.
Në këtë version kemi shtuar informacionin mbi statuset e pipeline-ve në panelin e kontrollit. Tani zhvilluesit shohin funksionimin e pipeline-ve në të gjithë projektet e nevojshme - në një ndërfaqe.
Pipeline për rezultatet e bashkuara
PREMIUM, ULTIMATE, SILVER, GOLD
Zakoni, me kalimin e kohës, dega burimore devijon nga ajo përfundimtare nëse nuk bëni vazhdimisht ndryshime mes tyre. Si rezultat, pipeline-t e degës burimore dhe asaj përfundimtare janë "të gjelbra" dhe nuk ka konflikte gjatë bashkimit, por gjatë bashkimit ndodh dështimi për shkak të moskonsistencës së ndryshimeve.
Kur pipeline-i i kërkesave për bashkim automatikisht krijon një lidhje të re që përmban rezultatin e bashkimit të degëve burimore dhe atyre përfundimtare, ne mund të nisnim pipeline-in për këtë lidhje dhe të garantojmë që rezultati përbashkët do të jetë funksional.
Nëse përdorni pipeline të kërkesave për bashkim (në çdo cilësi) dhe angazhoni GitLab-runners privatë versioni 11.8 ose më të vjetër, është e nevojshme t'i azhurnoni për të shmangur probleme. . Kjo nuk ndikon në përdoruesit e GitLab-runners publik.
Propozimi i ndryshimeve në disa rreshta
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Kur punoni së bashku mbi kërkesat për bashkim, shpesh vëreni probleme dhe propozoni zgjidhje. Prej versionit GitLab 11.6 ne mbështesim për një rresht.
Në versionin 11.10, në komentet në diff-in e kërkesës për bashkim, mund të propozoni ndryshime për disa rreshta dhe pastaj secili përdorues me leje për të shkruar në degën burimore mund t'i pranojë ato me një klik të vetëm. Falë funksionalitetit të ri, mund të shmangni kopjimin dhe ngjitjen, si në versionet e mëparshme.
Etiketat në një Zonë
PREMIUM, ULTIMATE, SILVER, GOLD
Me etiketat në një zonë, ekipet mund të aplikojnë etiketa përjashtuese (në të njëjtën zonë) për një detyrë, kërkesë për bashkim ose epik në skenarë me fusha të personalizuara ose gjendje të personalizuara të punës. Ato konfigurohen me një sintaksë të veçantë me dy pikë në titullin e etiketës.
Supozoni se ju nevojitet njĂ« fushĂ« e personalizuar nĂ« detyra pĂ«r tĂ« gjurmuar sistemin operativ tĂ« platformĂ«s, pĂ«r tĂ« cilin janĂ« orientuar funksionet tuaja. Ădo detyrĂ« duhet tĂ« lidhet vetĂ«m me njĂ« platformĂ«. Mund tĂ« krijoni etiketa platform::iOS, platform::Android, platform::Linux dhe tĂ« tjera sipas nevojĂ«s. NĂ«se njĂ« etiketĂ« e tillĂ« i jepet njĂ« detyre, automatikisht do tĂ« fshihet njĂ« etiketĂ« tjetĂ«r ekzistuese, e cila fillon me platform::.
Supozoni se keni etiketa workflow::development, workflow::review dhe workflow::deployed, që shënojnë gjendjen e procesit të punës në ekipin tuaj. Nëse një detyrë tashmë ka një etiketë workflow::development, dhe zhvilluesi dëshiron ta kalojë detyrën në etapën workflow::review, ai thjesht i aplikon një etiketë të re, ndërsa e vjetra (workflow::development) fshihet automatikisht. Ky sjellje tashmë ekziston kur ju lëvizni detyrat midis listave të etiketave në bordin e detyrave, i cili ilustron procesin e punës të ekipit tuaj. Tani, anëtarët e ekipit që nuk punojnë drejtpërdrejt me bordin e detyrave mund të ndryshojnë gjendjen e procesit të punës në vetë detyrat.
Pastrim më i kujdesshëm i regjistrit të kontejnerëve
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Në përdorim të zakonshëm të regjistrit të kontejnerëve me pipeline-e CI, ju dërgoni disa ndryshime të ndara në një etiketa. Për shkak të implementimit të shpërndarjes së Docker, sjellja e paracaktuar është ruajtja e të gjitha ndryshimeve në sistem, por përfundimisht ato zënë shumë hapësirë. Nëse përdorni opsionin -m me registry-garbage-collect, mund të hiqni shpejt të gjitha ndryshimet e mëparshme dhe të çlironi hapësirën e çmuar.
Blerja e minutave të tjera CI Runner
BRONZE, SILVER, GOLD
Përdoruesit me plane të paguara në GitLab.com (Gold, Silver, Bronze) tani mund të blejnë minuta shtesë CI Runner. Më parë duhet të përputheshit me kuotën e parashikuar nga plani. Falë këtij përmirësimi, mund të blini minuta përtej kuotës për të shmangur ndërprerjet e punës për shkak të ndalimit të pipeline-ve.
Tani 1000 minuta kushtojnĂ« 8 dollarĂ«, dhe mund tâi blini sa tĂ« doni. Minutat shtesĂ« do tĂ« fillojnĂ« tĂ« shpenzojnĂ« kur tĂ« keni shpenzuar tĂ« gjithĂ« kuotĂ«n mujore, dhe mbetja e minutave shtesĂ« do tĂ« kalojĂ« pĂ«r nĂ« muajin tjetĂ«r. NĂ« ne duam tĂ« shtojmĂ« kĂ«tĂ« veçori edhe nĂ« planet falas.
Auto DevOps i kompostuar
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Me Auto DevOps, ekipet kalojnë në praktikat moderne të DevOps thuajse pa përpjekje. Duke filluar nga GitLab 11.10, çdo punë në Auto DevOps ofrohet si . Përdoruesit mund të përdorin në GitLab CI, për të përfshirë faza të veçanta të Auto DevOps dhe në të njëjtën kohë të përdorin skedarin e tyre të personalizuar gitlab-ci.yml. Kështu mund të përfshihen vetëm punët e nevojshme dhe të përfitohet nga përmirësimet në upstream.
Menaxhimi automatik i anëtarëve të grupit në GitLab.com me anë të SCIM
SILVER, GOLD
Më parë, duhej të menaxhohej anëtarësia në grupe në GitLab.com manualisht. Tani mund të përdoret SAML SSO dhe të menaxhohet anëtarësia me anë të SCIM, për të krijuar, fshirë dhe përditësuar përdoruesit në GitLab.com.
Kjo është veçanërisht e dobishme për kompani me numër të madh përdoruesish dhe ofrues të centralizuar të identitetit. Tani mund të keni një burim të vetëm të së vërtetës, siç është Azure Active Directory, dhe përdoruesit do të krijohen dhe fshihen automatikisht përmes ofruesit të identitetit, në vend që manualisht.
Hyrja në GitLab.com përmes ofruesit SAML
SILVER, GOLD
Më parë, kur përdorej SAML SSO për grupin, përdoruesi duhej të hynte me kredencialet e GitLab dhe me ofruesin e identitetit. Tani mund të hysh drejtpërdrejt përmes SSO si një përdorues GitLab, i lidhur me grupin e konfiguruar.
Përdoruesit nuk do të kenë nevojë të hyjnë dy herë, kështu që kompanitë do të kenë më lehtë të përdorin SAML SSO për GitLab.com.
Përmirësime të tjera në GitLab 11.10
Schema e epikëve të nën-grupit
ULTIMATE, GOLD
Në versionin e kaluar, ne shtuam epikë nën-grupi (epikë të epikëve), për t'ju bërë më të lehtë menaxhimin e strukturës së shpërndarjes së detyrave. Epikët nën-grupit shfaqen në faqen e epikut prind.
Në këtë version, në faqen e epikut prind shfaqet schema e epikëve nën-grup, kështu që ekipet shohin kronologjinë e epikëve nën-grup dhe mund të menaxhojnë varësitë në kohë.
Ekranet e daljes për kërkesat për bashkim
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Në këtë version, ne prezantojmë ekrane informuese, që shfaqen kur e kaloni kursori mbi lidhjen e kërkesës për bashkim. Më parë ne tregonim vetëm titullin e kërkesës për bashkim, dhe tani dhe statusin e kërkesës për bashkim, statusin e CI-pipeline dhe një URL të shkurtër.
Në versionet e ardhshme planifikojmë të shtojmë më shumë informacione të rëndësishme, siç janë , po ashtu do të prezantojmë ekrane dalëse për .
Filtrimi i kërkesave për bashkim sipas degëve të synuara
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Procese tĂ« Git pĂ«r lĂ«shimin ose dorĂ«zimin e softuerit shpesh lidhen me disa degĂ« afatgjata â pĂ«r tĂ« bĂ«rĂ« korrigjime nĂ« versionet e mĂ«parshme (p.sh., stable-11-9) ose pĂ«r ta kaluar nga kontrolli i cilĂ«sisĂ« nĂ« prodhim (p.sh., integration), por nuk Ă«shtĂ« kaq e lehtĂ« tĂ« gjejmĂ« kĂ«rkesat pĂ«r bashkim pĂ«r kĂ«to degĂ« midis shumĂ« kĂ«rkesave tĂ« hapura pĂ«r bashkim.
Lista e kërkesave për bashkim për projekte dhe grupe tani mund të filtrohet sipas degës qëllim të kërkesës për bashkim, për t'u bërë më e lehtë identifikimi i atyre që nevojiten.
Faleminderit, Hiroyuki Sato ()!
Dërgimi dhe bashkimi pas një pipeline të suksesshëm
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Nëse ne përdorim metodën e zhvillimit Trunk-based, duhet të shmangim degët me jetëgjatësi të gjatë në favor të degëve të vogla me një pronar. Ndryshimet e vogla shpesh dërgohen drejtpërdrejt në degën qëllim, por kështu rrezikojmë të thyjmë ndërtimin.
Në këtë lëshim, GitLab mbështet parametrat e rinj të dërgimit në Git, për të hapur automatikisht kërkesat për bashkim, për të specifikuar degën qëllim dhe për të siguruar bashkimin pas një pipeline të suksesshëm nga linja e komandës gjatë dërgimit në degë.
Integrim i përmirësuar me tabelat e monitorimit të jashtme
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
GitLab mund të kontaktojë me disa servera Prometheus (në nivel ambienti, projekti dhe ), por ekzistenca e disa pikave të fundit mund të komplikohet sistemi ose të mos mbështetet nga tabelat e monitorimit standarde. Në këtë lëshim, ekipi mund të përdorë një API Prometheus, gjë që e thjeshton ndjeshëm integrimin me shërbime të tilla si Grafana.
Klasifikimi i faqeve Wiki sipas datës së krijimit
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Në Wiki të projektit, ekipet mund të ndajnë dokumentacionin dhe informacion të rëndësishëm përveç kodit burim dhe detyrave. Në këtë lëshim, lista e faqeve në Wiki mund të klasifikohet sipas datës së krijimit dhe titullit, për të gjetur shpejt përmbajtjen e sapokrijuar.
Monitorimi i burimeve të kërkuara nga klasteri
ULTIMATE, GOLD
GitLab ndihmon në monitorimin e klasterit Kubernetes për aplikacionet në zhvillim dhe ato operative. Duke filluar nga ky lëshim, ndihmoni në monitorimin e burimeve të kërkuara nga klasteri, si CPU dhe memorie, për të parë vështirësitë potenciale para se ato të bëhen probleme.
Shikimi i metrikave të balancuesit të ngarkesës në tabelën e monitorimit Grafana
CORE, STARTER, PREMIUM, ULTIMATE
ĂshtĂ« shumĂ« e rĂ«ndĂ«sishme tĂ« monitoroni performancĂ«n e instancĂ«s GitLab. MĂ« parĂ«, ne ofruam panelet e monitorimit si parazgjedhje pĂ«rmes njĂ« instance tĂ« integruar tĂ« Grafana. Duke filluar nga kjo nxjerrje, kemi pĂ«rfshirĂ« panelet shtesĂ« pĂ«r tĂ« monitoruar balancuesit e ngarkesĂ«s NGINX.
SAST për Elixir
ULTIMATE, GOLD
Ne vazhdojmë të zgjasim mbështetje për gjuhë dhe thellojmë kontrollet e sigurisë. Në këtë nxjerrje, kemi përfshirë kontrolle sigurie për projektet në dhe projektet e krijuara në .
Kërkesa të shumta në një diagramë
PREMIUM, ULTIMATE, SILVER, GOLD
NĂ« GitLab mund tĂ« krijoni diagrame pĂ«r tĂ« vizualizuar metrikat e mbledhura. Shpesh â pĂ«r shembull, nĂ«se dĂ«shirani tĂ« shihni vlerĂ«n maksimale ose mesatare tĂ« metrikĂ«s â dĂ«shironi tĂ« nxirrni disa vlera nĂ« njĂ« diagramĂ«. Duke filluar nga kjo nxjerrje, keni kĂ«tĂ« mundĂ«si.
Rezultatet DAST në panelin e sigurisë së grupit
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Kemi shtuar rezultatet e testimit të aplikacioneve dinamike të sigurisë (Dynamic Application Security Testing, DAST) në panelin e sigurisë së grupit përveç SAST, skanimit të konteinerëve dhe skanimit të varësive.
Shtimi i metadata në raportin e skanimit të konteinerëve
ULTIMATE, GOLD
NĂ« kĂ«tĂ« nxjerrje, raporti i skanimit tĂ« konteinerĂ«ve pĂ«rmban mĂ« shumĂ« metadata â kemi shtuar komponentin e prekur (feature Clair) nĂ« metadat e ekzistuese: pĂ«rparĂ«sia, identifikuesi (me linkun nĂ« mitre.org) dhe niveli i prekur (pĂ«r shembull, debian:8).
Shtimi i llojit të raportit për metrika në kërkesat për bashkim
PREMIUM, ULTIMATE, SILVER, GOLD
GitLab tashmë ofron disa lloje raportesh që mund të përfshihen drejtpërdrejt në kërkesat për bashkim: nga raportet për dhe në fazën e rishikimit deri në dhe në fazën e mbrojtjes.
Dhe ndonëse këto janë raporte të rëndësishme, edhe informacionet bazike që janë të përshtatshme për skenarë të ndryshëm janë të nevojshme. Në GitLab 11.10, ne ofrojmë raportet e metrikave direkt në kërkesën për bashkim, e cila pret një çift të thjeshtë çelës-vlerë. Kështu, përdoruesit ndjekin ndryshimet me kalimin e kohës, duke përfshirë metrika të përdoruesve dhe ndryshimet e metrikave për një kërkesë të caktuar për bashkim. Përdorimi i memories, testimi i ngarkesave të specializuara dhe statuset e operimit mund të shndërrohen në metrika të thjeshta, të cilat mund të shihen drejtpërdrejt në kërkesat për bashkim së bashku me raportet e tjera të integruara.
Mbështetje për projektet multi-modul Maven për skanimin e varësive
ULTIMATE, GOLD
Në këtë version, projektet multi-modul Maven mbështesin skanimin e varësive GitLab. Më parë, nëse një nënmodul kishte një varësi nga një nënmodul tjetër të së njëjtës nivel, ai nuk mund të zgjidhte shkarkimin nga depoja qendrore Maven. Tani, një projekt multi-modul Maven krijohet me dy module dhe një varësi midis dy moduleve. Varësia midis moduleve të së njëjtës nivel tani është e disponueshme në depojen lokale Maven, për t'u vazhduar ndërtimi.
Përdoruesit mund të ndryshojnë rrugën për klonimin në CI
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Në mënyrë të paracaktuar, GitLab Runner klonon projektin në një rrugë të veçantë unike në $CI_BUILDS_DIR. Por për disa projekte, si Golang, kodi duhet të klonohet në një katalog të veçantë për t'u ndërtuar.
Në GitLab 11.10, ne introduktuam variablën GIT_CLONE_PATH, me të cilën mund të specifikoni një rrugë të veçantë, ku GitLab Runner klonon projektin para se të ekzekutojë detyrën.
Maskimi i thjeshtë i variablave të mbrojtura në logs
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
GitLab ofron disa mënyra dhe e variablave në GitLab CI/CD. Por variablave mund t'u ndodhin rastësisht ose qëllimisht të shfaqen në logët e ndërtimit.
GitLab e merr seriozisht menaxhimin e rreziqeve dhe auditimin dhe vazhdon të shtojë funksione për të përmbushur kërkesat. Në GitLab 11.10 ne prezantuam mundësinë për të maskuar disa lloje variablash në logët e gjurmimit të punëve, duke shtuar një nivel mbrojtjeje nga rastësia e shfaqjes së përmbajtjes së këtyre variablave në logë. Gjithashtu, GitLab tani mjaft variabla të integruar të tokenëve.
Aktivizimi dhe çaktivizimi i Auto DevOps në nivel grupi
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Me Auto DevOps nĂ« projektin GitLab.com, mund tĂ« filloni me lehtĂ«si proceset moderne DevOps â nga ndĂ«rtimi deri te dorĂ«zimi.
Deri në GitLab 11.10, mund të aktivizoni dhe çaktivizoni Auto DevOps për të gjitha projektet në një grup.
Faqja e thjeshtëzuar dhe e përmirësuar për licencat
STARTER, PREMIUM, ULTIMATE
Për ta bërë menaxhimin e çelësave të licencave më të thjeshtë dhe më të lehtë, ne kemi ndryshuar dizajnin e faqes së licencave në panelin e administratorit dhe kemi theksuar elementet më të rëndësishme.
Përmirësimi i selektorit të etiketave për deplojet Kubernetes
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Në panelet e deplojeve shfaqen informacionet mbi të gjitha deplojet Kubernetes.
Në këtë version kemi ndryshuar mënyrën e përputhjes së etiketave me deplojet. Tani janë të disponueshme përputhjet për app.example.com/app dhe app.example.com/env ose app. Kjo do të shmangë konfliktet gjatë filtrimit dhe rrezikun e dislokimeve të gabuara të lidhura me projektin.
Për më tepër, në versionin GitLab 12.0 ne , dhe përputhja do të jetë e mundur vetëm për app.example.com/app dhe app.example.com/env.
Krijimin dinamik të burimeve Kubernetes
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Integrimi i Kubernetes në GitLab lejon përdorimin e funksionit RBAC përmes llogarive të shërbimit dhe hapësirave të dedikuara për çdo projekt GitLab. Duke filluar nga ky lëshim, për efektivitet maksimal këto burime do të krijohen vetëm kur janë të nevojshme për dislokim.
Gjatë dislokimit të Kubernetes, GitLab CI do të krijojë këto burime para dislokimit.
Runner gruporë për klasterët në nivel grupi
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Klasterët në nivel grupi tani mbështesin instalimin e GitLab Runner. Runner-at Kubernetes në nivel grupi shfaqen për projektet e bijë si runner gruporë të etiketuar me etiketa grupi dhe kubernetes.
Numëruesi i thirrjeve për funksionet Knative
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Funksionet e dislokuara me , tani tregojnë numrin e thirrjeve të marra për çdo funksion të veçantë. Për këtë, duhet të instaloni Prometheus në klasterin ku është instaluar Knative.
Kontrolli i parametrave git pastroni për punët GitLab CI/CD
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Sipas parazgjedhjes, GitLab Runner kryen git pastroni në procesin e shkarkimit të kodit gjatë ekzekutimit të një pune në GitLab CI/CD. Duke filluar nga GitLab 11.10, përdoruesit mund të kontrollojnë parametrat e kaluar komandës git pastroni. Kjo është e dobishme për ekipet me runner të dedikuar, si dhe për ekipet që ndërtjnë projekte nga depo të mëdha monorepo. Tani ata mund të menaxhojnë procesin e shkarkimit përpara ekzekutimit të skripteve. Variabla e re GIT_CLEAN_FLAGS për parazgjedhjen ka vlerën -ffdx dhe pranon të gjitha parametrat e mundshëm të komandës [git clean](https://git-scm.com/docs/git-clean).
Autorizimi i jashtëm në Core
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Mjediset e siguruara mund të kërkojnë një burim të jashtëm autorizimi për aksesin në projekt. Ne kemi shtuar mbështetje për një nivel shtesë të kontrolleve të aksesit në dhe kemi marrë shumë kërkesa për të hapur këtë funksionalitet në Core. Ne jemi të lumtur të paraqesim autorizimin e jashtëm dhe një nivel shtesë sigurie për instancat Core, pasi kjo karakteristikë është e nevojshme për pjesëmarrësit e veçantë.
Mundësia për të krijuar projekte në grupe në Core
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Roli Developer mund të krijojë projekte në grupe , dhe tani kjo është e mundur edhe në Core. Krijimi i projekteve është një mundësi kyçe për punë produktive në GitLab, dhe falë përfshirjes së kësaj funksionaliteti në Core, pjesëmarrësit e instancës tani kanë më të lehtë të angazhohen në diçka të re.
GitLab Runner 11.10
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Sot kemi lëshuar GitLab Runner 11.10! GitLab Runner është një projekt me kod të hapur, i cili përdoret për të ekzekutuar detyra CI/CD dhe për të dërguar rezultatet prapa në GitLab.
Ndryshimet më interesante:
- .
- .
- .
- .
- .
Lista e plotë e ndryshimeve mund të gjendet në regjistrin e ndryshimeve të GitLab Runner: .
Korrigjimi i kthimit project_id në API-në e kërkimit të blob në Elasticsearch
STARTER, PREMIUM, ULTIMATE
Kemi korrigjuar një gabim në API-në e kërkimit të blob në Elasticsearch, i cili ktheu gabimisht 0 për project_id. Do të nevojitet , për të marrë vlera të sakta project_id pas instalimit të kësaj versioni GitLab.
Përmirësimet Omnibus
CORE, STARTER, PREMIUM, ULTIMATE
Ne kemi bërë këto përmirësime në Omnibus në GitLab 11.10:
- GitLab 11.10 përfshin , , në lëshimin e fundit të të cilit përfshihet një katalog i ri i integrimit për transfertë të lehta të të dhënave nga Hipchat dhe shumë më tepër. Ky version përfshin , dhe ne rekomandojmë të kaloni në këtë version.
- Ne , dhe tani ka qenë shumë e lehtë të filloni monitorimin e instancës GitLab.
- Ne kemi shtuar mbështetje për fshirjen e imazheve të vjetra të kontejnerëve nga regjistri Docker.
- Ne e kemi përditësuar ca-certs deri më 2019-01-23.
Përmirësime të performancës
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Vazhdojmë të përmirësojmë performancën e GitLab me çdo lëshim për instancat e GitLab të çdo madhësie. Disa përmirësime në GitLab 11.10:
- .
- .
- .
- .
- .
- .
- .
- .
Përmirësimi i diagrameve në GitLab.
CORE, STARTER, PREMIUM, ULTIMATE
Ne kemi bërë këto përmirësime në diagramet e GitLab:
- .
Karakteristikat e vjetra
GitLab Geo do të sigurojë ruajtje të koduar në GitLab 12.0
GitLab Geo kërkon për të zbutur konkurrencën në nyjat dytësore. 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.
Mbështetje për Ubuntu 14.04
GitLab 11.10 do të jetë lëshimi i fundit me .
Canonical njoftoi se do të ndalojë mbështetje standarde për Ubuntu 14.04 nga . Këshillojmë përdoruesit të kalojnë në një version të mbështetur LTS: Ubuntu 16.04 ose Ubuntu 18.04.
Data e heqjes: 22 maj 2019
Kufizimi i numrit maksimal të pipeline-ve që krijohen nga një dërgesë
Më parë, GitLab krijonte pipeline për HEAD çdo degë në dërgesë. Kjo është e dobishme për zhvilluesit që dërgojnë disa ndryshime në të njëjtën kohë (p.sh., në degën e veçorisë dhe në degën develop).
Por kur dërgoni një repository të madh, ku ka shumë degë aktive (p.sh., për zhvendosje, pasqyrim ose ndarje), nuk është e nevojshme të krijoni një pipeline për çdo degë. Duke filluar nga GitLab 11.10 krijojmë në dërgim.
Data e heqjes: 22 maj 2019
Rrugët e vjetra të kodit legacy të GitLab Runner
Deri me GitLab 11.9, GitLab Runner përdor klonimi / thirrja e repository-t. Aktualisht, GitLab Runner do të përdorë metodën e vjetër nëse e reja nuk mbështetet. Shihni më shumë në .
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ë .
Në versionin 11.3, GitLab Runner filloi të mbështesë ; që çoi në konfigurime të reja për . Në , këtu është tabela e ndryshimeve dhe udhëzimet për kalimin në konfigurimin e ri. Më shumë informacion në .
Këto rrugë nuk do të jenë në dispozicion në GitLab 12.0. Si përdorues, nuk keni nevojë të ndryshoni asgjë, vetëm sigurohuni që instanca e GitLab të funksionojë me versionin 11.9+ kur përditësoni 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 dhe .
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 !
Data e heqjes: 22 Qershor 2019.
Në kuadër të përpjekjeve për të mbështetur
Windows Docker executor helper image .
Në GitLab 12.0, GitLab Runner nis me komanda të reja. Kjo ka të bëjë vetëm me përdoruesit që Zhvilluesit mund të fshijnë etiketat Git në GitLab 11.10 .
Data e heqjes: 22 Qershor 2019.
Heqja e mekanizmit të vjetër git clean nga GitLab Runner
Në GitLab Runner 11.10 konfigurojë se si Runner ekzekuton komandën git pastroni. Gjithashtu, strategjia e re e pastrimit eliminon përdorimin e git rikthe dhe vendos komandën git pastroni pas hapit të shkarkimit.
Duke qenë se ky ndryshim në sjellje mund të ndikojë në disa përdorues, kemi përgatitur parametrin FF_USE_LEGACY_GIT_CLEAN_STRATEGY. Nëse vendosni vlerën true, ajo do të rikthejë strategjinë e vjetër të pastrimit. Më shumë rreth përdorimit të parametrave të funksioneve në GitLab Runner mund të gjeni .
Në GitLab Runner 12.0 do të heqim mbështetje për strategjinë e vjetër të pastrimit dhe mundësinë për ta rikthyer atë me parametrin e funksionit. Më shumë informacion në .
Data e heqjes: 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.
Rekordet e ndryshimeve
Shikoni të gjitha këto ndryshime në regjistrin e ndryshimeve:
Instalimi
Nëse po konfiguroni një instalim të ri të GitLab, vizitoni .
Përditësim
Shikoni në .
Planet e abonimit të GitLab
GitLab është në dy variante: dhe .
: lokal ose në platformën cloud të preferuar.
- Core: për ekipe të vogla, projekte personale ose një provë të pakufizuar të GitLab.
- Starter: për ekipe që punojnë në një zyrë mbi disa projekte dhe që kërkojnë mbështetje profesionale.
- Premium: për ekipa të shpërndara që kanë nevojë për funksionalitete të avancuara, disponueshmëri të lartë dhe mbështetje 24/7.
- Ultimate: për ndërmarrje që kërkojnë një strategji dhe zbatim të besueshëm me përmirësim të sigurisë dhe përputhshmërisë.
â GitLab.com: hostohet, menaxhohet dhe administratohet nga GitLab pĂ«r pĂ«r zhvillues tĂ« veçantĂ« dhe ekipe.
- Falë: depo private pa limite dhe numër të pakufizuar të pjesëmarrësve në projekt. Projektet e mbyllura kanë akses në karakteristikat e nivelit Falë, ndërsa kanë akses në karakteristikat e nivelit Gold.
- Bronze: për ekipe që kërkojnë akses në funksionalitete të avancuara të procesit të punës.
- Silver: për ekipe që kanë nevojë për mundësi më të besueshme DevOps, përputhshmëri dhe mbështetje të shpejtë.
- Gold: përshtatet për shumë punë CI/CD. Të gjitha projektet e hapura mund të përdorin falas funksionalitetet Gold pa marrë parasysh planin.
Burimi: habr.com
