GitLab 11.10 mei dashboardpipelines, gearfoege resultatenpipelines, en multi-line suggestjes yn fúzjeoanfragen.
Handige ynformaasje oer de prestaasjes fan pipelines yn ferskate projekten
GitLab bliuwt sichtberens yn 'e DevOps-libbenssyklus te fergrutsjen. Yn dit nûmer op kontrôle paniel tafoege in oersjoch fan pipeline status.
Dit is handich sels as jo studearje de pipeline fan in inkele projekt, mar is foaral nuttich as ferskate projekten, - en dit bart normaal as jo mikrotsjinsten brûke en in pipeline wolle útfiere foar it testen en leverjen fan koade fan ferskate projektrepositories. No kinne jo fuortendaliks de foarstelling sjen pipelines op it kontrôlepaniel, wêr't se ek útfierd wurde.
Running pipelines foar gearfoege resultaten
Yn 'e rin fan' e tiid ferskille de boarne- en doeltûken, en in situaasje kin ûntstean wêr't se apart omgean, mar net gearwurkje. No kinsto pipelines útfiere foar gearfoegde resultaten foardat jo fusearje. Op dizze manier sille jo fluch flaters fernimme dy't allinich ferskine as wizigingen faak wurde ferpleatst tusken tûken, wat betsjut dat jo pipelinefouten folle rapper korrigearje en de GitLab Runner.
Fierder optimalisearje gearwurking
GitLab 11.10 foeget noch mear funksjes ta foar naadleaze gearwurking en ferienfâldige workflows. YN foarige útjefte wy yntrodusearre suggestjes foar fúzje fersiken, dêr't in resinsint koe foarstelle in feroaring oan ien rigel yn in reaksje nei in fúzje fersyk, en it koe wurde fuortendaliks ynsette direkt út de opmerking thread. Us brûkers fûnen it leuk en fregen dizze funksje út te wreidzjen. No kinne jo biede feroarings foar meardere rigels, oanjout hokker rigels te ferwiderjen en hokker ta te foegjen.
De meast weardefolle meiwurker fan dizze moanneMVP) - Takuya Noguchi
De meast weardefolle meiwurker fan dizze moanne is Takuya Noguchi (Takuya Noguchi). Takuya die in goede baan foar de gloarje fan GitLab: reparearre bugs, foltôge tekoarten yn 'e efterkant en frontend en ferbettere de brûkersynterface. Dankewol!
Haadfunksjes fan GitLab 11.10
Pipelines op de kontrôle paniel
PREMIUM, ULTIMATE, SILVER, GOUD
It dashboard yn GitLab toant ynformaasje oer projekten oer jo heule GitLab-eksimplaar. Jo foegje yndividuele projekten ien foar ien ta en kinne kieze hokker projekt jo ynteresseart.
Yn dizze release hawwe wy ynformaasje tafoege oer pipelinestatussen oan it dashboard. No sjogge ûntwikkelders de funksjonaliteit fan pipelines yn alle nedige projekten - yn ien ynterface.
Pipelines foar gearfoege resultaten
PREMIUM, ULTIMATE, SILVER, GOUD
It is gewoanlik dat de boarnetûke yn 'e rin fan' e tiid ôfwykt fan 'e doeltûke, útsein as jo konstant feroaringen tusken har triuwe. As gefolch binne de boarne- en doeltakkepipelines "grien" en binne d'r gjin fúzjekonflikten, mar de fúzje mislearret troch ynkompatibele feroarings.
As de pipeline foar fúzjefersyk automatysk in nije keppeling makket dy't it kombinearre resultaat fan 'e gearfoeging fan' e boarne- en doeltûken befettet, kinne wy de pipeline op dy keppeling útfiere en soargje dat it algemiene resultaat wurket.
As jo pipelines foar gearfoeging brûke (yn elke kapasiteit) en privee GitLab runners ferzje 11.8 of âlder brûke, moatte jo se bywurkje om dit probleem te foarkommen gitlab-ee#11122. Dit hat gjin ynfloed op brûkers fan iepenbiere GitLab-runners.
As jo gearwurkje oan fúzjeoanfragen, fine jo faak problemen en stelle oplossingen foar. Sûnt GitLab 11.6 stypje wy foarstel foar feroarings foar ien line.
Yn ferzje 11.10 kinne diff-kommentaren foar gearfoeging feroarings foarstelle oan meardere rigels, en dan kin elkenien mei skriuwrjochten foar de orizjinele tûke se mei ien klik akseptearje. Mei tank oan de nije funksje kinne jo kopiearje-plakke foarkomme, lykas yn eardere ferzjes.
Fluchtoetsen yn ien gebiet
PREMIUM, ULTIMATE, SILVER, GOUD
Mei labels yn deselde omfang, kinne teams ûnderling eksklusyf labels tapasse (yn deselde omfang) op in probleem, fúzjefersyk, of epysk yn senario's mei oanpaste fjilden of oanpaste workflow-staten. Se wurde konfigureare mei in spesjale kolonsyntaksis yn 'e labeltitel.
Litte wy sizze dat jo in oanpast fjild nedich binne yn taken om it bestjoeringssysteem te folgjen fan it platfoarm dat jo funksjes rjochtsje. Elke taak moat relatearje oan mar ien platfoarm. Jo kinne fluchtoetsen meitsje platform::iOS, platform::Android, platform::Linux en oaren as nedich. As jo sa'n fluchtoets tapasse op in taak, sil dizze automatysk in oare besteande fluchtoets fuortsmite dy't begjint mei platform::.
Litte wy sizze dat jo fluchtoetsen hawwe workflow::development, workflow::review и workflow::deployed, oanjout fan de steat fan de workflow fan jo team. As de taak al in fluchtoets hat workflow::development, en de ûntwikkelder wol de taak nei it poadium ferpleatse workflow::review, it past gewoan de nije fluchtoets en de âlde (workflow::development) wurdt automatysk wiske. Dit gedrach bestiet al as jo taken ferpleatse tusken listen mei fluchtoetsen op it taakboerd dat de workflow fan jo team fertsjintwurdiget. No kinne teamleden dy't net direkt mei it taakbestjoer wurkje, de workflowstatus yn 'e taken sels feroarje.
Mear yngeande skjinmeitsjen fan it kontenerregister
As jo typysk in kontenerregister brûke mei CI-pipelines, drukke jo meardere aparte wizigingen nei ien tag. Troch de ymplemintaasje fan Docker's distribúsje is it standertgedrach om alle wizigingen yn it systeem op te slaan, mar se nimme úteinlik in soad ûnthâld yn. As jo de parameter brûke -m с registry-garbage-collect, kinne jo alle eardere wizigingen fluch wiskje en kostbere romte frijmeitsje.
Oankeapje ekstra CI Runner minuten
BRONS, SILVER, GOUD
Brûkers mei betelle GitLab.com-plannen (Goud, Sulver, Brûns) kinne no ekstra CI Runner-minuten keapje. Earder wie it nedich om te foldwaan oan it yn it plan foarsjoen kwotum. Mei dizze ferbettering kinne jo foarôf keapje oer-kwota-minuten om ûnderbrekkingen te foarkommen fanwegen pipeline-shutdowns.
No kostje 1000 minuten $ 8, en jo kinne safolle keapje as jo wolle. Oanfoljende minuten sille begjinne te brûken as jo jo hiele moanlikse kwota hawwe bestege, en de rest fan 'e ekstra minuten sil oergean nei de folgjende moanne. YN takomstige release wy wolle dizze funksje ek tafoegje oan fergese plannen.
Mei Auto DevOps geane teams hast sûnder muoite oer nei moderne DevOps-praktiken. Begjin mei GitLab 11.10 wurdt elke baan yn Auto DevOps levere as ûnôfhinklike sjabloan. Brûkers kinne gebrûk meitsje функцию includes yn GitLab CI om yndividuele stadia fan Auto DevOps yn te skeakeljen en tagelyk jo oanpaste bestân te brûken gitlab-ci.yml. Op dizze manier kinne jo allinich de banen ynskeakelje dy't jo nedich binne en profitearje fan upstream updates.
Behear groepleden automatysk op GitLab.com mei SCIM
SILVER, GOUD
Earder moasten jo groepslidmaatskip manuell beheare op GitLab.com. Jo kinne no SAML SSO brûke en lidmaatskip beheare mei SCIM om brûkers op GitLab.com te meitsjen, te wiskjen en te aktualisearjen.
Dit is foaral nuttich foar bedriuwen mei grutte oantallen brûkers en sintralisearre identiteitsproviders. No kinne jo in inkele boarne fan wierheid hawwe, lykas Azure Active Directory, en brûkers sille automatysk oanmakke en wiske wurde fia de identiteitsprovider ynstee fan mei de hân.
Oanmelde by GitLab.com fia SAML Provider
SILVER, GOUD
Earder, by it brûken fan SAML SSO foar groepen, wie de brûker ferplichte om oan te melden mei GitLab-bewizen en in identiteitsprovider. Jo kinne no direkt fia SSO ynlogge as in GitLab-brûker ferbûn mei in konfigureare groep.
Brûkers hoege net twa kear oan te melden, wat it makliker makket foar bedriuwen om SAML SSO te brûken foar GitLab.com.
Oare ferbetterings yn GitLab 11.10
Bern epysk skema
ULTIMATE, GOUD
Yn 'e foarige release hawwe wy berne-eposen (eposen fan eposen) tafoege om jo te helpen jo struktuer fan wurkferdieling te behearjen. Berneposen ferskine op 'e side fan' e âlderepos.
Yn dizze útjefte toant de âldere epyske side in skets fan berne-epiken, sadat teams de tiidline fan berne-epos sjen kinne en timing-ôfhinklikens kinne beheare.
Yn dizze release yntrodusearje wy ynformative skermen dy't opdûke as jo hoverje oer in fúzjefersykkeppeling. Earder lieten wy allinich de titel fan 'e fúzjefersyk sjen, mar no litte wy ek de status fan' e fúzjefersyk, CI-pipelinestatus en koarte URL sjen.
Git-workflows foar it frijjaan of ferstjoeren fan software befetsje faak meardere tûken op lange termyn - om reparaasjes te meitsjen foar eardere ferzjes (bgl. stable-11-9) of ferpleatse fan kwaliteitstesten nei produksje (bgl. integration), mar it is net maklik om fúzjeoanfragen foar dizze tûken te finen ûnder de protte iepen fúzjeoanfragen.
De list mei fúzjeoanfragen foar projekten en groepen kin no wurde filtere troch de doeltûke fan it fúzjefersyk om it makliker te meitsjen om dejinge te finen dy't jo nedich binne.
As wy gebrûk meitsje fan de Trunk-basearre ûntwikkeling metoade, wy moatte mije lange libbene tûken yn it foardiel fan lytse, tydlike tûken mei ien eigener. Lytse wizigingen wurde faak direkt nei de doeltûke skood, mar d'r is it risiko dat de bou brekke.
Mei dizze útjefte stipet GitLab nije Git-push-opsjes om automatysk fúzjeoanfragen te iepenjen, de doeltûke yn te stellen en in fúzje ôf te twingen op in suksesfolle pipeline fan 'e kommandorigel op it momint fan push nei de branch.
GitLab kin tagong krije ta meardere Prometheus-tsjinners (omjouwing, projekt, en groepen (ferwachte)), mar it hawwen fan meardere einpunten kin kompleksiteit tafoegje of wurde miskien net stipe troch standert dashboards. Mei dizze release kinne teams in inkele Prometheus API brûke, wêrtroch yntegraasje mei tsjinsten lykas Grafana folle makliker makket.
Yn in projekt Wiki kinne teams dokumintaasje en oare wichtige ynformaasje diele tegearre mei boarnekoade en taken. Mei dizze útjefte kinne jo de list mei Wiki-siden sortearje op oanmaakdatum en titel om fluch koartlyn oanmakke ynhâld te finen.
Tafersjochmiddels oanfrege troch it kluster
ULTIMATE, GOUD
GitLab helpt jo jo Kubernetes-kluster te kontrolearjen foar ûntwikkeling- en produksjeapplikaasjes. Begjin mei dizze release, kontrolearje CPU- en ûnthâldfersiken fan jo kluster om potinsjele problemen te spotten foardat se problemen wurde.
Besjoch Load Balancer Metrics yn it Grafana Dashboard
CORE, STARTER, PREMIUM, ULTIMATE
It is heul wichtich om de sûnens fan jo GitLab-eksimplaar te kontrolearjen. Earder levere wy standert dashboards fia in ynbêde Grafana-eksimplaar. Begjin mei dizze release hawwe wy ekstra dashboards opnommen foar it kontrolearjen fan NGINX load balancers.
SAST foar Elixir
ULTIMATE, GOUD
Wy bliuwe taalstipe útwreidzje en feiligenskontrôles ferdjipje. Yn dizze release hawwe wy befeiligingskontrôles ynskeakele foar projekten op Elixir en projekten makke op Phoenix platfoarm.
Meardere fragen yn ien diagram
PREMIUM, ULTIMATE, SILVER, GOUD
Yn GitLab kinne jo diagrammen oanmeitsje om de metriken te visualisearjen dy't jo sammelje. Faak, bygelyks, as jo moatte sjen nei de maksimale of gemiddelde wearde fan in metrysk, jo wolle werjaan ferskate wearden op ien diagram. Begjinnend mei dizze release, hawwe jo dizze kâns.
Wy hawwe resultaten fan Dynamic Application Security Testing (DAST) tafoege oan it befeiligingsdashboard fan it team neist SAST, kontenerscannen en ôfhinklikensscannen.
Metadata tafoegje oan in kontenerscanrapport
ULTIMATE, GOUD
Yn dizze release befettet it Container Scan Report mear metadata - wy hawwe tafoege beynfloede komponint (in Clair-funksje) yn besteande metadata: prioriteit, identifier (mei ferwizing nei mitre.org) en beynfloede nivo (bgl. debian:8).
In metrikrapporttype tafoegje om fersiken te fusearjen
PREMIUM, ULTIMATE, SILVER, GOUD
GitLab leveret al ferskate soarten rapporten dy't direkt kinne wurde opnommen yn fúzjeoanfragen: fan rapporten oant koade kwaliteit и ienheid testen by de ferifikaasje poadium oant SAST и DAST op it poadium fan beskerming.
Hoewol dit wichtige rapporten binne, is basisynformaasje dy't past by ferskate senario's ek nedich. Yn GitLab 11.10 leverje wy metriken dy't direkt rapportearje yn it fúzjefersyk, dat in ienfâldich kaai-wearde-pear ferwachtet. Op dizze manier folgje brûkers feroaringen yn 'e rin fan' e tiid, ynklusyf oanpaste metriken, en feroaringen yn metriken foar in spesifyk fúzjefersyk. Unthâldgebrûk, spesjalisearre testen fan wurkdruk, en sûnensstatussen kinne wurde omboud ta ienfâldige metriken dy't direkt kinne wurde besjoen yn fúzjeoanfragen tegearre mei oare ynboude rapporten.
Stipe foar multi-module Maven-projekten foar ôfhinklikensskennen
ULTIMATE, GOUD
Mei dizze útjefte stypje multi-module Maven-projekten GitLab-ôfhinklikensscannen. Earder, as in submodule in ôfhinklikheid hie fan in oare submodule fan itselde nivo, koe it net laden fan it sintrale Maven-repository tastean. No is in multi-module Maven-projekt makke mei twa modules en in ôfhinklikens tusken de twa modules. Ofhinklikens tusken sibling modules binne no beskikber yn de lokale Maven repository sadat de bou kin trochgean.
Standert kloan GitLab Runner it projekt nei in unyk subpaad yn $CI_BUILDS_DIR. Mar foar guon projekten, lykas Golang, moat de koade yn in spesifike map klone wurde om it te bouwen.
Yn GitLab 11.10 hawwe wy de fariabele yntrodusearre GIT_CLONE_PATH, wêrtroch jo in spesifyk paad kinne opjaan wêr't GitLab Runner it projekt klonet foardat de taak útfiert.
Ienfâldige maskering fan beskerme fariabelen yn logs
GitLab biedt ferskate manieren om te beskermjen и it gebiet beheine fariabelen yn GitLab CI / CD. Mar fariabelen kinne noch einigje yn boulogs, mei opsetsin of tafallich.
GitLab nimt risikobehear en kontrôle serieus en giet troch mei it tafoegjen fan funksjes foar neilibjen. Yn GitLab 11.10 hawwe wy de mooglikheid yntrodusearre om beskate soarten fariabelen te maskearjen yn job trace logs, en tafoegjen fan in nivo fan beskerming tsjin de ynhâld fan dizze fariabelen dy't per ongelok opnommen wurde yn 'e logs. En no GitLab automatysk maskers in protte ynboude token fariabelen.
Auto DevOps ynskeakelje of útskeakelje op teamnivo
Mei Auto DevOps op in GitLab.com-projekt kinne jo moderne DevOps-workflows oannimme fan bouwen oant levering sûnder it gedoe.
Begjinnend mei GitLab 11.10 kinne jo Auto DevOps ynskeakelje of útskeakelje foar alle projekten yn deselde groep.
Ienfâldige en ferbettere lisinsje side
STARTER, PREMIUM, ULTIMATE
Om it behearen fan lisinsjekaaien handiger en ienfâldiger te meitsjen, hawwe wy de lisinsjeside yn it adminpaniel opnij ûntwurpen en de wichtichste eleminten markearre.
Update de fluchtoetsselektor foar Kubernetes-ynset
Ynsetpanielen jouwe ynformaasje oer alle Kubernetes-ynset.
Yn dizze release hawwe wy de manier feroare wêrop wy fluchtoetsen yn kaart bringe nei ynset. Wedstriden binne no beskikber troch app.example.com/app и app.example.com/env of app. Dit sil filterjen fan konflikten en it risiko fan ferkearde ynset ferbûn mei it projekt foarkomme.
Kubernetes-yntegraasje mei GitLab lit jo de RBAC-funksje brûke mei in tsjinstkonto en in tawijd nammeromte foar elk GitLab-projekt. Begjinnend mei dizze release, foar maksimale effisjinsje, sille dizze boarnen allinich wurde makke as it nedich is foar ynset.
By it ynsetten fan Kubernetes sil GitLab CI dizze boarnen meitsje foar ynset.
Groepsnivo-klusters stypje no GitLab Runner-ynstallaasje. Kubernetes-runners op groepnivo ferskine foar bernprojekten as groeprinners markearre cluster и kubernetes.
Funksjes ynset mei GitLab Serverless, toant no it oantal oanroppen ûntfongen foar in bepaalde funksje. Om dit te dwaan, moatte jo Prometheus ynstallearje op it kluster wêr't Knative ynstalleare is.
Parameter kontrôle git clean foar GitLab CI / CD banen
Standert rint GitLab Runner git clean tidens it proses fan it opladen fan koade by it útfieren fan in baan yn GitLab CI / CD. Fanôf GitLab 11.10 kinne brûkers de parameters kontrolearje dy't trochjûn binne oan in team git clean. Dit is nuttich foar teams mei tawijde runners, lykas ek foar teams dy't projekten sammelje fan grutte monorepositories. No kinne se it ûntlaadproses kontrolearje foardat se skripts útfiere. Nije fariabele GIT_CLEAN_FLAGS standert wearde is -ffdx en akseptearret alle mooglike kommando parameters [git clean](https://git-scm.com/docs/git-clean).
Feilige omjouwings kinne in ekstra eksterne autorisaasjeboarne fereaskje om tagong te krijen ta it projekt. Wy hawwe stipe tafoege foar in ekstra nivo fan tagongskontrôle yn 10.6 en krige in protte oanfragen om dizze funksjonaliteit yn Core te iepenjen. Wy binne bliid om eksterne autorisaasje en in ekstra laach fan feiligens yn te fieren foar Core-eksimplaren, om't dizze funksje nedich is troch yndividuele dielnimmers.
Mooglikheid om projekten te meitsjen yn groepen yn Core
De rol fan ûntwikkelders kin projekten oanmeitsje yn groepen sûnt ferzje 10.5, en no is dit mooglik yn Core. Projekten oanmeitsje is in wichtige funksje foar produktiviteit yn GitLab, en troch dizze funksje yn Core op te nimmen, is it no makliker foar bygelyks leden om wat nijs te dwaan.
Hjoed hawwe wy GitLab Runner 11.10 frijlitten! GitLab Runner is in iepen boarne-projekt dat wurdt brûkt om CI / CD-taken út te fieren en de resultaten werom te drukken nei GitLab.
De folsleine list mei feroarings is te finen yn it GitLab Runner changelog: CHANGELOG.
Korreksje fan de werom project_id yn 'e blob sykje API yn Elasticsearch
STARTER, PREMIUM, ULTIMATE
Wy repareare in brek yn 'e Elasticsearch blob-sykjen API dy't ferkeard 0 foar weromkaam project_id. It sil nedich wêze reindex Elasticsearchom de juste wearden te krijen project_id nei it ynstallearjen fan dizze ferzje fan GitLab.
Omnibus ferbetterings
CORE, STARTER, PREMIUM, ULTIMATE
Wy hawwe de folgjende ferbetterings makke oan Omnibus yn GitLab 11.10:
GitLab Geo sil hashed opslach bringe nei GitLab 12.0
GitLab Geo is fereaske hashed opslach om konkurrinsje op sekundêre knopen te beheinen. Dit waard opmurken yn gitlab-ce#40970.
Yn GitLab 11.5 wy hawwe dizze eask tafoege oan 'e Geo dokumintaasje: gitlab-ee#8053.
Yn GitLab 11.6sudo gitlab-rake gitlab:geo:check kontrolearret as hashed opslach is ynskeakele en as alle projekten binne migrearre. Cm. gitlab-ee#8289. As jo Geo brûke, fier dan dizze kontrôle út en migrearje sa gau mooglik.
Yn GitLab 11.8 permanint útskeakele warskôging gitlab-ee!8433 sil werjûn wurde op 'e side Admin Area > geo > Nodenas de boppesteande kontrôles binne net tastien.
Yn GitLab 12.0 Geo sil gebrûk meitsje fan hashed opslach easken. Cm. gitlab-ee#8690.
Canonical kundige it ein oan fan standertstipe foar Ubuntu 14.04 April 2019. Wy advisearje brûkers om te upgrade nei in stipe LTS-ferzje: Ubuntu 16.04 of Ubuntu 18.04.
Wiskje datum: 22-hefst 2019
Beheining fan it maksimum oantal pipelines makke troch ien yntsjinjen
Earder makke GitLab pipelines foar HEAD elke tûke yn 'e shipment. Dit is handich foar ûntwikkelders dy't meardere wizigingen tagelyk triuwe (bygelyks nei in funksje-tûke en in develop).
Mar as jo in grut repository triuwe wêr't d'r in protte aktive tûken binne (bygelyks om te ferpleatsen, spegelje of foarke), hoege jo gjin pipeline foar elke tûke te meitsjen. Begjinnend mei GitLab 11.10 meitsje wy maksimum 4 pipelines by it ferstjoeren.
Wiskje datum: 22-hefst 2019
GitLab Runner legacy koade paden
Sûnt Gitlab 11.9 GitLab Runner brûkt nije metoade it repository klonearje / neame. Op it stuit sil GitLab Runner de âlde metoade brûke as de nije net stipe wurdt. Sjoch mear yn dizze taak.
Yn GitLab 11.0 hawwe wy de konfiguraasjewerjefte fan metriken foar GitLab Runner feroare. metrics_server sil fuortsmiten wurde yn it foardiel fan listen_address yn GitLab 12.0. Sjoch mear yn dizze taak.
Dizze paden sille net beskikber wêze yn GitLab 12.0. As brûker hoege jo neat te feroarjen, soargje derfoar dat jo GitLab-eksimplaar ferzje 11.9+ hat as jo opwurdearje nei GitLab Runner 12.0.
Wiskje datum: 22 juny 2019
Ferâldere opsje foar yngongspuntfunksje foar GitLab Runner
Yn GitLab 12.0 sille wy oerskeakelje nei it juste gedrach as soe de funksje-ynstelling útskeakele binne. Sjoch mear yn dizze taak.
Wiskje datum: 22 juny 2019
Ferâldere stipe foar in Linux-distribúsje dy't EOL hat berikt foar GitLab Runner
Guon Linux-distribúsjes wêrop jo GitLab Runner kinne ynstallearje hawwe har doel tsjinne.
Yn GitLab 12.0 sil GitLab Runner gjin pakketten mear ferspriede nei dizze Linux-distribúsjes. In folsleine list mei distribúsjes dy't net mear wurde stipe is te finen yn ús dokumintaasje. Mei tank oan Javier Ardo (Javier Jardon) mei syn bydrage!
Wiskje datum: 22 juny 2019
It fuortsmiten fan âlde GitLab Runner Helper kommando's
GitLab 12.0 lanseart GitLab Runner mei nije kommando's. Dit jildt allinnich foar brûkers dy't oerskriuwe helper ôfbylding. Sjoch mear yn dizze taak.
Wiskje datum: 22 juny 2019
It legacy git skjinne meganisme fuortsmite fan GitLab Runner
Yn GitLab Runner 11.10 wy jouwe de kâns ynstelle hoe't Runner in kommando útfiert git clean. Derneist ferwideret de nije skjinmakstrategy it gebrûk git reset en set it kommando git clean nei de uploadstap.
Sûnt dizze gedrachsferoaring kin ynfloed hawwe op guon brûkers, hawwe wy in ynstelling taret FF_USE_LEGACY_GIT_CLEAN_STRATEGY. As jo ynstelle de wearde true, it sil de legacy-skjinstrategy weromsette. Mear oer it brûken fan funksjeparameters yn GitLab Runner kin fûn wurde yn dokumintaasje.
Yn GitLab Runner 12.0 sille wy stipe fuortsmite foar de legacy-skjinstrategy en de mooglikheid om it te herstellen mei in funksjeparameter. Sjoch mear details yn dizze taak.
Wiskje datum: 22 juny 2019
Systeemynfo seksje yn it adminpaniel
GitLab presintearret ynformaasje oer jo GitLab-eksimplaar yn admin/system_info, mar dizze ynformaasje kin net krekt wêze.
Frij: Unbeheinde partikuliere repositories en ûnbeheind oantal projektmeiwurkers. Sluten projekten hawwe tagong ta nivo funksjes Frijat iepen projekten hawwe tagong ta nivo funksjes goud.
brûnzen: Foar teams dy't tagong hawwe ta avansearre workflowfunksjes.
Sulver: Foar teams dy't mear robúste DevOps-mooglikheden, neilibjen en rappere stipe nedich binne.
goud: Geskikt foar in protte CI / CD banen. Alle iepen projekten kinne Gold-funksjes fergees brûke, nettsjinsteande plan.