Rapide detekti likitajn sekretojn
Ŝajnus malgranda eraro hazarde transdoni akreditaĵojn al komuna deponejo. Tamen, la konsekvencoj povas esti gravaj. Post kiam la atakanto ricevas vian pasvorton aŭ API-ŝlosilon, li transprenos vian konton, ŝlosos vin kaj uzos vian monon fraŭde. Krome, domenefiko eblas: aliro al unu konto malfermas aliron al aliaj. La intereso estas alta, do estas ege grave ekscii pri likitaj sekretoj kiel eble plej baldaŭ.
En ĉi tiu eldono ni enkondukas la opcion kiel parto de nia SAST-funkcieco. Ĉiu komit estas skanita en la CI/KD-laboro por sekretoj. Estas sekreto - kaj la programisto ricevas averton en la kunfanda peto. Ĝi revokas likitajn akreditaĵojn surloke kaj kreas novajn.
Certigante taŭgan ŝanĝadministradon
Ĉar ĝi kreskas kaj iĝas pli kompleksa, konservi konsistencon inter malsamaj partoj de organizo fariĝas pli malfacila. Ju pli da uzantoj de la aplikaĵo kaj ju pli alta estas la enspezo, des pli gravaj estas la sekvoj de kunfandado de malĝusta aŭ nesekura kodo. Por multaj organizoj, certigi taŭgan revizian procezon antaŭ kunfandado de kodo estas strikta postulo ĉar la riskoj estas tre altaj.
GitLab 11.9 donas al vi pli da kontrolo kaj pli efika strukturo, danke al . Antaŭe, por akiri permeson, vi devis nur identigi individuon aŭ grupon (ĉiu membro povis doni permeson). Vi nun povas aldoni plurajn regulojn tiel ke kunfanda peto postulas permeson de specifaj individuoj aŭ eĉ pluraj membroj de specifa grupo. Krome, la funkcio de Code Owners estas integrita al la permesaj reguloj, kio faciligas identigi la personon, kiu donis la permesilon.
Ĉi tio permesas al organizoj efektivigi kompleksajn rezoluciajn procezojn konservante la simplecon de ununura GitLab-apo kie problemoj, kodo, duktoj kaj monitoraj datumoj estas videblaj kaj alireblaj por fari decidojn kaj akceli la rezolucian procezon.
ChatOps nun estas malferma fonto
GitLab ChatOps estas potenca aŭtomatiga ilo, kiu ebligas al vi ruli ajnan CI/KD-laboron kaj pridemandi ĝian staton rekte en babilaj programoj kiel Slack kaj Mattermost. , ChatOps estis parto de la GitLab Ultimate abono. Bazita и , ni foje movas trajtojn malsupren nivelon kaj neniam supren.
En la kazo de ChatOps, ni rimarkis, ke ĉi tiu funkcio povas esti utila al ĉiuj, kaj ke komunuma partopreno povas profitigi la funkcion mem.
En GitLab 11.9 ni , kaj tiel ĝi nun estas libere havebla por uzo en mem-administrata GitLab Core kaj sur GitLab.com kaj malfermita al la komunumo.
Kaj multe pli!
Estas tiom da bonegaj funkcioj disponeblaj en ĉi tiu eldono, ekz. , и , - ke ni ne povas atendi rakonti al vi pri ili!
Plej valora dungito () ĉi-monate estas rekonita de Marcel Amirault ()
Marcel konstante helpis nin plibonigi GitLab-dokumentadon. Li plibonigi la kvaliton kaj uzeblecon de niaj dokumentoj. Domo arigato [multan dankon (japane) - ĉ. trad.] Marcel, ni kore dankas ĝin!
Ĉefaj funkcioj aldonitaj en GitLab 11.9-eldono
Malkovrante sekretojn kaj akreditaĵojn en deponejo
(FININA, ORO)
Programistoj foje pretervole likas sekretojn kaj akreditaĵojn al foraj deponejoj. Se aliaj homoj havas aliron al ĉi tiu fonto, aŭ se la projekto estas publika, tiam sentemaj informoj estas elmontritaj kaj povas esti uzataj de atakantoj por aliri rimedojn kiel deplojmedioj.
GitLab 11.9 havas novan teston - "Sekreta Detekto". Ĝi skanas la enhavon de la deponejo serĉante API-ŝlosilojn kaj aliajn informojn, kiuj ne devus esti tie. GitLab montras rezultojn en la SAST-raporto en la fenestraĵo de Merge Demando, duktoraportoj kaj sekurecaj paneloj.
Se vi jam ebligis SAST por via aplikaĵo, tiam vi ne bezonas fari ion ajn, nur profitu ĉi tiun novan funkcion. Ĝi ankaŭ estas inkluzivita en la agordo defaŭlte.
Reguloj por solvi kunfandpetojn
(PREMIUMO, ULTIMA, ARGENTO, ORO)
Kodrevizio estas esenca elemento de ĉiu sukcesa projekto, sed ne ĉiam estas klare, kiu devus revizii ŝanĝojn. Ofte estas dezirinde havi recenzistojn de malsamaj teamoj: la evolua teamo, la uzant-sperta teamo, la produkta teamo.
Permesaj reguloj permesas vin plibonigi la procezon de interago inter homoj implikitaj en koda revizio difinante la rondon de rajtigitaj aprobantoj kaj la minimuman nombron da permesoj. Rezoluciaj reguloj estas montrataj en la fenestraĵo pri kunfanda peto, por ke vi rapide asignu la sekvan recenziston.
En GitLab 11.8, permesreguloj estis malŝaltitaj defaŭlte. Komencante kun GitLab 11.9, ili disponeblas defaŭlte. En GitLab 11.3 ni enkondukis la opcion identigi teamanojn respondecajn pri individuaj kodoj ene de projekto. La funkcio de Code Owners estas integrita en permesregulojn, tiel ke vi ĉiam povas rapide trovi la ĝustajn homojn por revizii ŝanĝojn.
Movante ChatOps al Kerno
(KENA, STARTER, PREMIUM, ULTIMATE, FREE, BRONZO, ARGENTO, ORO)
Origine enkondukita en GitLab Ultimate 10.6, ChatOps moviĝis al GitLab Core. GitLab ChatOps ofertas la kapablon ruli GitLab CI-laborpostenojn per Slack uzante la funkcion .
Ni estas malferma fonto ĉi tiu funkcio laŭ nia . Uzante ĝin pli ofte, la komunumo kontribuos pli.
Revizio de funkcio-parametroj
(PREMIUMO, ULTIMA, ARGENTO, ORO)
Operacioj kiel aldoni, forigi aŭ ŝanĝi funkciojn parametrojn nun estas registritaj en la auditoria protokolo de GitLab, do vi povas vidi kio estis ŝanĝita kaj kiam. Okazis akcidento kaj vi bezonas vidi, kio ŝanĝiĝis lastatempe? Aŭ ĉu vi nur bezonas kontroli kiel la funkcio-parametroj estis ŝanĝitaj kadre de revizio? Nun ĉi tio estas tre facila por fari.
Pritraktado de Merge Demand Vulnerabilities
(FININA, ORO)
Por rapide solvi kodajn vundeblecojn, la procezo devas esti simpla. Gravas simpligi sekurecajn diakilojn, permesante al programistoj koncentriĝi pri siaj respondecoj. En GitLab 11.7 ni , sed ĝi devis esti elŝutita, aplikita loke, kaj poste puŝita al la fora deponejo.
En GitLab 11.9 ĉi tiu procezo estas aŭtomatigita. Ripari vundeblecojn sen forlasi la interfacon de GitLab. Kunfanda peto estas kreita rekte de la vundebleco-informfenestro, kaj ĉi tiu nova branĉo jam enhavos la solvon. Post kontroli ĉu la problemo estas solvita, aldonu la solvon al la kontraŭflua branĉo se la dukto estas en ordo.
Montrante ujajn skanajn rezultojn en la grupa sekureca panelo
(FININA, ORO)
La sekureca panelo de la teamo permesas al teamoj koncentriĝi pri la plej kritikaj aferoj por ilia laboro, provizante klaran, detalan superrigardon de ĉiuj eblaj vundeblecoj, kiuj povus influi aplikojn. Tial gravas, ke la panelo enhavas ĉiujn necesajn informojn en unu loko kaj ebligas al uzantoj enprofundigi la datumojn antaŭ solvi vundeblecojn.
En GitLab 11.9, uj-skanadrezultoj estis aldonitaj al la panelo, aldone al la ekzistantaj SAST kaj dependeca skanado-rezultoj. Nun la tuta superrigardo estas en unu loko, sendepende de la fonto de la problemo.
CI/KD-ŝablonoj por sekurecaj laborpostenoj
(FININA, ORO)
La sekurecaj funkcioj de GitLab evoluas tre rapide kaj postulas konstantajn ĝisdatigojn por konservi vian kodon efika kaj sekura. Ŝanĝi la difinon de laboro estas malfacila kiam vi administras plurajn projektojn. Kaj ni ankaŭ komprenas, ke neniu volas riski uzi la lastan version de GitLab sen esti certa, ke ĝi estas plene kongrua kun la nuna kazo de GitLab.
Tial ni enkondukis en GitLab 11.7 novan mekanismon por difini laborpostenojn uzante .
Komencante per GitLab 11.9 ni proponos enkonstruitajn ŝablonojn por ĉiuj sekurecaj laboroj: ekzemple, sast и dependency_scanning, - kongrua kun la responda versio de GitLab.
Enmetu ilin rekte en vian agordon, kaj ili estos ĝisdatigitaj kun la sistemo kiam ajn vi ĝisdatigas al nova versio de GitLab. La duktokonfiguracioj ne ŝanĝiĝas.
La nova maniero difini sekurecajn laborpostenojn estas oficiala kaj ne subtenas iujn ajn aliajn antaŭajn labordifinojn aŭ kodpecetojn. Vi devas ĝisdatigi vian difinon kiel eble plej baldaŭ por uzi la novan ŝlosilvorton
template. Subteno por iu ajn alia sintakso povas esti forigita en GitLab 12.0 aŭ aliaj estontaj eldonoj.
Aliaj plibonigoj en GitLab 11.9
Respondu al komento
(KENA, STARTER, PREMIUM, ULTIMATE, FREE, BRONZO, ARGENTO, ORO)
GitLab havas diskutojn pri temoj. Ĝis nun, la homo, kiu skribis la originan komenton, devis dekomence decidi ĉu li volas diskuton.
Ni malstreĉis ĉi tiun limigon. Prenu ajnan komenton en GitLab (pri aferoj, kunfandi petoj kaj epopeoj) kaj respondu al ĝi, tiel komencante diskuton. Tiel teamoj interagas pli organizite.
Projektaj ŝablonoj por .NET, Go, iOS kaj Paĝoj
(KENA, STARTER, PREMIUM, ULTIMATE, FREE, BRONZO, ARGENTO, ORO)
Por faciligi al uzantoj krei novajn projektojn, ni proponas plurajn novajn projektajn ŝablonojn:
- Elementa , kiu inkluzivas bazan aplikaĵon kun CI.
- Preta uzebla ŝablono, kiu kombinas kaj GitLab CI/CD.
- , preta por komenca personigo en GitLab. Notu, ke ĉar iOS-konstruaĵoj postulas dediĉitan MacOS-kurilon, vi devos provizi vian propran konstruservilon se vi volas uzi ĝin kun GitLab CI/CD.
- agordita por labori kun Netlify.
Postuli permeson por kunfandaj petoj de Kodposedantoj
(PREMIUMO, ULTIMA, ARGENTO, ORO)
Ne ĉiam estas evidente, kiu aprobas kunfandpeton.
GitLab nun subtenas postuli kunfandan peton esti aprobita surbaze de kiaj dosieroj la peto modifas, uzante . Kodposedantoj estas asignitaj uzante dosieron nomitan CODEOWNERS, la formato estas simila al gitattributes.
Subteno por aŭtomate asignado de Kodposedantoj kiel personoj respondecaj pri aprobo de kunfanda peto estis aldonita .
Movante dosierojn en Web IDE
(KENA, STARTER, PREMIUM, ULTIMATE, FREE, BRONZO, ARGENTO, ORO)
Nun, renominte la dosieron aŭ dosierujon, vi povas movi ĝin de la TTT-IDE al la deponejo laŭ la nova vojo.
Etikedoj en alfabeta ordo
(KENA, STARTER, PREMIUM, ULTIMATE, FREE, BRONZO, ARGENTO, ORO)
GitLab-etikedoj estas nekredeble multflankaj, kaj teamoj konstante trovas novajn uzojn por ili. Sekve, uzantoj ofte aldonas multajn etikedojn al afero, kunfandi peton aŭ epopeon.
En GitLab 11.9, ni iom plifaciligis uzi etikedojn. Por aferoj, kunfandi petoj kaj epopeoj, la etikedoj kiuj aperas en la flanka kolumno estas aranĝitaj en alfabeta ordo. Ĉi tio validas ankaŭ por vidi la liston de ĉi tiuj objektoj.
Rapidaj komentoj kiam filtras agojn laŭ tasko
(KENA, STARTER, PREMIUM, ULTIMATE, FREE, BRONZO, ARGENTO, ORO)
Ni lastatempe enkondukis funkcion, kiu ebligas al uzantoj filtri la agadfluon laŭ taskoj, kunfandi petojn aŭ epopeojn, kio permesas al ili koncentriĝi nur pri komentoj aŭ sistemaj notoj. Ĉi tiu agordo estas konservita por ĉiu uzanto en la sistemo, kaj povas okazi, ke uzanto eble ne rimarkas, ke kiam vi vidas problemon kelkajn tagojn poste, ili vidas filtritan fluaĵon. Li sentas, ke li ne povas lasi komenton.
Ni plibonigis ĉi tiun interagon. Nun uzantoj povas rapide ŝanĝi al reĝimo, kiu permesas al ili lasi komentojn sen rulumi reen al la supro de la feed. Ĉi tio validas por taskoj, kunfandaj petoj kaj epopeoj.
Ŝanĝante la ordon de infanaj epopeoj
(FININA, ORO)
Ni ĵus publikigis , kiuj permesas la uzon de epopeoj de epopeoj (krom infanaj taskoj de epopeoj).
Vi nun povas rearanĝi la ordon de infanaj epopeoj simple trenante kaj faligante, same kiel ĉe infanaj aferoj. Teamoj povas uzi ordon por reflekti prioritaton aŭ determini la ordon en kiu laboro devus esti kompletigita.
Proprataj kapliniaj kaj piedpiedaj sistemaj mesaĝoj en la reto kaj retpoŝto
(KENA, STARTER, PREMIUM, ULTIMATE)
Ni antaŭe aldonis funkcion, kiu ebligas kutimajn titolojn kaj piedpaĝajn mesaĝojn aperi sur ĉiu paĝo en GitLab. Ĝi estis varme ricevita, kaj teamoj uzas ĝin por dividi gravajn informojn, kiel sistemajn mesaĝojn ligitajn al sia GitLab-instanco.
Ni ĝojas alporti ĉi tiun funkcion al Kerno por ke eĉ pli da homoj povu uzi ĝin. Aldone, ni permesas al uzantoj laŭvole montri la samajn mesaĝojn en ĉiuj retpoŝtoj senditaj per GitLab por konsistenco trans la alia tuŝpunkto de GitLab de la uzanto.
Filtri per konfidencaj taskoj
(KENA, STARTER, PREMIUM, ULTIMATE, FREE, BRONZO, ARGENTO, ORO)
Konfidencaj Aferoj estas utila ilo por teamoj por ebligi privatajn diskutojn pri sentemaj temoj ene de malferma projekto. Aparte, ili estas idealaj por labori pri sekurecaj vundeblecoj. Ĝis nun, administri sentemajn taskojn ne estis facila.
En GitLab 11.9, la GitLab-problemlisto nun estas filtrita per sentemaj aŭ ne-sentemaj aferoj. Ĉi tio validas ankaŭ por serĉado de taskoj uzante la API.
Dankon al Robert Schilling pro lia kontribuo)!
Redaktado de Knative Domajno Post Deplojo
(KENA, STARTER, PREMIUM, ULTIMATE, FREE, BRONZO, ARGENTO, ORO)
Specifante kutiman domajnon instalante Knative ebligas al vi servi diversajn senservilajn aplikojn/funkciojn de unika finpunkto.
Kubernetes-integriĝo en GitLab nun permesas vin ŝanĝi/ĝisdatigi la uzantan domajnon post deplojado de Knative al la Kubernetes-areo.
Kontrolante la formaton de atestilo de Kubernetes CA
(KENA, STARTER, PREMIUM, ULTIMATE, FREE, BRONZO, ARGENTO, ORO)
Aldonante ekzistantan Kubernetes-grupon, GitLab nun kontrolas, ke la CA-atestilo enigita estas en valida PEM-formato. Ĉi tio forigas eblajn erarojn kun Kubernetes-integriĝo.
Etendi la komparan peton kunfandi al la tuta dosiero
(KENA, STARTER, PREMIUM, ULTIMATE, FREE, BRONZO, ARGENTO, ORO)
Kiam vi vidas ŝanĝojn al kunfanda peto, vi nun povas etendi la diferencan ilon laŭ po-dosiera bazo por montri la tutan dosieron por pli da kunteksto, kaj lasi komentojn pri la neŝanĝitaj linioj.
Efektivigu specifajn laborojn bazitajn sur kunfandaj petoj nur kiam iuj dosieroj ŝanĝiĝas
(KENA, STARTER, PREMIUM, ULTIMATE, FREE, BRONZO, ARGENTO, ORO)
GitLab 11.6 aldonis la kapablon difini por duktaj laboroj por ke uzantoj povu plenumi specifajn taskojn nur dum kreado de kunfanda peto.
Nun ni plivastigas ĉi tiun funkcion: konekta logiko estis aldonita , kaj uzantoj povas efektivigi specifajn laborojn nur por kunfandaj petoj kaj nur kiam certaj dosieroj ŝanĝiĝas.
Dankon pro la kontribuo Hiroyuki Sato ()!
Aŭtomatigita GitLab Monitorado kun Grafana
(KENA, STARTER, PREMIUM, ULTIMATE)
Grafana nun estas inkluzivita en nia Omnibus-pakaĵo, faciligante kompreni kiel funkcias via kazo.
Agordu grafana['enable'] = true в gitlab.rb, kaj Grafana estos disponebla ĉe: https://your.gitlab.instance/-/grafana. En proksima estonteco ni ankaŭ faros "el la skatolo".
Rigardu ĉefajn epopeojn en la flanka kolumno de epopeoj
(FININA, ORO)
Ni lastatempe prezentis , permesante la uzon de epopeoj de epopeoj.
En GitLab 11.9, ni faciligis vidi ĉi tiun rilaton. Nun vi povas vidi ne nur la patrinan epopeon de difinita epopeo, sed la tutan epopean arbon en la flanka kolumno dekstre. Vi povas vidi ĉu ĉi tiuj epopeoj estas fermitaj aŭ ne, kaj vi eĉ povas iri rekte al ili.
Ligi al nova tasko de movita kaj fermita tasko
(KENA, STARTER, PREMIUM, ULTIMATE, FREE, BRONZO, ARGENTO, ORO)
En GitLab, vi povas facile movi problemon al alia projekto per la flanka kolumno aŭ rapida ago. Malantaŭ la scenoj, la ekzistanta tasko estas fermita kaj nova tasko estas kreita en la cela projekto kun ĉiuj kopiitaj datumoj, inkluzive de sistemaj notoj kaj flankaj atributoj. Ĉi tio estas bonega trajto.
Konsiderante ke ekzistas sistema noto pri la movo, uzantoj, kiam vi vidas fermitan taskon, estas konfuzitaj kaj ne povas ne rimarki, ke la tasko estis fermita pro movo.
Kun ĉi tiu eldono, ni klarigas en la piktogramo ĉe la supro de la paĝo de fermita numero, ke ĝi estas movita, kaj ni ankaŭ inkluzivas enigitan ligilon al la nova numero por ke ĉiu, kiu atingas la malnovan numeron, povas rapide. navigu al la nova.
YouTrack integriĝo
(KENA, STARTER, PREMIUM, ULTIMATE, FREE, BRONZO, ARGENTO, ORO)
GitLab integriĝas kun multaj eksteraj problemoj pri spurado de sistemoj, faciligante al teamoj uzi GitLab por aliaj funkcioj konservante sian elektan ilon pri administrado de problemoj.
En ĉi tiu eldono ni aldonis la kapablon integri YouTrack de JetBrains.
Ni ŝatus danki Kotau Jauchen pro lia kontribuo ()!
Regrandigi la kunfandan peton-dosierarbon
(KENA, STARTER, PREMIUM, ULTIMATE, FREE, BRONZO, ARGENTO, ORO)
Vidante kunfandpetajn ŝanĝojn, vi nun povas regrandigi la dosierarbon por montri longajn dosiernomojn aŭ ŝpari spacon sur pli malgrandaj ekranoj.
Iru al lastatempaj taskobretoj
(STARTER, PREMIUM, ULTIMATE, BRONZO, ARGENTO, ORO)
Paneloj estas tre utilaj, kaj teamoj kreas plurajn panelojn por ĉiu projekto kaj grupo. Ni lastatempe aldonis serĉbreton por rapide filtri ĉiujn panelojn pri kiuj vi interesiĝas.
En GitLab 11.9 ni ankaŭ enkondukis sekcion lastatempaj en la fallisto. Tiel vi povas rapide salti al la paneloj, kun kiuj vi lastatempe interagis.
Kapablo por programistoj krei protektitajn branĉojn
(KENA, STARTER, PREMIUM, ULTIMATE, FREE, BRONZO, ARGENTO, ORO)
Protektitaj branĉoj malhelpas nereviziitan kodon esti movita aŭ kunfandita. Tamen, se neniu rajtas movi protektitajn branĉojn, tiam neniu povas krei novan protektitan branĉon: ekzemple eldonbranĉo.
En GitLab 11.9, programistoj povas krei protektitajn branĉojn de jam protektitaj branĉoj per GitLab aŭ la API. Uzi Git por movi novan protektitan branĉon ankoraŭ estas limigita por eviti hazarde krei novajn protektitajn branĉojn.
Git Objekta Deduplikado por Malfermaj Forkoj (Betao)
(KENA, STARTER, PREMIUM, ULTIMATE)
Forking permesas al iu ajn kontribui al malfermfontaj projektoj: sen skribpermeso, simple kopiante la deponejon en novan projekton. Stoki kompletajn kopiojn de ofte forkitaj Git-deponejoj estas malefika. Nun kun Git alternatives forkoj dividas oftajn objektojn de la gepatroprojekto en objektonaĝejo por redukti diskstokadpostulojn.
Fork-objektoj estas kreitaj nur por malfermitaj projektoj kiam haŝita stokado estas ebligita. Objektoj estas ebligitaj uzante funkcioparametron object_pools.
Filtri la liston de kunfandaj petoj de asignitaj aprobantoj
(STARTER, PREMIUM, ULTIMATE, BRONZO, ARGENTO, ORO)
Kodrevizio estas ofta praktiko por iu sukcesa projekto, sed povas esti malfacile por recenzisto konservi trakon de kunfandaj petoj.
En GitLab 11.9, la listo de kunfandaj petoj estas filtrita de asignita aprobanto. Tiel vi povas trovi kunfandajn petojn aldonitajn al vi kiel recenzisto.
Dankon al Glewin Wiechert pro liaj kontribuoj ()!
Ŝparvojoj por sekva kaj antaŭa dosiero en kunfanda peto
(KENA, STARTER, PREMIUM, ULTIMATE, FREE, BRONZO, ARGENTO, ORO)
Vidante ŝanĝojn al kunfanda peto, vi povas rapide ŝanĝi inter dosieroj uzante ]aŭ j movi al la sekva dosiero kaj [ aŭ k por iri al la antaŭa dosiero.
Simpligo .gitlab-ci.yml por senservilaj projektoj
(KENA, STARTER, PREMIUM, ULTIMATE, FREE, BRONZO, ARGENTO, ORO)
Konstruita sur funkcieco GitLab CI, senservila ŝablono gitlab-ci.yml tre simpligita. Por enkonduki novajn funkciojn en estontaj eldonoj, vi ne bezonas fari ŝanĝojn al ĉi tiu dosiero.
Subteno de la gastiga nomo de eniro
(KENA, STARTER, PREMIUM, ULTIMATE, FREE, BRONZO, ARGENTO, ORO)
Dum deplojado de Kubernetes Ingress-regilo, iuj platformoj falas reen al IP-adreso (ekzemple, GKE de Google), dum aliaj falas reen al DNS-nomo (ekzemple, EKS de AWS).
Nia Kubernetes-integriĝo nun subtenas ambaŭ specojn de finpunktoj por montri en la sekcio clusters projekto.
Dankon al Aaron Walker pro lia kontribuo ()!
Limigante JupyterHub-ensalutan aliron nur al teamaj/projektaj membroj
(KENA, STARTER, PREMIUM, ULTIMATE, FREE, BRONZO, ARGENTO, ORO)
Deploji JupyterHub uzante la Kubernetes-integriĝon de GitLab estas bonega maniero konservi kaj uzi Jupyter Notebooks en grandaj teamoj. Estas ankaŭ utile kontroli aliron al ili dum transdono de konfidencaj aŭ personaj datumoj.
En GitLab 11.9, la kapablo ensaluti en JupyterHub-instancoj deplojitaj per Kubernetes estas limigita al projektmembroj kun programisto-aliro (per grupo aŭ projekto).
Agordigeblaj tempointervaloj por sekurecaj paneloj
(FININA, ORO)
La Teama Sekureca Panelo inkluzivas vundeblecon por doni superrigardon pri la aktuala sekureca stato de la projektoj de la teamo. Ĉi tio estas tre utila por sekurecaj direktoroj por starigi procezojn kaj kompreni kiel funkcias la teamo.
En GitLab 11.9, vi nun povas elekti la tempon por ĉi tiu vundebla mapo. Defaŭlte, ĉi tio estas la lastaj 90 tagoj, sed vi povas agordi la daŭron al 60 aŭ 30 tagoj, depende de la nivelo de detalo, kiun vi bezonas.
Ĉi tio ne influas la datumojn en la nombriloj aŭ listo, nur la datumajn punktojn montritajn en la diagramo.
Aldono de Aŭtomata DevOps-konstrulaboro por etikedoj
(KENA, STARTER, PREMIUM, ULTIMATE, FREE, BRONZO, ARGENTO, ORO)
La konstrupaŝo de Aŭtomata DevOps kreas konstruon de via aplikaĵo uzante la Dockerfile de via Heroku-projekto aŭ konstrupakaĵo.
En GitLab 11.9, la rezulta Docker-bildo enigita en la etikeddukto estas nomita simile al tradiciaj bildnomoj uzante etikedan kommit anstataŭ SHA.
Dankon al Aaron Walker pro lia kontribuo!
Ĝisdatigu Code Climate al versio 0.83.0
(STARTER, PREMIUM, ULTIMATE, BRONZO, ARGENTO, ORO)
GitLab uzoj por kontroli kiel ŝanĝoj influas la staton de via kodo kaj projekto.
En GitLab 11.9 ni ĝisdatigis la motoron al la plej nova versio () por provizi la avantaĝojn de plia lingvo kaj senmova analiza subteno por GitLab Code Quality.
Dankon al GitLab Core teamano Takuya Noguchi pro liaj kontribuoj ()!
Zomi kaj movu la metrikan panelon
(KENA, STARTER, PREMIUM, ULTIMATE, FREE, BRONZO, ARGENTO, ORO)
Kiam oni esploras rendimentajn anomaliojn, estas ofte utile rigardi pli detale individuajn partojn de aparta metriko.
Kun GitLab 11.9, uzantoj povos zomi al individuaj tempoperiodoj en la metrika panelo, rulumi tutan tempoperiodon kaj facile reveni al la vido de la origina tempointervalo. Ĉi tio permesas vin rapide kaj facile esplori la eventojn, kiujn vi bezonas.
SAST por TypeScript
(FININA, ORO)
estas relative nova programlingvo bazita sur .
En GitLab 11.9, Static Application Security Testing (SAST) analizas kaj detektas vundeblecojn en TypeScript-kodo, montrante ilin en la kunfanda peto-fenestraĵo, duktonivelo kaj sekureca panelo. Nuna Labordifino sast ne necesas ŝanĝi, kaj ĝi ankaŭ estas aŭtomate inkluzivita en .
SAST por multmodulaj Maven-projektoj
(FININA, ORO)
Maven-projektoj ofte estas organizitaj por kombini en unu deponejo. Antaŭe, GitLab ne povis ĝuste skani tiajn projektojn, kaj programistoj kaj sekurecaj specialistoj ne ricevis raportojn pri vundeblecoj.
GitLab 11.9 ofertas vastigitan subtenon por la SAST-trajto por ĉi tiu specifa projekta agordo, provizante la kapablon testi ilin pri vundeblecoj kiel estas. Danke al la fleksebleco de la analiziloj, la agordo estas determinita aŭtomate, kaj vi ne bezonas ŝanĝi ion ajn por vidi rezultojn por plurmodulaj Maven-aplikoj. Kiel kutime, similaj plibonigoj ankaŭ haveblas ene .
GitLab Runner 11.9
(KENA, STARTER, PREMIUM, ULTIMATE, FREE, BRONZO, ARGENTO, ORO)
Hodiaŭ ni ankaŭ publikigis GitLab Runner 11.9! GitLab Runner estas malfermfonta projekto kaj estas uzata por ruli CI/KD-laborojn kaj sendi la rezultojn reen al GitLab.
Malsupre estas kelkaj el la ŝanĝoj en GitLab Runner 11.9:
- .
- и .
- ... ĝi estas la sama .
- por subteno , kiu aperos en GitLab 11.10.
- .
- .
- Movante plurajn skriptojn - inkluzive и - en Go.
- .
- .
- .
La plena listo de ŝanĝoj troveblas en la ŝanĝprotokolo de GitLab Runner: .
Pliboniĝoj de la skemo de GitLab
(KENA, STARTER, PREMIUM, ULTIMATE)
La sekvaj plibonigoj estis faritaj al GitLab-diagramo:
- Aldonita subteno por Google Cloud Memorystore.
- Cron-labor-agordoj , ĉar ili estas uzataj de pluraj servoj.
- La registro estis ĝisdatigita al versio 2.7.1.
- Aldonis novan agordon por igi la GitLab-registron kongrua kun Docker-versioj antaŭ 1.10. Por aktivigi, instalu
registry.compatibility.schema1.enabled: true.
Rendimento plibonigo
(KENA, STARTER, PREMIUM, ULTIMATE, FREE, BRONZO, ARGENTO, ORO)
Ni daŭre plibonigas la agadon de GitLab per ĉiu eldono por GitLab-kazoj de ĉiuj grandecoj. Jen kelkaj plibonigoj en GitLab 11.9:
- .
- .
- .
- .
Omnibus-plibonigoj
(KENA, STARTER, PREMIUM, ULTIMATE)
GitLab 11.9 inkluzivas la sekvajn Omnibus-plibonigojn:
- GitLab 11.9 inkluzivas , , kies plej nova eldono inkluzivas MFA por Team Edition, plibonigitan bildan rendimenton kaj pli. Ĉi tiu versio ankaŭ inkluzivas ; rekomendita ĝisdatigo.
- Aldonis novan agordon por igi la GitLab-registron kongrua kun Docker-versioj antaŭ 1.10. Por aktivigi, instalu
registry['compatibility_schema1_enabled'] = true в gitlab.rb. - La GitLab-registro nun eksportas Prometheus-metrikojn kaj estas aŭtomate kontrolata de envenantaj .
- Aldonita subteno por Google Cloud Memorystore, kiu postulas .
opensslĝisdatigita al versio 1.0.2r,nginx- ĝis versio 1.14.2,python- ĝis versio 3.4.9,jemalloc- ĝis versio 5.1.0,docutils- ĝis versio 0.13.1,gitlab-monitor- ĝis versio 3.2.0.
Malrekomenditaj trajtoj
GitLab Geo alportos haŝitan stokadon al GitLab 12.0
GitLab Geo estas bezonata mildigi konkuradon (vetkura kondiĉo) sur sekundaraj nodoj. Ĉi tio estis notita en .
En GitLab ni aldonis ĉi tiun postulon al la Geo-dokumentado: .
En GitLab sudo gitlab-rake gitlab: geo: check kontrolas ĉu haŝita stokado estas ebligita kaj ĉu ĉiuj projektoj estas migritaj. Cm. . Se vi uzas Geo, bonvolu fari ĉi tiun kontrolon kaj migri kiel eble plej baldaŭ.
En GitLab konstante malfunkciigita averto estos montrata sur la paĝo Administra Areo › Geo › Nodojse la supraj kontroloj ne estas permesitaj.
En GitLab Geo uzos haŝitajn konservajn postulojn. Cm. .
Dato de Forigo: 22 junio 2019
Hipchat integriĝo
Hipchat . Krome, en versio 11.9 .
Dato de Forigo: 22 Marto 2019
Subteno de CentOS 6 por GitLab Runner uzante Docker-ekzekutoron
GitLab Runner ne subtenas CentOS 6 kiam vi uzas Docker sur GitLab 11.9. Ĉi tio estas la rezulto de ĝisdatigo al la kernbiblioteko Docker, kiu ne plu subtenas CentOS 6. Por pliaj detaloj, vidu .
Dato de Forigo: 22 Marto 2019
GitLab Runner heredaj kodaj vojoj
Ekde Gitlab 11.9 GitLab Runner uzas kloni/voki la deponejon. Nuntempe, GitLab Runner uzos la malnovan metodon se la nova ne estas subtenata.
En GitLab 11.0, ni ŝanĝis la agordan vidon de metrika servilo por GitLab Runner. metrics_server estos forigita favore al listen_address en GitLab 12.0. Vidu pli en . Kaj pli da detaloj en .
En versio 11.3, GitLab Runner komencis subteni , kio kondukis al novaj agordoj por . la estas tabelo de ŝanĝoj kaj instrukcioj por migri al la nova agordo. Vidu pli en .
Ĉi tiuj vojoj ne plu disponeblas en GitLab 12.0. Kiel uzanto, vi ne bezonas ŝanĝi ion krom certigi, ke via GitLab-instanco funkcias version 11.9+ dum ĝisdatigo al GitLab Runner 12.0.
Dato de Forigo: 22 junio 2019
Malrekomendita opcio por enirpunkto-trajto por GitLab Runner
Funkcia parametro enkondukita en 11.4 GitLab Runner ripari problemojn kiel и .
En GitLab 12.0, ni ŝanĝos al la ĝusta konduto kvazaŭ la funkcio-agordo estus malŝaltita. Vidu pli en .
Dato de Forigo: 22 junio 2019
Malrekomendita subteno por Linukso-distribuo, kiu atingis EOL por GitLab Runner
Iuj Linukso-distribuoj, sur kiuj vi povas instali GitLab Runner, plenumis sian celon.
En GitLab 12.0, GitLab Runner ne plu distribuos pakaĵojn al ĉi tiuj Linukso-distribuoj. Kompleta listo de distribuoj, kiuj ne plu estas subtenataj, troviĝas en nia . Dankon al Javier Ardo () por li !
Dato de Forigo: 22 junio 2019
Forigante malnovajn komandojn de GitLab Runner Helper
Kadre de niaj klopodoj subteni devis forlasi kelkajn el la malnovaj komandoj, kiuj estas uzataj por .
En GitLab 12.0, GitLab Runner estas lanĉita per novaj komandoj. Ĉi tio nur influas uzantojn, kiuj superregas . Vidu pli en .
Dato de Forigo: 22 junio 2019
Programistoj povas forigi Git-etikedojn en GitLab 11.10
Forigi aŭ redakti versajn notojn por Git-etikedoj en nekontrolitaj branĉoj historie estis limigita al nur .
Ĉar programistoj povas aldoni etikedojn kaj modifi kaj forigi senprotektajn branĉojn, programistoj devus povi forigi Git-etikedojn. En GitLab 11.10 en nian permesmodelon por plibonigi laborfluon kaj helpi programistojn uzi etikedojn pli bone kaj pli efike.
Se vi volas konservi ĉi tiun limigon por prizorgantoj kaj posedantoj, uzu .
Dato de Forigo: 22 aprilo 2019
Subteno de Prometheus 1.x en Omnibus GitLab
Komencante kun GitLab , la enkonstruita versio de Prometheus 1.0 estis forigita de Omnibus GitLab. . Tamen, la metrika formato ne kongruas kun versio 1.0. Ekzistantaj versioj povas esti ĝisdatigitaj al 2.0 kaj, se necese, datumoj transdonitaj .
En GitLab-versio Prometheus 2.0 estos aŭtomate instalita se la ĝisdatigo ne estas jam instalita. Datumoj de Prometheus 1.0 estos perditaj ĉar... ne estas tolerataj.
Dato de Forigo: 22 junio 2019
TLS v1.1
Komencante kun GitLab plibonigi sekurecon. Ĉi tio solvas multajn problemojn, inkluzive de Heartbleed, kaj igas GitLab PCI DSS 3.1 konforma el la skatolo.
Por tuj malŝalti TLS v1.1, agordu nginx['ssl_protocols'] = "TLSv1.2" в gitlab.rband kaj kuru gitlab-ctl reconfigure.
Dato de Forigo: 22 junio 2019
OpenShift-ŝablono por instalado de GitLab
Oficiala — la rekomendita metodo por ruli GitLab sur Kubernetes, inkluzive .
instali GitLab estas malrekomendita kaj ne plu estos subtenata .
Dato de Forigo: 22 junio 2019
Antaŭaj difinoj de sekurecaj laborpostenoj
Kun enkonduko iuj antaŭaj labordifinoj estos malrekomenditaj kaj estos forigitaj en GitLab 12.0 aŭ poste.
Ĝisdatigu viajn labordifinojn por uzi la novan sintakson kaj utiligi ĉiujn novajn sekurecajn funkciojn provizitajn de GitLab.
Dato de forigo: la 22-an de junio 2019
Sekcio pri Sistema Informoj en la administra panelo
GitLab prezentas informojn pri via GitLab-instanco en admin/system_info, sed ĉi tiu informo eble ne estas preciza.
Ni administra panelo en GitLab 12.0 kaj ni rekomendas uzi .
Dato de Forigo: 22 junio 2019
fonto: www.habr.com