Eldonaĵo 13.4 estis publikigita kun HashiCorp-stokado por CI-variabloj, Kubernetes Agent kaj sekureca centro, same kiel ŝanĝeblaj funkcioj en Starter.
Ĉe GitLab, ni ĉiam pensas pri kiel ni povas helpi uzantojn redukti riskon, plibonigi efikecon kaj plibonigi liverrapidecon en via plej ŝatata platformo. Ĉi-monate ni aldonis multajn utilajn novajn funkciojn, kiuj pligrandigas sekureckapablojn, reduktas la nombron da vundeblecoj, pliigas efikecon, simpligas labori kun GitLab kaj helpas vian teamon liveri funkciojn eĉ pli rapide. Ni esperas, ke vi trovos la ĉefajn funkciojn de la eldono utilaj, same kiel 53 aliaj novaj funkcioj, aldonita en ĉi tiu eldono.
Altnivelaj Sekurecaj Trajtoj
Ni provas aldoni plurajn novajn funkciojn al GitLab DevSecOps ĉiumonate, kaj ĉi tiu eldono ne estas escepto. kadre de kunigo kaj deplojo. Aldone, organizoj kiuj volas subteni apartigon de kodaj deplojrespondecoj nun povas . Ĉi tiu rolo korespondas kaj permesos vin konfirmi kunfandi petojn (en la rusa lokalizo de GitLab "kunfandi petoj") kaj deploji kodon en protektitaj medioj, sen havigi aliron por ŝanĝi la kodon mem.
Alia maniero redukti riskojn estas uzi novan . Operaciaj teamoj povas deploji Kubernetes-aretojn de GitLab sen devi elmontri sian areton al la tuta interreto. Ni ankaŭ enkondukas aŭtomatan version-kontrolan subtenon por novaj ŝtatdosieroj de Terraform kun por subteni konformecon kaj facilecon de senararigado. Fine, la instanca sekureca panelo fariĝis kun vundeblaj raportoj kaj sekurecaj agordoj.
Pli oportuna kaj efika laboro kun GitLab
Ni plibonigis nian tutmondan serĉon por inkluzivi , ebligante vin facile navigi al la plej novaj biletoj, grupoj, projektoj, agordoj kaj helptemoj. Ni ĝojas anonci tiujn GitLab Paĝojn redirekti individuajn paĝojn kaj adresarojn ene de la retejo, kio permesos al uzantoj pli efike disfaldi siajn retejojn. Kaj por tiuj, kiuj ŝatus ricevi vastigitajn informojn pri la disfaldiĝo, ĉi tiu eldono permesas !
Malfermfontaj Kontribuoj
Ni reprezentas kiun mi aldonis . Markoj sur unutesta kovrado de ŝanĝita kodo donas al programistoj klaran ideon pri koda kovrado dum revizio; ĉi tiu informo helpas akceli recenzojn kaj redukti la tempon por kunfandi kaj disfaldi novan kodon. Kaj ni ankaŭ kaj plano .
Kaj ĉi tio estas nur la komenco!
Kiel ĉiam, estas tro malmulte da spaco en la ĝenerala superrigardo, sed estas multaj bonegaj funkcioj en la 13.4-eldono. Jen kelkaj pliaj:
- .
Se vi volas scii anticipe, kio atendas vin en sekva liberigu, rigardu .
.
ĉi-monate -
Fabio signife kontribuis в - funkcio kiu estas atendita de tre longa tempo en la GitLab-komunumo. Ĉi tio estas vere grava kontribuo kun ne-trivialaj ŝanĝoj kiuj postulis konstantan kunlaboron kun GitLab-teamanoj kaj influis multajn areojn de la projekto kiel ekzemple UX, front-end kaj back-end.
Ĉefaj trajtoj de la eldono de GitLab 13.4
Uzu HashiCorp Vault-ŝlosilojn en CI-laboroj
(PREMIUMO, ULTIMA, ARGENTO, ORO)
En eldono 12.10, GitLab lanĉis la kapablon ricevi kaj transdoni ŝlosilojn al CI-laboroj uzante la GitLab-labortraktilon (GitLab-kuristo). Nun ni plivastiĝas , aldonante novan sintakson secrets arkivi .gitlab-ci.yml. Ĉi tio faciligos agordi kaj uzi la deponejon HashiCorp kun GitLab.
и .
Prezentante GitLab Kubernetes Agent
(PREMIUMO, ULTIMA)
La integriĝo de GitLab kun Kubernetes longe ebligis deploji al Kubernetes-aretoj sen bezono de mana agordo. Multaj uzantoj ŝatis la facilecon de uzo de ĉi tiu pakaĵo, dum aliaj renkontis kelkajn malfacilaĵojn. Por la nuna integriĝo, via areto devas esti alirebla de la Interreto por ke GitLab aliru ĝin. Por multaj organizoj, tio ne eblas ĉar ili limigas aliron al aretoj pro sekureco, konformeco aŭ reguligaj kialoj. Por ĉirkaŭiri ĉi tiujn limigojn, uzantoj bezonis konstrui siajn ilojn sur GitLab, alie ili ne povus uzi ĉi tiun funkcion.
Hodiaŭ ni prezentas la GitLab Kubernetes Agenton, novan manieron deploji al Kubernetes-grupoj. La agento funkcias en via areto, do vi ne bezonas elmontri ĝin al la tuta Interreto. La agento kunordigas la deplojon petante novajn ŝanĝojn de GitLab, prefere ol GitLab puŝi ĝisdatigojn al la areto. Ne gravas kian GitOps-metodon vi uzas, GitLab kovras vin.
Bonvolu noti, ke ĉi tio estas la unua eldono de la agento. Nia nuna fokuso por GitLab Kubernetes Agent estas agordi kaj administri deplojojn per kodo. Iuj ekzistantaj integraj funkcioj de Kubernetes, kiel deplojtabuloj kaj administritaj aplikoj de GitLab, ankoraŭ ne estas subtenataj. ke ĉi tiuj kapabloj estos aldonitaj al la agento en estontaj eldonoj, same kiel novaj integriĝoj koncentritaj pri sekureco kaj konformeco.
и .
Donu al uzantoj deplojajn permesojn sen koda aliro
(PREMIUMO, ULTIMA, ARGENTO, ORO)
Antaŭe, la permessistemo de GitLab malfaciligis konvene dividi respondecojn ene de via teamo inter tiuj respondecaj pri evoluo kaj tiuj respondecaj pri deplojo. Kun la liberigo de GitLab 13.4, vi povas doni permeson aprobi kunfandi petojn por deplojo, same kiel efektive disfaldi kodon al homoj, kiuj ne skribas la kodon, sen doni al ili alirrajtojn de prizorganto (en la rusa lokalizo de GitLab "prizorganto" ).
и .
Sekureca Centro
(FININA, ORO)
Antaŭe, administrado de vundebleco de ekzemplnivelo estis limigita en kaj funkcieco kaj fleksebleco. La interfaco estis ununura paĝo, kiu kombinas detalojn de vundeblecoj, metrikaj grafikaĵoj kaj agordoj. Ne estas multe da loko por disvolvi ĉi tiujn funkciojn aŭ uzi aliajn sekurecajn funkciojn.
Ni faris fundamentajn ŝanĝojn al kiel ni administras sekurecon kaj travideblecon en GitLab. La sekureca panelo transformiĝis al tuta sekureca centro. La plej granda ŝanĝo estas la enkonduko de nova menua strukturo: anstataŭ unu paĝo, vi nun vidas la sekurecan instrumentpanelon, vundeblecon kaj agordan sekcion aparte. Kvankam la funkcieco ne ŝanĝiĝis, disrompi ĝin en partojn ebligos plibonigojn al ĉi tiu sekcio, kiuj alie estus malfacilaj. Ĉi tio ankaŭ metas la scenejon por aldoni aliajn sekurec-rilatajn kapablojn en la estonteco.
La diligenta sekcio pri Vulnerability Report nun havas pli da spaco por montri gravajn detalojn. Jen la vundeblecoj, kiuj estas nuntempe en la listo de vundeblecoj de la projekto. Movi fenestraĵojn kun vundeblecoj al aparta sekcio kreas oportunan sekurecan kontrolpanelon. Ĝi nun estas kanvaso por estontaj bildigoj - ne nur por vundebleco-administrado, sed por ajnaj sekurecaj metrikoj. Finfine, aparta agorda areo kreas komunan spacon por ĉiuj ekzemplnivelaj sekurecaj agordoj, ne nur vundebleco-administrado.
и .
Ŝalteblaj funkcioj nun estas en GitLab Starter
(STARTER, PREMIUM, ULTIMATE, BRONZO, ARGENTO, ORO)
GitLab 11.4 estis publikigita . En 12.2 ni enkondukis strategiojn por ili и , kaj en 13.1 ili aldonis и por malsamaj medioj.
Komence de ĉi tiu jaro, GitLab faris devontigon en malferman fonton. En ĉi tiu eldono, ni kompletigis la migradon de ŝanĝeblaj funkcioj al la Starter-plano kaj daŭre migros ilin al Core de . Ni ĝojas alporti ĉi tiun funkcion al pli da uzantoj kaj volas aŭdi kiel vi uzas ĝin.
и .
Rapida navigado de la serĉbreto
(KENA, STARTER, PREMIUM, ULTIMATE, FREE, BRONZO, ARGENTO, ORO)
Kelkfoje, kiam vi navigas por GitLab, vi volas iri rekte al specifa projekto prefere ol la serĉrezulta paĝo.
Uzante la tutmondan serĉbreton, vi povas rapide navigi al la plej novaj biletoj, grupoj, projektoj, agordoj kaj helptemoj. Vi eĉ povas uzi klavoklavon /movi vian kursoron al la serĉbreto por navigi GitLab eĉ pli efike!
и .
Montrante kodan kovradon en kunfandaj petodiferencoj
(KENA, STARTER, PREMIUM, ULTIMATE, FREE, BRONZO, ARGENTO, ORO)
Dum reviziado de kunfanda peto, povas esti malfacile determini ĉu la ŝanĝita kodo estas kovrita per unutestoj. Anstataŭe, recenzistoj povas fidi je la ĝenerala priraportado kaj peti ke ĝi estu pliigita antaŭ aprobi kunfandan peton. Ĉi tio povas konduki al hazarda aliro al verkado de testoj, kiuj fakte ne plibonigos kodkvaliton aŭ testan kovradon.
Nun, kiam vi vidas kunfandan peton, vi vidos vidan montradon de koda kovrado. Novaj markoj permesos vin rapide kompreni ĉu la ŝanĝita kodo estas kovrita de unutesto, kiu helpos akceli kodan revizion kaj la tempon de kunfandado kaj deplojado de nova kodo.
Спасибо kaj Siemens por ĉi tiu funkcio!
и .
Pli da medioj kaj projektoj en la panelo Medioj
(PREMIUMO, ULTIMA, ARGENTO, ORO)
Ekde la liberigo de GitLab 12.5 uzante vi povus kontroli la staton de medioj, sed ne pli ol sep medioj en tri projektoj. Ni plibonigis ĉi tiun panelon en eldono 13.4 per paĝigo de ĝi por helpi vin konservi kaj administri viajn mediojn laŭskale. Nun vi povas vidi pli da medioj en pli da projektoj.
и .
GitLab prenas kontrolon de la GitLab Terraform-provizanto
(KENA, STARTER, PREMIUM, ULTIMATE, FREE, BRONZO, ARGENTO, ORO)
Lastatempe ni kaj plano . Dum la pasinta monato, ni akceptis 21 kunfandigajn petojn kaj fermis 31 biletojn, inkluzive de kelkaj longdaŭraj eraroj kaj mankantaj funkcioj kiel ekzemple ... Vi povas en la Terraform-dokumentado.
и .
Fuzzing API-testado kun OpenAPI-specifoj aŭ HAR-dosiero
(FININA, ORO)
API-fuzzing-testado estas bonega maniero trovi cimojn kaj vundeblecojn en viaj TTT-aplikoj kaj API-oj, kiujn aliaj skaniloj kaj testaj metodoj povus maltrafi.
API-fuzzing-testado en GitLab permesas vin provizi aŭ via aplikaĵo kaj tiam aŭtomate generas hazardajn enigajn datumojn desegnitajn por testi randkazojn kaj trovi cimojn. Rezultoj estas tuj videblaj ene de via dukto.
Ĉi tio estas nia unua eldono pri fuzz-testado de API kaj ni ŝatus aŭdi kion vi pensas. Ni havas pli da stoko por fuzz-testado , kiun ni bazos sur la liberigo de ĉi tiu funkcio.
и .
Antaŭrigardu novajn grafikaĵojn en la metrika panelo
(KENA, STARTER, PREMIUM, ULTIMATE, FREE, BRONZO, ARGENTO, ORO)
Antaŭe, krei grafeon en la metrika panelo en GitLab ne estis facila tasko. Post kiam vi kreis la metrikon en la panela YAML-dosiero, vi faris ŝanĝojn al master, sen povi kontroli, ke la nove kreita grafeo funkcias ĝuste kiel vi bezonas. Komencante kun ĉi tiu eldono, vi povas antaŭrigardi ŝanĝojn dum vi kreas la grafeon, havante ideon pri la rezulto antaŭ sendi la ŝanĝojn al la panela YAML-dosiero.
и .
Datumoj pri koda kovrado per testoj por ĉiuj projektoj de la grupo
(PREMIUMO, ULTIMA, ARGENTO, ORO)
Kiam vi administras grandan nombron da projektoj en GitLab, vi bezonas ununuran fonton de informoj pri kiel koda kovrado ŝanĝiĝas laŭlonge de la tempo tra ĉiuj projektoj. Antaŭe, montri ĉi tiun informon postulis tedan kaj tempopostulan manlibron: vi devis elŝuti kodkovrajn datumojn de ĉiu projekto kaj kombini ĝin en tabelo.
En eldono 13.4, fariĝis eble facile kaj rapide kunveni .csv dosiero kun ĉiuj datumoj pri koda kovrado por ĉiuj projektoj de la grupo aŭ por elekto de projektoj. Ĉi tiu funkcio estas MVC, ĝi estos sekvita de la kapablo .
и .
Subteno por novaj lingvoj por plena fuzz-testado
(FININA, ORO)
Ĉi tiu eldono enkondukas subtenon por pluraj novaj lingvoj por fuzz-testado celita al plena priraportado.
Nun vi povas taksi la plenajn kapablojn de fuzzing-testado en viaj Java, Rust, kaj Swift-aplikaĵoj kaj trovi erarojn kaj vundeblecojn, kiujn aliaj skaniloj kaj testaj metodoj povas maltrafi.
и .
Atentigoj sur la ĉefa mediopaĝo
(PREMIUMO, ULTIMA, ARGENTO, ORO)
La paĝo Medioj montras la ĝeneralan staton de viaj medioj. En ĉi tiu eldono ni plibonigis ĉi tiun paĝon aldonante atentan ekranon. Ekigitaj atentigoj kune kun la stato de viaj medioj helpos vin rapide agi por korekti situaciojn aperantajn.
и .
Nestitaj duktoj nun povas funkciigi siajn proprajn nestitajn duktojn
(KENA, STARTER, PREMIUM, ULTIMATE, FREE, BRONZO, ARGENTO, ORO)
Uzante nestitajn duktoj, nun eblas funkciigi novajn duktoj ene de infanduktoj. La ekstra nivelo de profundo povas esti utila se vi bezonas la flekseblecon por generi varian nombron da duktoj.
Antaŭe, dum uzado de nestitaj duktoj, ĉiu infandukto postulis ellasillaboron esti permane difinita en la gepatra dukto. Nun vi povas krei nestitajn duktoj, kiuj dinamike lanĉos ajnan nombron da novaj nestitaj duktoj. Ekzemple, se vi havas monodeponejon, vi povas dinamike generi la unuan subdukton, kiu mem kreos la postulatan nombron da novaj duktoj surbaze de ŝanĝoj en la branĉo.
и .
Plibonigita navigado inter gepatraj kaj nestitaj duktoj
(KENA, STARTER, PREMIUM, ULTIMATE, FREE, BRONZO, ARGENTO, ORO)
Antaŭe, navigi inter gepatra kaj nestita dukto ne estis tre oportuna - vi bezonis multajn klakojn por atingi la deziratan dukton. Ankaŭ ne estis facile eltrovi, kiu laboro komencis la dukton. Nun estos multe pli facile vidi la ligojn inter gepatraj kaj nestitaj duktoj.
и .
Paralelaj matricaj laborpostenoj montras signifajn variablojn en labortitolo
(KENA, STARTER, PREMIUM, ULTIMATE, FREE, BRONZO, ARGENTO, ORO)
Se vi uzis , vi eble rimarkis, ke estis malfacile determini, kiu matrica variablo estis uzata por aparta laboro, ĉar la labornomoj aspektis kiel matrix 1/4. En eldono 13.4, vi vidos la koncernajn variablovalorojn, kiuj estis uzataj en tiu laboro anstataŭ la ĝenerala labornomo. Ekzemple, se via celo estas sencimigi la x86-arkitekturon, tiam la laboro estus nomita matrix: debug x86.
и .
Aliaj plibonigoj en GitLab 13.4
Konektante Atlassian-konton
(KENA, STARTER, PREMIUM, ULTIMATE)
Uzantoj de GitLab nun povos konekti siajn GitLab-kontojn al sia konto de Atlassian Cloud. Ĉi tio permesos al vi ensaluti en GitLab kun viaj Atlassian-akreditaĵoj, kaj ankaŭ starigos la bazon por estontaj integriĝplibonigoj. kaj kun aliaj produktoj de la Atlassian linio.
и .
Eksportante liston de ĉiuj kunfandaj kommitaĵoj
(FININA, ORO)
Konformec-fokusitaj organizoj bezonas manieron montri al revizoroj tutecan vidon de la komponentoj asociitaj kun iu antaŭfiksita ŝanĝo en produktado. En GitLab, ĉi tio signifas kolekti ĉion en unu loko: kunfandi petojn, biletojn, duktoj, sekurecajn skanojn kaj aliajn komisajn datumojn. Ĝis nun, vi aŭ devis permane kolekti ĝin en GitLab aŭ agordi viajn ilojn por kolekti la informojn, kio ne estis tre efika.
Vi nun povas programe kolekti kaj eksporti ĉi tiujn datumojn por plenumi reviziajn postulojn aŭ fari aliajn analizojn. Por eksporti liston de ĉiuj kunfandaj kommitaĵoj por la nuna grupo, vi devas iri al kaj alklaku la butonon Listo de ĉiuj kunfandaj komitaĵoj. La rezulta dosiero enhavos ĉiujn kommitaĵojn de la kunfandpeto, ilian aŭtoron, ID de la rilata kunfandpeto, grupon, projekton, konfirmilojn kaj aliajn informojn.
и .
Listigu kaj administru personajn alirĵetonojn per API
(FININA, ORO)
Administri aliron al la nomspaco GitLab estas grava parto de plenumaj klopodoj. De principoj de malplej privilegio ĝis malfunkciigado de tempigita aliro, povas esti pluraj postuloj asociitaj kun personaj alirĵetonoj en GitLab. Por faciligi konservi kaj administri ĉiujn ĉi tiujn uzantajn akreditaĵojn ene de via nomspaco, ni disponigis la kapablon listigi ĉiujn personajn alirsignalojn kaj laŭvole. per API.
Ĉi tiuj plibonigoj al la GitLab API permesas al uzantoj listigi kaj nuligi siajn proprajn personajn alirĵetonojn, kaj administrantoj listigi kaj nuligi la ĵetonojn de siaj uzantoj. Nun estos pli facile por administrantoj vidi kiu havas aliron al sia nomspaco, fari alirdecidojn surbaze de uzantdatenoj kaj revoki personajn alirĵetonojn kiuj eble estis endanĝerigitaj aŭ kiuj restas ekster la aliradministradpolitikoj de la firmao.
и .
Rilataj problemoj kaj aliaj funkcioj nun estas en GitLab Core
(KENA, STARTER, PREMIUM, ULTIMATE, FREE, BRONZO, ARGENTO, ORO)
Antaŭ kelkaj monatoj ni anoncis planon . Laborante por plenumi ĉi tiun promeson, ni faris , и (en la rusa lokalizo de GitLab "diskutejo") disponebla en la Kerna plano. Ĉi tio validas nur por "ligitaj al" rilatoj; "blokoj" kaj "blokitaj" rilatoj restas en pagitaj planoj.
и .
Montrante la originbranĉan nomon en la kunfanda peto-flankbreto
(KENA, STARTER, PREMIUM, ULTIMATE, FREE, BRONZO, ARGENTO, ORO)
Dum reviziado de kodŝanĝoj, diskutoj kaj kunfandaj petoj, ofte estas dezirinde fari lokan kontrolon de la branĉo por pli profunda revizio. Tamen, trovi la fadennomon fariĝas ĉiam pli malfacila ĉar pli da enhavo estas aldonita al la kunfanpeta priskribo kaj vi devas rulumi pli malsupren la paĝon.
Ni aldonis la branĉonomon al la kunfanda peto flanka kolumno, farante ĝin alirebla en ajna momento kaj forigante la bezonon rulumi tra la tuta paĝo. Same kiel la ligo al la kunfanda peto, la fonta branĉo sekcio enhavas oportunan "kopion" butonon.
Спасибо pro via grandega kontribuo al la disvolviĝo de ĉi tiu funkcio!
и .
Indiko pri la ĉeesto de kolapsitaj dosieroj en kunfandaj petoj-diferencoj
(KENA, STARTER, PREMIUM, ULTIMATE, FREE, BRONZO, ARGENTO, ORO)
Kunfandi petojn, kiuj aldonas ŝanĝojn al pluraj dosieroj, foje kolapsas la diferencojn de grandaj dosieroj por plibonigi bildigan rendimenton. Kiam tio okazas, eblas hazarde preterpasi dosieron dum revizio, precipe en kunfandaj petoj kun granda nombro da dosieroj. Ekde la versio 13.4, kunfandaj petoj markos diferencojn, kiuj enhavas falditajn dosierojn, do vi ne maltrafos ĉi tiujn dosierojn dum koda revizio. Por eĉ pli klareco, ni planas aldoni reliefigon al ĉi tiuj dosieroj en estonta eldono. Restu agordita por ĝisdatigoj pri .
и .
Averto pri la ĉeesto de kolapsitaj dosieroj en la diferenco de kunfanda peto
(KENA, STARTER, PREMIUM, ULTIMATE, FREE, BRONZO, ARGENTO, ORO)
En la sekcio de diferencoj de peto kunfandi, grandaj dosieroj estas kolapsitaj por plibonigi rendimenton. Tamen, dum reviziado de kodo, iuj dosieroj povas esti maltrafitaj kiam la recenzisto rulumas tra la listo de dosieroj, ĉar ĉiuj grandaj dosieroj estas kolapsitaj.
Ni aldonis videblan averton ĉe la supro de la difpaĝo pri kunfanda peto por informi uzantojn, ke estas kunfandita dosiero en ĉi tiu sekcio. Tiel, vi ne maltrafos ajnajn ŝanĝojn al la kunfanda peto dum revizio.
и .
Aŭtomata reakiro de Gitaly-grupo-deponejo
(KENA, STARTER, PREMIUM, ULTIMATE, FREE, BRONZO, ARGENTO, ORO)
Antaŭe, kiam la primara nodo de Gitaly-areto malkonektas, la deponejoj sur tiu nodo estis markitaj kiel nurlegeblaj. Ĉi tio malhelpis datumperdon en situacioj kie ekzistis ŝanĝoj sur la nodo kiu ankoraŭ ne estis reproduktita. Kiam la nodo revenis interrete, GitLab ne estis aŭtomate restarigita, kaj administrantoj devis permane komenci la sinkronigan procezon aŭ akcepti datumperdon. Aliaj situacioj, kiel ekzemple fiasko de reproduktadlaboro sur sekundara nodo, ankaŭ povus rezultigi malfreŝajn aŭ nurlegeblajn deponejojn. En ĉi tiu kazo, la deponejo restis malfreŝa ĝis la sekva skriboperacio okazis, kiu komencus la reproduktan laboron.
Por solvi ĉi tiun problemon nun planas reproduktan laboron kiam ĝi detektas malmodernan deponejon sur unu nodo kaj la plej novan version de la deponejo sur alia. Ĉi tiu reproduktadlaboro tenas la deponejon ĝisdatigita aŭtomate, forigante la bezonon permane restarigi datumojn. Aŭtomata reakiro ankaŭ certigas, ke sekundaraj nodoj estas rapide ĝisdatigitaj se reproduktadlaboro malsukcesas, anstataŭ atendi la sekvan skriban operacion. Ĉar multaj Gilaly-aretoj stokas grandan nombron da deponejoj, tio signife reduktas la tempon, kiun administrantoj kaj fidindec-inĝenieroj pasigas por reakiri datumojn post eraro.
Krome, aŭtomata riparo komencas reproduktadon de deponejoj sur iu nova Gitaly-nodo aldonita al la areto, forigante manan laboron aldonante novajn nodojn.
и .
Marku farotan taskon kiel finite sur la dezajna paĝo
(KENA, STARTER, PREMIUM, ULTIMATE, FREE, BRONZO, ARGENTO, ORO)
Efika komunikado en GitLab baziĝas sur farolistoj. Se vi estas menciita en komento, estas grave povi salti al tasko kaj aŭ komenci fari ion aŭ marki ĝin kiel finita. Ankaŭ gravas povi asigni taskon al vi mem kiam vi devas labori pri io aŭ reveni al ĝi poste.
Antaŭe, vi ne povis aldoni taskojn aŭ marki ilin kiel finitaj kiam vi laboras kun dezajnoj. Ĉi tio grave interrompis la efikecon de komunikado inter produktteamoj, ĉar faroj estas kritika elemento de la laborfluo de GitLab.
En eldono 13.4, dezajnoj atingas biletajn komentojn en uzado de taskoj, kio faras labori kun ili pli konsekvenca kaj efika.
и .
Plibonigita problemo-solva gvidilo por CI/CD
(KENA, STARTER, PREMIUM, ULTIMATE, FREE, BRONZO, ARGENTO, ORO)
Ni plibonigis la gvidilon pri solvo de problemoj por GitLab CI/CD kun pli da informoj pri oftaj problemoj, kiujn vi eble renkontos. Ni esperas, ke la plibonigita dokumentaro estos valora rimedo por helpi vin ekfunkciigi GitLab CI/CD rapide kaj facile.
и .
Kunfandaj petoj ne plu falas el la kunfandvico
(PREMIUMO, ULTIMA, ARGENTO, ORO)
Antaŭe, kunfandaj petoj povis hazarde fali el la kunfandvico pro malfruaj komentoj. Se kunfandpeto jam estis en la atendovico kaj iu aldonis komenton al ĝi kiu kreis novan nesolvitan diskuton, la kunfandpeto estis konsiderata neelektebla por kunfandado kaj falus el la atendovico. Nun, post kiam kunfandpeto estas aldonita al la kunfandvico, novaj komentoj povas esti aldonitaj sen timo interrompi la kunfandprocezon.
и .
Montrante la kodan kovrovaloron por laboro en kunfanda peto
(KENA, STARTER, PREMIUM, ULTIMATE, FREE, BRONZO, ARGENTO, ORO)
Programistoj devus povi vidi la kodan kovrovaloron post kiam la dukto finiĝis - eĉ en kompleksaj scenaroj kiel ekzemple prizorgado de dukto kun multoblaj laboroj kiuj devas esti analizitaj por kalkuli la kovrovaloron. Antaŭe, la kunfanda peto-fenestraĵo nur montris la mezumon de ĉi tiuj valoroj, kio signifis, ke vi devis navigi al la laborpaĝo kaj reen al la kunfanda peto por akiri mezajn kovrajn valorojn. Por ŝpari al vi tempon kaj ĉi tiujn kromajn paŝojn, ni igis la fenestraĵon montri la averaĝan kovran valoron, ĝiajn ŝanĝojn inter la cela kaj fonta branĉoj, kaj konsileto, kiu montras la kovrovaloron por ĉiu laboro surbaze de kiu la mezumo estis kalkulita.
и .
Forigante pakaĵojn el la pakregistro dum rigardado de grupo
(KENA, STARTER, PREMIUM, ULTIMATE, FREE, BRONZO, ARGENTO, ORO)
La pakaĵregistro de GitLab estas loko por stoki kaj distribui pakaĵojn en malsamaj formatoj. Kiam vi havas multajn pakaĵojn en via projekto aŭ grupo, vi devas rapide identigi neuzatajn pakaĵojn kaj forigi ilin por malhelpi homojn elŝuti ilin. Vi povas forigi pakaĵojn el via registro per aŭ per la pakaĵregistra uzantinterfaco. Tamen, ĝis nun vi ne povis forigi pakaĵojn kiam vi vidas grupon per la UI. Rezulte, vi devis forigi nenecesajn pakaĵojn laŭprojekte, kio estis malefika.
Vi nun povas forigi pakaĵojn kiam vi rigardas la pakregistron de grupo. Simple iru al la pakaĵregistra paĝo de la grupo, filtru la pakaĵojn laŭ nomo kaj forigu iujn, kiujn vi ne bezonas.
и .
Skali Conan-pakaĵojn al projektnivelo
(KENA, STARTER, PREMIUM, ULTIMATE, FREE, BRONZO, ARGENTO, ORO)
Vi povas uzi la deponejon de Conan en GitLab por publikigi kaj distribui dependecojn de C/C++. Tamen, antaŭe pakaĵoj povis nur skali al la instanca nivelo, ĉar la paknomo de Conan povis nur esti maksimume 51 signoj. Se vi volis eldoni pakaĵon el subgrupo, ekzemple gitlab-org/ci-cd/package-stage/feature-testing/conan, estis preskaŭ neeble fari.
Vi nun povas grimpi pakaĵojn de Conan ĝis la nivelo de la projekto, faciligante publikigi kaj distribui la dependecojn de viaj projektoj.
и .
Subteno por novaj pakaĵadministrantoj kaj lingvoj por dependeca skanado
(FININA, ORO)
Ni ĝojas aldoni dependecajn skanaĵojn por C, C++, C# kaj .Net-kodaj projektoj, kiuj uzas NuGet 4.9+ aŭ Conan-pakaĵadministrantojn al nia listo. . Vi nun povas ebligi dependecan skanadon kiel parto de la Sekura stadio por kontroli konatajn vundeblecojn en dependecoj aldonitaj per pakaĵadministrantoj. La vundeblecoj trovitaj estos montritaj en via kunfanda peto kune kun ilia severeca nivelo, por ke vi sciu antaŭ ol plenumi la kunfandigon, kiajn riskojn portas la nova dependeco. Vi ankaŭ povas agordi vian projekton por postuli por dependecoj kun vundeblecoj kun kritika (Kritika), alta (Alta) aŭ nekonata (Nekonata) severeco.
и .
Sciigoj kiam ŝanĝas la kunfandan peton agordon al 'Kunfandi kiam dukto finiĝas sukcese'
(KENA, STARTER, PREMIUM, ULTIMATE, FREE, BRONZO, ARGENTO, ORO)
Antaŭe, kiam oni agordas la kunfandpetajn agordojn Kunfandi kiam la dukto finiĝas (Merge When Pipeline Succeeds, MWPS) neniu retpoŝta sciigo estis sendita. Vi devis permane kontroli la staton aŭ atendi kunfandigon. Kun ĉi tiu eldono ni ĝojas prezenti uzantkontribuojn , kiu solvis ĉi tiun problemon aldonante aŭtomatajn sciigojn al ĉiuj abonintaj kunfandipeton kiam recenzisto ŝanĝas la kunfandigon al MWPS.
и .
Kreante EKS-aretojn kun uzanto-specifita versio de Kubernetes
(KENA, STARTER, PREMIUM, ULTIMATE, FREE, BRONZO, ARGENTO, ORO)
Uzantoj de GitLab nun povas elekti la version de Kubernetes, kiu estos provizita de EKS; vi povas elekti inter versioj 1.14–1.17.
и .
Krei incidentojn kiel biletspecojn
(KENA, STARTER, PREMIUM, ULTIMATE, FREE, BRONZO, ARGENTO, ORO)
Ne ĉiu problemo kiu ekestas tuj ekigas alarmojn: uzantoj raportas malfunkciojn kaj teamanoj esploras rendimentajn problemojn. Okazaĵoj nun estas speco de bileto, do viaj teamoj povas rapide krei ilin kiel parto de sia normala laborfluo. Klaku Nova tasko de ie ajn en GitLab, kaj sur la kampo Tajpu elektu Okazaĵo.
и .
Menciante GitLab-Alertojn en Markdown
(KENA, STARTER, PREMIUM, ULTIMATE, FREE, BRONZO, ARGENTO, ORO)
Ni plibonigis GitLab-atentigojn aldonante novan menciotipon specife por ili en GitLab Markdown, faciligante kunhavigi kaj mencii atentigojn. Uzu ^alert#1234mencii la atentigon en iu ajn Markdown-kampo: en incidentoj, biletoj aŭ kunfandaj petoj. Ĉi tio ankaŭ helpos vin identigi laborpostenojn, kiuj estas kreitaj de atentigoj prefere ol biletoj aŭ kunfandaj petoj.
и .
Rigardante la atentan ŝarĝon laŭ okazaĵo
(KENA, STARTER, PREMIUM, ULTIMATE, FREE, BRONZO, ARGENTO, ORO)
La atentiga priskribo enhavas informojn esencajn por solvi problemojn kaj reakiron, kaj ĉi tiuj informoj devus esti facile alireblaj por ke vi ne devas ŝanĝi ilojn aŭ langetojn dum vi laboras por solvi okazaĵon. Okazaĵoj kreitaj de atentigoj montras la plenan atentan priskribon en la langeto Atentigaj Detaloj.
75% pli rapida altnivela serĉo
(STARTER, PREMIUM, ULTIMATE, BRONZO, ARGENTO, ORO)
GitLab, kiel ununura aplikaĵo, havas la unikan kapablon fari enhavan malkovron tra via tuta DevOps-laborfluo rapide. En GitLab 13.4, altnivela serĉo liveras rezultojn 75% pli rapide kiam ĝi , kiel ĉe GitLab.com.
и .
Vidante forigitajn projektojn por administrantoj
(KENA, STARTER, PREMIUM, ULTIMATE)
Estis eblo prokrasti projektan forigon . Tamen antaŭe ne eblis vidi ĉiujn projektojn atendantajn forigon en unu loko. Administrantoj de uzantkazaĵoj de GitLab nun povas vidi ĉiujn pritraktatajn forigajn projektojn en unu loko, kune kun butonoj por facile restarigi tiujn projektojn.
Ĉi tiu funkcio donas al administrantoj pli grandan kontrolon pri projekta forigo kolektante ĉiujn koncernajn informojn en unu loko kaj havigante la kapablon malfari nedeziratajn forigajn agojn.
Спасибо por ĉi tiu funkcio!
и .
Aldonita subteno por grupaj puŝreguloj al la API
(STARTER, PREMIUM, ULTIMATE, BRONZO, ARGENTO, ORO)
Antaŭe, grupaj puŝreguloj povus esti agorditaj nur vizitante ĉiun grupon individue per la GitLab UI kaj aplikante tiujn regulojn. Vi nun povas administri ĉi tiujn regulojn per API por subteni viajn kutimajn ilojn kaj aŭtomatigon de GitLab.
и .
Revokante personajn alirĵetonojn por mem-administrata akreditaĵostokado
(FININA)
Provizas al administrantoj la informojn, kiujn ili bezonas por administri uzantajn akreditaĵojn por sia GitLab-ekzemplo. Ĉar observo-fokusitaj organizoj varias laŭ la severeco de siaj akreditaĵoj-administradpolitikoj, ni aldonis butonon kiu permesas al administrantoj laŭvole revoki la personan alirĵetonon (PAT) de uzanto. Administrantoj nun povas facile revoki eble kompromititajn PAT-ojn. Ĉi tiu funkcio estas utila por organizoj kiuj volas pli flekseblajn plenumajn elektojn por minimumigi interrompon al siaj uzantoj.
и .
Agorda dosiero por la senmova retejo-redaktilo
(KENA, STARTER, PREMIUM, ULTIMATE, FREE, BRONZO, ARGENTO, ORO)
En GitLab 13.4, ni enkondukas novan manieron personecigi la senmovan retejan redaktilon. Kvankam la agorda dosiero ne konservas aŭ ricevas iujn ajn agordojn en ĉi tiu eldono, ni metas la bazon por estonta personigo de redakcia konduto. En estontaj eldonoj ni aldonos al la dosiero .gitlab/static-site-editor.yml parametroj por instalado , sur kiu , superregante la sintaksajn agordojn de Markdown kaj aliajn agordojn de la redaktilo.
и .
Redakti la enkondukan parton de dosiero uzante senmovan retejan redaktilon
(KENA, STARTER, PREMIUM, ULTIMATE, FREE, BRONZO, ARGENTO, ORO)
Antaŭa materio estas fleksebla kaj oportuna maniero difini paĝajn variablojn en datumdosieroj por prilaborado de la senmova reteja generatoro. Ĝi estas kutime uzata por agordi la paĝotitolon, enpaĝigŝablonon aŭ aŭtoron, sed povas esti uzata por transdoni ajnan tipon de metadatenoj al la generatoro dum prezentado de la paĝo en HTML. Inkluzivita ĉe la supro de ĉiu datumdosiero, la enkonduka parto estas tipe formatita kiel YAML aŭ JSON kaj postulas konsekvencan kaj precizan sintakson. Uzantoj ne konataj kun specifaj sintaksaj reguloj povas preterintence enigi nevalidan markadon, kiu siavice povas kaŭzi formatajn problemojn aŭ eĉ konstrui fiaskojn.
La redakta reĝimo WYSIWYG de la senmova retejo-redaktilo jam forigas la enkondukon de la redaktilo por malhelpi ĉi tiujn formatajn erarojn. Tamen ĉi tio malhelpas vin ŝanĝi la valorojn konservitajn en ĉi tiu parto sen reveni al redaktado en fontreĝimo. En GitLab 13.4, vi povas aliri ajnan kampon kaj redakti ĝian valoron en familiara form-bazita interfaco. Kiam la butono estas premata Agordoj (Agordoj) panelo malfermiĝos montrante formularan kampon por ĉiu ŝlosilo difinita ĉe la komenco. La kampoj estas plenigitaj per la nuna valoro, kaj redakti iun ajn el ili estas tiel simpla kiel enigi ĝin en la retformularo. Redakti la enkondukon tiamaniere evitas kompleksan sintakson kaj donas al vi kompletan kontrolon de la enhavo dum certigas ke la fina rezulto estas konstante formatita.
и .
GitLab por Jira kaj DVCS Connector nun estas en Kerno
(KENA, STARTER, PREMIUM, ULTIMATE, FREE, BRONZO, ARGENTO, ORO)
Por uzantoj de Jira en GitLab: и permesas vin montri informojn pri GitLab-komisioj kaj kunfandi petojn rekte en Jira. Kombinite kun nia enkonstruita Jira-integriĝo, vi povas facile moviĝi inter la du apoj dum vi laboras.
Ĉi tiuj funkcioj antaŭe estis nur disponeblaj en nia Premium-plano, sed nun disponeblas por ĉiuj uzantoj!
и .
Plimulta voĉdonado por Gitaly-grupo-transakcioj (beta)
(KENA, STARTER, PREMIUM, ULTIMATE)
Gitaly-grupo permesas al vi reprodukti Git-deponejojn al pluraj "varmaj" Gitaly-nodoj. Tio pliigas faŭltoleremon eliminante ununurajn punktojn de fiasko. , enkondukita en GitLab 13.3, igas ŝanĝojn elsenditaj al ĉiuj Gitaly-nodoj en la areto, sed nur Gitaly-nodoj kiuj voĉdonas konsente kun la primara nodo konservas la ŝanĝojn al disko. Se ĉiuj kopinodoj ne konsentas, nur unu kopio de la ŝanĝo estos stokita sur disko, kreante ununuran punkton de fiasko ĝis nesinkrona reproduktado finiĝas.
Plimulta voĉdonado plibonigas misfunkciadon postulante la konsenton de plimulto de nodoj (ne ĉiuj) antaŭ konservi ŝanĝojn al disko. Se ĉi tiu ŝaltilo estas ebligita, la skribo devus sukcesi sur pluraj nodoj. Malsamopiniaj nodoj estas aŭtomate sinkronigitaj uzante nesinkronan reproduktadon de tiuj nodoj kiuj formis kvorumon.
и .
Propra skemsubteno por JSON-validumado en Web IDE
(PREMIUMO, ULTIMA, ARGENTO, ORO)
Projektoj kie homoj skribas agordojn en JSON aŭ YAML ofte estas inklinaj al problemoj ĉar estas facile fari tajperarojn kaj rompi ion. Eblas skribi inspektajn ilojn por kapti ĉi tiujn problemojn en la CI-dukto, sed uzi JSON-skemdosieron povas esti utila por provizi dokumentadon kaj sugestojn.
Projektpartoprenantoj povas difini en sia deponejo la vojon al kutima skemo en dosiero .gitlab/.gitlab-webide.yml, kiu specifas la skemon kaj vojon al la kontrolotaj dosieroj. Kiam vi ŝargas specifan dosieron en la TTT-IDE, vi vidos pliajn sugestojn kaj validigon por helpi vin krei la dosieron.
и .
Direktita Acikla Grafiko (DAG) branĉa limo pliiĝis al 50
(KENA, STARTER, PREMIUM, ULTIMATE, FREE, BRONZO, ARGENTO, ORO)
Se vi uzas transportiloj (Direktita Acikla Grafiko (DAG)), vi eble trovos, ke ekzistas limo de 10 laborpostenoj, kiujn laboro povas specifi en needs:, tro severa. En 13.4, la defaŭlta limo estis pliigita de 10 al 50 por permesi pli kompleksajn retojn de rilatoj inter laboroj en viaj duktoj.
Se vi estas administranto de kutima GitLab-instanco, vi povas plialtigi ĉi tiun limon eĉ pli altan per agordo de baskuligo, kvankam ni ne ofertas oficialan subtenon por tio.
и .
Plibonigita konduto needs por mistrafitaj taskoj
(KENA, STARTER, PREMIUM, ULTIMATE, FREE, BRONZO, ARGENTO, ORO)
En kelkaj kazoj, maltrafita laboro en dukto povus esti malĝuste konsiderata sukcesa por dependecoj specifitaj en needs, kiu kaŭzis postajn laborojn funkcii, kio ne devus esti okazinta. Ĉi tiu konduto estis riparita en versio 13.4, kaj needs nun ĝuste pritraktas kazojn de mistrafitaj taskoj.
и .
Alpinglu la lastan serĉartefakton por malhelpi ĝin esti forigita
(KENA, STARTER, PREMIUM, ULTIMATE, FREE, BRONZO, ARGENTO, ORO)
GitLab nun aŭtomate ŝlosas la lastan sukcesan laboron kaj duktoartefakton sur iu ajn aktiva branĉo, kunfanda peto aŭ etikedo por malhelpi ĝin esti forigita post eksvalidiĝo. Fariĝas pli facile agordi pli agresemajn finajn regulojn por purigi malnovajn artefaktojn. Ĉi tio helpas redukti konsumon de diskspaco kaj certigas, ke vi ĉiam havas kopion de la plej nova artefakto de la dukto.
и .
CI/CD-Gvidilo pri Dukto-Optimumigo
(KENA, STARTER, PREMIUM, ULTIMATE, FREE, BRONZO, ARGENTO, ORO)
Optimumigi vian CI/KD-dukton povas plibonigi liverrapidecon kaj ŝpari monon. Ni plibonigis nian dokumentaron por inkluzivi rapidan gvidilon por profiti la plej bonan optimumigo de viaj duktoj.
и .
Testraporto ordigita laŭ testa stato
(KENA, STARTER, PREMIUM, ULTIMATE, FREE, BRONZO, ARGENTO, ORO)
estas facila maniero vidi la rezultojn de ĉiuj provoj en dukto. Tamen, kun granda nombro da testoj, trovi malsukcesajn testojn povas preni longan tempon. Aliaj aferoj, kiuj povas malfaciligi la uzon de la raporto, inkluzivas malfacilaĵojn por rulumi longajn spurajn elirojn kaj temporondonadon al nulo por testoj, kiuj funkcias en malpli ol 1 sekundo. Nun, defaŭlte, ordigante testan raporton, ĝi unue metas malsukcesajn testojn komence de la raporto, kaj poste ordigas la testojn laŭ daŭro. Ĉi tio faciligas trovi fiaskojn kaj longajn testojn. Aldone, testdaŭroj nun estas montrataj en milisekundoj aŭ sekundoj, igante ilin multe pli rapide legi, kaj antaŭaj rulproblemoj ankaŭ estis solvitaj.
и .
Limoj de la grandeco de dosieroj alŝutitaj al la paka registro
(KENA, STARTER, PREMIUM, ULTIMATE, FREE, BRONZO, ARGENTO, ORO)
Nun ekzistas limoj pri la grandeco de pakaĵdosieroj, kiuj povas esti alŝutitaj al la pakregistro de GitLab. Limigoj estis aldonitaj por optimumigi pakaĵregistran rendimenton kaj malhelpi misuzon. Limoj varias laŭ la pakformato. Por GitLab.com, maksimumaj dosiergrandoj estas:
- Conan: 250 MB
- Maven: 3GB
- NPM: 300MB
- NuGet: 250MB
- PyPI: 3GB
Por kutimaj GitLab-kazoj, la defaŭltoj estas la samaj. Tamen, la administranto povas ĝisdatigi la limigojn uzante .
и .
Uzu CI_JOB_TOKEN por eldoni PyPI-pakaĵojn
(KENA, STARTER, PREMIUM, ULTIMATE, FREE, BRONZO, ARGENTO, ORO)
Vi povas uzi la deponejon de GitLab PyPI por krei, publikigi kaj dividi Python-pakaĵojn kune kun fontkodo kaj CI/KD-duktoj. Tamen, antaŭe vi ne povis aŭtentikiĝi al la deponejo uzante antaŭdifinitan mediovariablon CI_JOB_TOKEN. Kiel rezulto, vi devis uzi viajn personajn akreditaĵojn por ĝisdatigi la deponejon de PyPI, aŭ vi eble decidis tute ne uzi la deponejon.
Nun estas pli facile uzi GitLab CI/CD por publikigi kaj instali PyPI-pakaĵojn uzante antaŭdifinitan mediovariablon. CI_JOB_TOKEN.
и .
DAST-skanilprofiloj laŭ peto
(FININA, ORO)
Al la laŭpeta DAST-skanado tio estis , DAST-skanilprofiloj estis aldonitaj. Ili etendas la agordajn kapablojn de ĉi tiuj skanadoj, permesante al vi rapide krei plurajn profilojn por kovri plurajn skanajn tipojn. En 13.4, la rampilo-profilo denaske inkluzivas agordon pri rampa tempo, kiu fiksas kiom longe la DAST-rapilo devas funkcii dum ĝi provas malkovri ĉiujn paĝojn de rampita retejo. La profilo ankaŭ inkluzivas agordon de cel-reteja tempo-tempo por agordi kiom longe la rampilo devas atendi ke retejo fariĝos alirebla antaŭ ĉesigi la rampadon se la retejo ne respondas per statuskodo 200 aŭ 300. Dum ni daŭre plibonigos Ĉi tiu funkcio estos aldonita al la skanila profilo en estontaj eldonoj; pliaj agordaj parametroj estos aldonitaj.
и .
Simpla redirekta agorda dosiero por GitLab Pages
(KENA, STARTER, PREMIUM, ULTIMATE, FREE, BRONZO, ARGENTO, ORO)
Se vi uzas GitLab Pages kaj volas pli bone administri URL-ŝanĝojn, vi eble rimarkis, ke administri alidirektilojn en via retejo de GitLab Pages ne eblis. GitLab nun permesas al vi agordi regulojn por redirekti unu URL al alia por via Paĝa retejo aldonante agordan dosieron al la deponejo. Ĉi tiu funkcio estas ebligita danke al la kontribuo de Kevin Barnett (), nia Eric Eastwood () kaj GitLab-teamoj. Dankon al ĉiuj pro via kontribuo.
и .
Terraform-ŝtato administrita de GitLab
(KENA, STARTER, PREMIUM, ULTIMATE, FREE, BRONZO, ARGENTO, ORO)
Aliro al antaŭaj versioj de Terraform-ŝtato estas necesa kaj por plenumado kaj por sencimigi se necese. Subteno por versio de Terraform-ŝtato administrita de GitLab estas provizita ekde GitLab 13.4. Versiado estas aŭtomate ebligita por novaj ŝtatdosieroj de Terraform. Ekzistantaj Terraform ŝtatdosieroj estos en posta eldono.
и .
Gravaj Okazaĵaj Sciigo-Detaloj
(KENA, STARTER, PREMIUM, ULTIMATE, FREE, BRONZO, ARGENTO, ORO)
Dum prilaborado de incidentoj, vi devas facile determini kiom longe alarmo estis malfermita kaj kiom da fojoj la evento estis ekigita. Ĉi tiuj detaloj ofte estas kritikaj por determini la efikon al la kliento kaj kion via teamo devus trakti unue. En la nova panelo pri Okazaĵo-Detaloj, ni montras la atentan komencan tempon, la nombron da eventoj kaj ligon al la originala atentigo. Ĉi tiuj informoj estas disponeblaj por okazaĵoj generitaj de atentigoj.
и .
Fiksante kaj redaktante la parametron de graveco de incidento
(KENA, STARTER, PREMIUM, ULTIMATE, FREE, BRONZO, ARGENTO, ORO)
La Incident Severity-dimensio permesas respondantojn kaj koncernatojn determini la efikon de malfunkcio, same kiel la metodon kaj urĝecon de la respondo. Ĉar via teamo dividas rezultojn dum incidenta solvado kaj reakiro, ili povas ŝanĝi ĉi tiun agordon. Vi nun povas redakti la severecon de okazaĵo en la dekstra flanka kolumno de la paĝo pri Okazaĵoj, kaj la severeco montriĝas en la listo de okazaĵoj.
и .
Kreado, redaktado kaj forigo de reguloj pri sekureca reto de konteneroj
(FININA, ORO)
Ĉi tiu plibonigo al la Uja Reto-Sekureca Regulredaktilo permesas al uzantoj facile krei, redakti kaj forigi siajn regulojn rekte de la uzantinterfaco de GitLab. Redaktrajtoj inkluzivas .yaml por spertaj uzantoj kaj regulredaktilo kun intuicia interfaco por tiuj novaj al retaj reguloj. Vi povas trovi novajn regulojn pri administrado en la sekcio Sekureco kaj Konformeco > Administrado de Minacoj > Reguloj (Sekureco kaj Konformeco > Administrado de Minacoj > Politikoj).
и .
Azure blob stokado subteno
(KENA, STARTER, PREMIUM, ULTIMATE, FREE, BRONZO, ARGENTO, ORO)
Kaj GitLab kaj GitLab Runner nun subtenas , faciligante ruli GitLab-servojn sur Azure.
GitLab-instancoj subtenas Azure por ĉiuj specoj de objektobutikoj, inkluzive de LFS-dosieroj, CI-artefaktoj, kaj . Por agordi Azure Blob-stokadon, sekvu la instalajn instrukciojn aŭ .
GitLab laborprocesoroj ankaŭ subtenas Azure por stokado . Azure-stokado povas esti agordita per la sekcio .
и .
Omnibus ARM64-pakaĵoj por Ubuntu kaj OpenSUSE
(KENA, STARTER, PREMIUM, ULTIMATE)
Responde al kreskanta postulo pri subteno por ruli GitLab sur 64-bita ARM-arkitekturo, ni ĝojas anonci la haveblecon de la oficiala ARM64 Ubuntu 20.04 Omnibus-pakaĵo. Koran dankon al Zitai Chen kaj Guillaume Gardet pro la grandegaj kontribuoj, kiujn ili faris - iliaj kunfandpetoj ludis ŝlosilan rolon en tio!
Por elŝuti kaj instali la pakaĵon por Ubuntu 20.04, iru al nia kaj elektu Ubuntu.
и .
Subteno pri aŭtentikiga saĝkarto por GitLab Helm-diagramo
(PREMIUMO, ULTIMA)
Saĝkartoj, kiel Common Access Cards (CAC), nun povas esti uzataj por aŭtentikigi al GitLab-okazaĵo deplojita per Helm-diagramo. Saĝkartoj estas aŭtentikigitaj kontraŭ loka datumbazo per X.509-atestiloj. Kun ĉi tio, inteligenta karto-subteno kun Helm-diagramo nun kongruas kun la inteligenta karto-subteno disponebla en Omnibus-deplojoj.
и .
Detalaj eldonnotoj kaj ĝisdatigaj/instalaj instrukcioj legeblas en la originala angla afiŝo: .
Ni laboris pri traduko el la angla , , и .
fonto: www.habr.com