Выйшаў рэліз 13.4/XNUMX са сховішчам HashiCorp для зменных CI, Kubernetes Agent і цэнтрам бяспекі, а таксама пераключаюцца фічамі ў Starter
У GitLab мы заўсёды думаем аб тым, як дапамагчы карыстальнікам знізіць рызыкі, павысіць эфектыўнасць і хуткасць пастаўкі на вашай каханай платформе. У гэтым месяцы мы дадалі нямала карысных навін, якія пашыраюць магчымасці бяспекі, зніжаюць колькасць уразлівасцяў, павялічваюць эфектыўнасць, спрашчаюць працу з GitLab і дапамагаюць вашай камандзе пастаўляць фічы яшчэ хутчэй. Мы спадзяемся, што вам спатрэбяцца асноўныя фічы рэлізу, а таксама 53 іншыя новыя фічы, дададзеныя ў гэтым рэлізе.
Пашыраныя магчымасці бяспекі
Мы стараемся дадаваць некалькі новых фіч да GitLab DevSecOps кожны месяц, і гэты рэліз – не выключэнне. у рамках зборкі і разгортвання. Акрамя таго, арганізацыі, якія жадаюць падтрымліваць падзел абавязкаў па разгортванні кода, зараз могуць . Гэтая роля адпавядае і дазволіць пацвярджаць мерж-рэквесты (у рускай лакалізацыі GitLab "запыты на зліццё") і разгортваць код у абароненых асяроддзях, не падаючы пры гэтым доступу для змены самога кода.
Яшчэ адзін спосаб знізіць рызыкі - выкарыстанне новага . Адмыслоўцы па эксплуатацыі могуць разгортваць кластары Kubernetes з GitLab без неабходнасці адчыняць доступ да свайго кластара для ўсяго інтэрнэту. Мы таксама прадстаўляем аўтаматычную падтрымку кантролю версій для новых файлаў стану Terraform з для падтрымкі адпаведнасці патрабаванням і зручнасці ў адладцы. І нарэшце, панэль кіравання бяспекай у інстансе ператварылася ў са справаздачамі аб уразлівасцях і наладамі бяспекі.
Больш зручная і эфектыўная праца з GitLab
Мы палепшылі наш глабальны пошук, дадаўшы ў яго , якая дазваляе лёгка пераходзіць да апошніх тыкетаў, груп, праектаў, налад і раздзелаў даведкі. Мы рады аб'явіць, што ў GitLab Pages для пераадрасацыі асобных старонак і каталогаў усярэдзіне сайта, што дазволіць карыстачам больш эфектыўна разгортваць свае сайты. А тым, хто хацеў бы атрымліваць пашыраную інфармацыю аб разгортванні, гэты рэліз дазваляе !
Уклады з адкрытым зыходным кодам
Мы прадстаўляем , якое дадаў . Адзнакі аб пакрыцці юніт-тэстамі змененага кода даюць распрацоўнікам навочнае ўяўленне пра пакрыццё кода пры рэўю; гэтая інфармацыя дапамагае паскорыць рэўю і паменшыць час на мерж і разгортванне новага кода. А яшчэ мы і плануем .
І гэта яшчэ толькі пачатак!
Як і заўсёды, у агульным аглядзе занадта мала месцы, а класных фіч у рэлізе 13.4/XNUMX вельмі шмат. Вось яшчэ некалькі:
- .
Калі вы хочаце загадзя даведацца, што вас чакае ў наступным рэлізе, паглядзіце .
.
гэтага месяца -
Fabio ўнёс значны в - фічу, якую вельмі доўга чакалі ў супольнасці GitLab. Гэта сапраўды важны фундуш з нетрывіяльнымі зменамі, якія патрабавалі сталага супрацоўніцтва з чальцамі каманды GitLab і закраналі мноства абласцей праекту, такіх як UX, фронтенд і бэкенд.
Асноўныя фічы рэлізу GitLab 13.4
Выкарыстоўвайце ключы HashiCorp Vault у заданнях CI
(PREMIUM, ULTIMATE, SILVER, GOLD)
У рэлізе 12.10 GitLab прадставіў магчымасць атрымліваць і перадаваць ключы ў CI-заданні з дапамогай апрацоўшчыка заданняў GitLab (GitLab runner). Цяпер мы пашыраем , дадаючы новы сінтаксіс secrets у файл .gitlab-ci.yml. Гэта аблегчыць наладу і выкарыстанне сховішчы HashiCorp з GitLab.
и .
Прадстаўляем GitLab Kubernetes Agent
(PREMIUM, ULTIMATE)
Інтэграцыя GitLab з Kubernetes ужо даўно дазваляе разгортваць на кластарах Kubernetes без неабходнасці ручной наладкі. Многім карыстальнікам спадабалася прастата выкарыстання гэтай звязкі, у той час як іншыя сутыкнуліся з некаторымі цяжкасцямі. Для бягучай інтэграцыі ваш кластар павінен быць даступны з інтэрнэту, каб GitLab мог мець да яго доступ. Для многіх арганізацый гэта не ўяўляецца магчымым, паколькі яны абмяжоўваюць доступ да кластараў з меркаванняў бяспекі, адпаведнасці патрабаванням або ў мэтах рэгулявання. Каб абыйсці гэтыя абмежаванні, карыстачам трэба было ствараць свае прылады па-над GitLab, інакш яны не змаглі б выкарыстаць гэтую магчымасць.
Сёння мы прадстаўляем GitLab Kubernetes Agent - новы спосаб разгортвання на кластарах Kubernetes. Агент працуе ўнутры вашага кластара, так што вам не спатрэбіцца адчыняць яго для ўсяго інтэрнэту. Агент каардынуе разгортванне, запытваючы новыя змены ў GitLab, замест таго, каб GitLab адпраўляў абнаўленні на кластар. Незалежна ад таго, які метад GitOps вы карыстаецеся, GitLab вам падыдзе.
Звярніце ўвагу, што гэта першы рэліз агента. У цяперашні час мы зрабілі для GitLab Kubernetes Agent упор на наладу і кіраванне разгортваннем праз код. Некаторыя існуючыя функцыі інтэграцыі Kubernetes, такія як дошкі разгортвання і прыкладанні, кіраваныя GitLab, пакуль не падтрымліваюцца. , Што гэтыя магчымасці будуць дададзены ў агент у будучых рэлізах, а таксама новыя інтэграцыі, арыентаваныя на бяспеку і адпаведнасць патрабаванням.
и .
Дайце карыстальнікам дазвол на разгортванне без доступу да кода.
(PREMIUM, ULTIMATE, SILVER, GOLD)
Раней сістэма дазволаў у GitLab не давала магчымасці пісьменна падзяліць абавязкі ў вашай камандзе паміж тымі, хто адказвае за распрацоўку, і тымі, хто адказвае за разгортванне. З рэлізам GitLab 13.4 вы можаце даць дазвол на пацверджанне мерж-рэквестаў для разгортвання, а таксама на фактычнае разгортванне кода людзям, не якія пішуць код, пры гэтым не падаючы ім правы доступу мэйнтэйнера (у рускай лакалізацыі GitLab "суправаджальны".
и .
Цэнтр бяспекі
(ULTIMATE, GOLD)
Раней кіраванне ўразлівасцямі на ўзроўні інстанса было абмежавана як па функцыянальнасці, так і па гнуткасці. Інтэрфейс уяўляў сабой адну старонку, якая аб'ядноўвае ў сабе дэталі ўразлівасцяў, графікі метрык і наладкі. Не так ужо шмат месца для развіцця гэтых функцый ці выкарыстанні іншых сродкаў бяспекі.
Мы ўнеслі фундаментальныя змены ва ўпраўленне бяспекай і яе празрыстасцю ў GitLab. Панэль бяспекі інстанса пераўтварылася ў цэлы цэнтр бяспекі. Самае вялікае змяненне - гэта ўвядзенне новай структуры меню: замест адной старонкі зараз вы асобна бачыце панэль кіравання бяспекай, справаздачу аб уразлівасцях і раздзел налад. Хоць функцыянальнасць не змянілася, разбіццё на часткі дазволіць паляпшаць гэты раздзел, што ў адваротным выпадку было б цяжка. Гэта таксама стварае базу для дадання ў будучыні іншых магчымасцяў, звязаных з бяспекай.
У спецыяльнай часткі для справаздачы аб уразлівасцях зараз больш месца для адлюстравання важных дэталяў. Тут сабраны ўразлівасці, якія ў наш час знаходзяцца ў спісе ўразлівасцяў праекту. Перанос віджэтаў з метрыкамі ўразлівасцяў у асобную частку стварае зручную панэль кіравання бяспекай. Зараз гэта палатно для будучых візуалізацый - не толькі для кіравання ўразлівасцямі, але і для любых метрык, звязаных з бяспекай. Нарэшце, асобная вобласць налад стварае агульную прастору для ўсіх налад бяспекі на ўзроўні інстанса, не толькі для кіравання ўразлівасцямі.
и .
Пераключаюцца фічы зараз у GitLab Starter
(STARTER, PREMIUM, ULTIMATE, BRONZE, SILVER, GOLD)
У GitLab 11.4 была выпушчана . У 12.2/XNUMX мы ўвялі для іх стратэгіі и , а ў 13.1 дадалі и для розных акружэнняў.
Раней у гэтым годзе GitLab узяў на сябе абавязацельства у адкрыты зыходны код. У гэтым рэлізе мы завяршылі перанос пераключаюцца фіч у план Starter і працягнем перанос іх у Core з . Мы рады даць гэтую магчымасць большай колькасці карыстальнікаў і хочам даведацца, як вы будзеце іх выкарыстоўваць.
и .
Хуткая рух з радка пошуку
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Часам пры навігацыі па GitLab вы жадаеце адразу перайсці да вызначанага праекту, а не на старонку з вынікамі пошуку.
З дапамогай панэлі глабальнага пошуку вы можаце хутка перайсці да апошніх тыкетаў, груп, праектаў, налад і раздзелаў даведкі. Вы нават можаце выкарыстоўваць гарачую клавішу /, Каб перамясціць курсор на панэль пошуку, каб яшчэ больш эфектыўна перамяшчацца па GitLab!
и .
Адлюстраванне пакрыцця кода ў дыфах мерж-рэквестаў
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Пры рэўю мерж-рэквеста можа быць цяжка вызначыць, ці пакрыты зменены код юніт-тэстамі. Замест гэтага правяраючыя могуць спадзявацца на агульнае пакрыццё і патрабаваць яго павялічыць, перш чым пацвярджаць мерж-рэквест. Гэта можа прывесці да бессістэмнага падыходу да напісання тэстаў, што насамрэч не палепшыць якасць кода ці яго пакрыццё тэстамі.
Цяпер пры праглядзе дыфа мерж-рэквеста вы ўбачыце нагляднае адлюстраванне пакрыцця кода. Новыя пазнакі дазволяць хутка зразумець, ці пакрыты зменены код юніт-тэстам, што дапаможа паскорыць рэўю кода і час мержа і разгортванні новага кода.
Дзякуй і Siemens за гэтую фічу!
и .
Больш акружэнняў і праектаў на панэлі акружэнняў
(PREMIUM, ULTIMATE, SILVER, GOLD)
З рэлізу GitLab 12.5 з дапамогай вы маглі адсочваць стан акружэнняў, але не больш за сем асяродкаў у трох праектах. Мы палепшылі гэтую панэль у рэлізе 13.4, разбіўшы яе на старонкі, каб дапамагчы вам падтрымліваць вашыя асяроддзі і кіраваць імі ў вялікіх маштабах. Цяпер вы можаце бачыць больш акружэнняў у большай колькасці праектаў.
и .
GitLab прыняў кіраванне правайдэрам GitLab Terraform
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Нядаўна мы і плануем . За апошні месяц мы прынялі 21 мерж-рэквест і закрылі 31 тыкет, у тым ліку некаторыя даўно існавалыя памылкі і адсутныя фічы, такія як . Вы можаце у дакументацыі па Terraform.
и .
Фазінг-тэставанне API са спецыфікацыямі OpenAPI або HAR-файлам
(ULTIMATE, GOLD)
Фазінг-тэставанне API - гэта выдатны спосаб пошуку ў вашых вэб-прыкладаннях і API памылак і ўразлівасцяў, якія іншыя сканары і метады тэставання могуць прапусціць.
Тэставанне API фазінгам у GitLab дазваляе падаць або вашага прыкладання, а затым аўтаматычна генеруе выпадковыя ўваходныя дадзеныя, прызначаныя для праверкі краявых выпадкаў і пошуку памылак. Вынікі адразу ж адлюстроўваюцца ў рамках вашага канвеера.
Гэта наш першы рэліз тэсціравання API фазінгам, і мы будзем рады даведацца, што вы думаеце. Для фазінг-тэставанні ў нас у запасе яшчэ , якія мы будзем засноўваць на рэлізе гэтай фічы.
и .
Прадпрагляд новых графікаў на панэлі метрык
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Раней стварэнне графіка на панэлі метрык у GitLab было няпростай задачай. Пасля таго, як вы стварылі метрыку ў YAML-файле панэлі, вы ўносілі змены ў master, не маючы магчымасці праверыць, што толькі што створаны графік працуе менавіта так, як вам было трэба. Пачынаючы з гэтага рэлізу вы можаце папярэдне праглядаць змены па меры стварэння графіка, атрымліваючы ўяўленне аб выніку перад адпраўкай змен у YAML-файл панэлі.
и .
Дадзеныя аб пакрыцці кода тэстамі па ўсіх праектах групы
(PREMIUM, ULTIMATE, SILVER, GOLD)
Калі вы кіруеце вялікай колькасцю праектаў у GitLab, вам патрабуецца адзіная крыніца інфармацыі аб тым, як з часам змяняецца пакрыццё кода па ўсіх праектах. Раней адлюстраванне гэтай інфармацыі патрабавала стомнай і працаёмкай ручной працы: трэба было спампаваць дадзеныя аб пакрыцці кода тэстамі з кожнага праекта і аб'яднаць іх у табліцы.
У рэлізе 13.4 з'явілася магчымасць лёгка і хутка сабраць у .csv файл усе дадзеныя аб пакрыцці кода па ўсіх праектах групы або па выбарцы праектаў. Гэтая фіча – MVC, за ёй рушыць услед магчымасць .
и .
Падтрымка новых моў для поўнага фазінг-тэставанні
(ULTIMATE, GOLD)
Гэты рэліз уяўляе падтрымку некалькіх новых моў для фазінг-тэставанні, накіраванага на поўнае пакрыццё.
Цяпер вы можаце ацаніць усе магчымасці фазінг-тэставанні ў вашых прыкладаннях на Java, Rust і Swift і знайсці памылкі і ўразлівасці, якія іншыя сканары і метады тэсціравання могуць прапусціць.
и .
Абвесткі на галоўнай старонцы акружэнняў
(PREMIUM, ULTIMATE, SILVER, GOLD)
Старонка акружэнняў паказвае агульны стан вашых акружэнняў. У гэтым рэлізе мы палепшылі гэтую старонку, дадаўшы адлюстраванне абвестак. Якія спрацавалі абвесткі разам са статутам вашых акружэнняў дапамогуць вам хутчэй прымаць меры па выпраўленні якія ўзнікаюць сітуацый.
и .
Укладзеныя канвееры зараз могуць запускаць свае ўкладзеныя канвееры
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Пры выкарыстанні ўкладзеных канвеераў стала магчымым запускаць новыя канвееры ўсярэдзіне даччыных канвеераў. Дадатковы ўзровень глыбіні можа быць карысны, калі вам патрэбна гнуткасць для генерацыі пераменнай колькасці канвеераў.
Раней пры выкарыстанні ўкладзеных канвеераў кожнаму даччынаму канвееру патрабавалася заданне-трыгер, уручную зададзенае ў бацькоўскім канвееры. Цяпер жа вы можаце ствараць укладзеныя канвееры, якія будуць дынамічна запускаць любую колькасць новых укладзеных канвеераў. Напрыклад, калі ў вас монорепозиторий, вы можаце дынамічна генераваць першы ўкладзены канвеер, які сам будзе ствараць неабходную колькасць новых канвеераў, засноўваючыся на зменах у галінцы.
и .
Палепшаная рух паміж бацькоўскімі і ўкладзенымі канвеерамі
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Перамяшчацца паміж бацькоўскімі і ўкладзенымі канвеерамі раней было не вельмі зручна - трэба было мноства клікаў, каб дабрацца да патрэбнага канвеера. Таксама было нялёгка зразумець, якое менавіта заданне запусціла гэты канвеер. Цяпер убачыць сувязі паміж бацькоўскімі і ўкладзенымі канвеерамі стане значна прасцей.
и .
Раўналежныя матрычныя заданні паказваюць рэлевантныя зменныя ў назове задання
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Калі вы выкарыстоўвалі , вы маглі заўважыць, што было складана вызначыць, якая матрычная пераменная выкарыстоўвалася для пэўнага задання, бо назвы задання выглядалі як matrix 1/4. У рэлізе 13.4 вы будзеце бачыць рэлевантныя значэнні зменных, якія былі скарыстаны ў гэтым заданні, замест агульнай назвы задання. Напрыклад, калі ваша мэта - адладка для архітэктуры x86, то заданне будзе называцца matrix: debug x86.
и .
Іншыя паляпшэнні ў GitLab 13.4
Падключэнне акаўнта Atlassian
(CORE, STARTER, PREMIUM, ULTIMATE)
Карыстальнікі GitLab зараз змогуць падлучаць свае акаўнты GitLab да акаўнта Atlassian Cloud. Гэта дазволіць аўтарызавацца ў GitLab з уліковымі дадзенымі Atlassian, а таксама закладзе аснову для будучых паляпшэнняў у інтэграцыі. і з іншымі прадуктамі з лінейкі Atlassian.
и .
Экспарт спісу ўсіх коммітаў мержа
(ULTIMATE, GOLD)
Арганізацыям, накіраваным на выкананне патрабаванняў, патрэбен спосаб паказаць аўдытарам цэласнае прадстаўленне кампанентаў, звязаных з любой канкрэтнай зменай на прадакшэне. У рамках GitLab гэта азначае, што трэба сабраць у адным месцы ўсё: мерж-рэквесты, цікеты, канвееры, сканіравання бяспекі і іншыя дадзеныя аб коміце. Да гэтага часу вам даводзілася альбо ўручную збіраць гэта ў GitLab, альбо наладжваць свае прылады для збору інфармацыі, што было не вельмі эфектыўна.
Цяпер вы можаце праграмна збіраць і экспартаваць гэтыя дадзеныя для задавальнення патрабаванняў аўдыту або правядзення іншых аналізаў. Каб экспартаваць спіс усіх коммітаў мержа для бягучай групы, вам трэба перайсці да і клікнуць на кнопку Спіс усіх комітаў мержа. Атрыманы ў выніку файл будзе змяшчаць усе коміты мерж-рэквеста, іх аўтара, ID звязанага мерж-рэквеста, групу, праект, якія пацвярджаюць і іншую інфармацыю.
и .
Выснова спісу і кіраванне асабістымі токенамі доступу праз API
(ULTIMATE, GOLD)
Кіраванне доступам да прасторы імёнаў GitLab - гэта важная частка дзейнасці па выкананні патрабаванняў. Ад прынцыпаў мінімальных прывілеяў да адключэння доступу па таймеры – могуць быць некалькі патрабаванняў, злучаных з асабістымі токенамі доступу ў GitLab. Каб было зручней падтрымліваць і кіраваць усімі гэтымі ўліковымі дадзенымі карыстальнікаў у рамках вашай прасторы імёнаў, мы падалі магчымасць выводзіць спіс усіх асабістых токенаў доступу і апцыянальна праз API.
Гэтыя паляпшэнні ў API GitLab дазваляюць карыстачам выводзіць спіс і ануляваць свае ўласныя асабістыя токены доступу, а адміністратарам - выводзіць спіс і ануляваць токены сваіх карыстачоў. Цяпер адміністратарам будзе лягчэй бачыць тых, у каго ёсць доступ да іх прасторы імёнаў, прымаць рашэнні аб падаванні доступу на аснове дадзеных карыстачоў, а таксама ануляваць асабістыя токены доступу, якія маглі быць скампраметаваныя ці якія выходзяць за межы правіл кампаніі па кіраванні доступам.
и .
Змяненні, цікеты і іншыя фічы цяпер у GitLab Core
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Некалькі месяцаў таму мы абвясцілі план па . Працуючы над выкананнем гэтага абяцання, мы зрабілі , и (у рускай лакалізацыі GitLab "дошка абмеркаванняў") даступнымі ў плане Core. Гэта адносіцца толькі да адносін тыпу "звязаны з", адносіны тыпу "блакуе" і "блакуецца" застаюцца ў платных планах.
и .
Адлюстраванне імя зыходнай галінкі на бакавой панэлі мерж-рэквеста.
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Пры рэўю змен кода, абмеркаванняў і коммітаў мерж-рэквеста часцяком пажадана рабіць лакальны checkout галінкі для глыбейшага раўчу. Аднак знайсці імя галінкі становіцца ўсё складаней па меры таго, як да апісання мерж-рэквеста дадаецца больш кантэнту, і даводзіцца ўсё далей гартаць старонку.
Мы дадалі імя галінкі на бакавую панэль мерж-рэквеста, што робіць яго даступным у любы час і пазбаўляе ад неабходнасці прагортваць усю старонку. Як і спасылка на мерж-рэквест, раздзел з зыходнай галінкай змяшчае зручную кнопку "скапіяваць".
Дзякуй за вялізны ўклад у распрацоўку гэтай фічы!
и .
Указанне на наяўнасць згорнутых файлаў у дыффах мерж-рэквеста
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Мярж-рэквесты, якія дадаюць змены да некалькіх файлаў, часам згортваюць дыфы вялікіх файлаў, каб палепшыць прадукцыйнасць адлюстравання. Калі гэта адбываецца, можна выпадкова прапусціць файл пры рэўю, асабліва ў мерж-рэквестах з вялікім лікам файлаў. Пачынальна з версіі 13.4 мерж-рэквесты будуць адзначаць дыффы, утрымоўвальныя згорнутыя файлы, дзякуючы чаму вы не прапусціце гэтыя файлы падчас рэўю кода. Для яшчэ большай яснасці мы плануем дадаць падсвятленне гэтых файлаў у будучыні рэлізе. Сачыце за абнаўленнямі ў .
и .
Папярэджанне аб наяўнасці згорнутых файлаў у дыфе мерж-рэквеста
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
У раздзеле з дыфамі мерж-рэквестаў буйныя файлы згортваюцца для павышэння прадукцыйнасці. Аднак пры рэўю кода некаторыя файлы могуць быць прапушчаныя, калі рэўюер прагортвае спіс файлаў, бо ўсе буйныя файлы згорнутыя.
Мы дадалі бачнае папярэджанне наверсе старонкі дыфа мерж-рэквеста, каб інфармаваць карыстальнікаў аб тым, што ў гэтым раздзеле ёсць згорнуты файл. Такім чынам, вы не прапусціце ніякія змены ў мерж-рэквест пры рэўю.
и .
Аўтаматычнае аднаўленне рэпазітара кластара Gitaly
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Раней, калі першасная нода кластара Gitaly адключалася, рэпазітары на гэтай надзе адзначаліся як даступныя толькі для чытання. Гэта прадухіляла страту дадзеных у сітуацыях, калі на нодзе былі змены, якія яшчэ не рэпліцыраваліся. Калі нода зноў падключалася, GitLab не аднаўляўся аўтаматычна, і адміністратарам даводзілася ўручную запускаць працэс сінхранізацыі ці мірыцца са стратай дадзеных. Таксама маглі прыводзіць да з'яўлення састарэлых або даступных толькі для чытання рэпазітароў і іншыя сітуацыі, такія як няўдалае завяршэнне задання па рэплікацыі на другаснай нодзе. У гэтым выпадку рэпазітар заставаўся састарэлым да таго часу, пакуль не была праведзена наступная аперацыя запісу, якая б запусціла заданне па рэплікацыі.
Для вырашэння гэтай праблемы зараз плануе заданне па рэплікацыі, калі ён выяўляе састарэлы рэпазітар на адной нодзе і апошнюю версію рэпазітара на іншы. Гэтае заданне па рэплікацыі робіць рэпазітар актуальным аўтаматычна, што пазбаўляе ад неабходнасці аднаўляць дадзеныя ўручную. Аўтаматычнае аднаўленне таксама забяспечвае хуткае прывядзенне да актуальнага стану другасных нод, калі заданне па рэплікацыі завяршаецца няўдала, замест таго, каб чакаць наступнай аперацыі запісу. Так як многія кластары Gilaly захоўваюць вялікую колькасць рэпазітараў, гэта значна зніжае час, які адміністратары і інжынеры па забеспячэнні надзейнасці марнуюць на аднаўленне дадзеных пасля памылкі.
Акрамя таго, аўтаматычнае папраўка запускае рэплікацыю рэпазітароў на любой новай нодзе Gitaly, дабаўленай да кластара, што пазбаўляе ад ручной працы пры даданні новых нод.
и .
Адзначайце заданне to-do як выкананае на старонцы дызайну
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Эфектыўная камунікацыя ў GitLab заснавана на спісах заданняў to-do. Калі вас згадалі ў каментары, то крытычна важна мець магчымасць перайсці да задання і альбо пачаць нешта рабіць, альбо пазначыць яго як ужо выкананае. Таксама важна мець магчымасць прызначаць заданне сабе, калі вам трэба папрацаваць над нечым ці вярнуцца да гэтага пазней.
Раней вы не маглі дадаваць заданні ці пазначаць іх як выкананыя пры працы з дызайнамі. Гэта сур'ёзна парушала эфектыўнасць камунікацыі паміж прадуктовымі камандамі, бо заданні to-do – гэта крытычна важны элемент працоўнага працэсу ў GitLab.
У рэлізе 13.4/XNUMX дызайны даганяюць каментары да тикетам ў выкарыстанні заданняў, што робіць працу з імі больш паслядоўнай і эфектыўнай.
и .
Палепшанае кіраўніцтва па ўхіленні непаладак для CI/CD
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Мы палепшылі кіраўніцтва па ўхіленні непаладак для GitLab CI/CD, дадаўшы дадатковую інфармацыю пра распаўсюджаныя праблемы, з якімі вы можаце сутыкнуцца. Мы спадзяемся, што палепшаная дакументацыя будзе каштоўным рэсурсам, які дапаможа вам хутка і проста настройваць і запускаць GitLab CI/CD.
и .
Мерж-рэквесты больш не выпадаюць з чаргі мержа
(PREMIUM, ULTIMATE, SILVER, GOLD)
Раней мерж-рэквесты маглі выпасці з чаргі мержа выпадкова з-за позніх каментароў. Калі мерж-рэквест ужо знаходзіўся ў чарзе, і нехта дадаваў да яго каментар, які ствараў новае недазволенае абмеркаванне, мерж-рэквест лічыўся непрыдатным для мержа і выпадаў з чаргі. Цяпер, пасля таго, як мерж-рэквест дадаецца да чаргі мержа, новыя каментарыі можна дадаваць, не баючыся парушыць працэс мержа.
и .
Адлюстраванне ў мерж-рэквесце значэння пакрыцця кода для задання
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
У распрацоўнікаў павінна быць магчымасць бачыць значэнне пакрыцця кода пасля завяршэння канвеера - нават у складаных сцэнарах, такіх як праца канвеера з некалькімі заданнямі, якія трэба парсіць, каб разлічыць значэнне пакрыцця. Раней віджэт мерж-рэквеста паказваў толькі сярэдняе ад гэтых значэнняў, што азначала, што вам даводзілася пераходзіць на старонку задання і назад да мерж-рэквеста, каб атрымаць прамежкавыя значэнні пакрыцця. Каб зэканоміць ваш час і пазбавіць вас ад гэтых лішніх крокаў, мы зрабілі ў віджэце адлюстраванне сярэдняга значэння пакрыцця, яго змены паміж мэтавай і зыходнай галінкамі і ўсплывальную падказку, якая паказвае значэнне пакрыцця для кожнага задання, на аснове якога было разлічана сярэдняе значэнне.
и .
Выдаленне пакетаў з рэестра пакетаў пры праглядзе групы
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Рэестр пакетаў GitLab - гэта месца для захоўвання і распаўсюджвання пакетаў у розных фарматах. Калі ў вашым праекце ці групе шмат пакетаў, вам трэба хутка ідэнтыфікаваць невыкарыстоўваныя пакеты і выдаляць іх, каб людзі іх не спампоўвалі. Вы можаце выдаляць пакеты са свайго рэестра праз ці праз карыстацкі інтэрфейс рэестра пакетаў. Аднак да гэтага часу вы не маглі выдаляць пакеты пры праглядзе групы праз карыстацкі інтэрфейс. У выніку вам даводзілася выдаляць лішнія пакеты асобна для кожнага праекту, што было неэфектыўна.
Цяпер вы можаце выдаляць пакеты пры праглядзе рэестра пакетаў групы. Проста перайдзіце на старонку рэестра пакетаў групы, адфільтруйце пакеты па імені і выдаліце ўсе непатрэбныя.
и .
Маштабаванне пакетаў Conan да ўзроўню праекта
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Вы можаце выкарыстоўваць рэпазітар Conan у GitLab для публікацыі і распаўсюджванні залежнасцяў C/C++. Аднак раней пакеты можна было маштабаваць толькі да ўзроўня інстанса, бо назоў пакета Conan магла складацца максімум з 51 знака. Калі вы хацелі апублікаваць пакет з падгрупы, напрыклад gitlab-org/ci-cd/package-stage/feature-testing/conan, гэта было амаль немагчыма зрабіць.
Цяпер вы можаце маштабаваць пакеты Conan да ўзроўню праекта, што дазваляе лёгка публікаваць і распаўсюджваць залежнасці вашых праектаў.
и .
Падтрымка новых мэнэджэраў пакетаў і моў для сканавання залежнасцяў
(ULTIMATE, GOLD)
Мы рады дадаць сканавання залежнасцяў для праектаў з кодам на C, C++, C# і .Net, якія выкарыстоўваюць NuGet 4.9+ ці менеджэры пакетаў Conan, да нашага спісу . Цяпер вы можаце ўключаць сканіраванне залежнасцяў як частка стадыі Secure, каб правяраць на вядомыя ўразлівасці залежнасці, дададзеныя праз менеджэры пакетаў. Знойдзеныя ўразлівасці будуць адлюстроўвацца ў вашым мерж-рэквест разам з узроўнем іх небяспекі, каб вы ведалі да выканання мержа якія рызыкі нясе ў сабе новая залежнасць. Вы таксама можаце наладзіць свой праект так, каб ён патрабаваў для залежнасцяў з уразлівасцямі з крытычным (Critical), высокім (High) ці невядомым (Unknown) узроўнем небяспекі.
и .
Апавяшчэнні пры змене налады мерж-рэквеста на 'Мяржыць пры паспяховым завяршэнні канвеера'
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Раней пры заданні наладкі мерж-рэквеста Мяржыць, калі завершыцца канвеер (Merge When Pipeline Succeeds, MWPS) ніякага email-паведамлення не адпраўлялася. Вам даводзілася ўручную правяраць статус або чакаць апавяшчэння аб выкананні мержа. У гэтым рэлізе мы рады прадставіць фундуш карыстача , які вырашыў гэтую праблему, дадаўшы аўтаматычную адпраўку апавяшчэнняў усім, хто падпісаны на мерж-рэквест, калі рэўюер мяняе наладу мержа на MWPS.
и .
Стварэнне кластараў EKS з версіяй Kubernetes, зададзенай карыстачом
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Карыстальнікі GitLab зараз могуць самі выбіраць версію Kubernetes, якая будзе прадстаўлена EKS; вы можаце выбіраць паміж версіямі 1.14-1.17.
и .
Стварэнне інцыдэнтаў як тыпаў тыкетаў
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Не кожная якая ўзнікае праблема адразу запускае адпраўку абвестак: карыстачы паведамляюць аб збоях у працы, а чальцы каманд разбіраюцца ў праблемах з прадукцыйнасцю. Цяпер інцыдэнты з'яўляюцца разнавіднасцю цікета, так што вашыя каманды змогуць хутка ствараць іх у рамках звыклага працоўнага працэсу. Клікніце Новая задача з любога месца ў GitLab, і ў полі Тып выберыце інцыдэнт.
и .
Згадванне абвестак GitLab у Markdown
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Мы палепшылі абвесткі GitLab, дадаўшы новы тып згадкі спецыяльна для іх на GitLab-версіі Markdown, што дазваляе прасцей дзяліцца абвесткамі і згадваць іх. Выкарыстоўвайце ^alert#1234, Каб згадаць апавяшчэнне ў любым полі з разметкай Markdown: у інцыдэнтах, тикетах або мерж-рэквестах. Гэта таксама дапаможа вам вызначаць заданні, якія ствараюцца з абвестак, а не з тыкетаў ці мерж-рэквестаў.
и .
Прагляд нагрузкі абвестак па інцыдэнтах
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Апісанне абвесткі змяшчае інфармацыю, крытычна важную для дыягнаставання збояў і аднаўлення, і гэтая інфармацыя павінна быць лёгка даступнай, каб вам не даводзілася пераключаць інструменты або ўкладкі пры працы над дазволам інцыдэнту. Інцыдэнты, створаныя з абвестак, адлюстроўваюць поўнае апісанне абвесткі ва ўкладцы Дэталі абвесткі.
На 75% хутчэйшы пашыраны пошук
(STARTER, PREMIUM, ULTIMATE, BRONZE, SILVER, GOLD)
У GitLab, як адзінага прыкладання, ёсць унікальная магчымасць зрабіць пошук кантэнту па ўсім працоўным працэсе DevOps хуткім. У GitLab 13.4 пашыраны пошук выдае вынікі на 75% хутчэй, калі ён , як на GitLab.com.
и .
Прагляд выдаленых праектаў для адміністратараў
(CORE, STARTER, PREMIUM, ULTIMATE)
Магчымасць адкласці выдаленне праекта была . Аднак раней не было магчымасці ўбачыць у адным месцы ўсе праекты, якія чакаюць выдалення. Цяпер адміністратары карыстацкіх інстансаў GitLab могуць праглядаць усе праекты, якія чакаюць выдалення, у адным месцы – разам з кнопкамі для лёгкага аднаўлення гэтых праектаў.
Гэтая магчымасць дазваляе адміністратарам лепш кантраляваць выдаленне праектаў, збіраючы ўсю неабходную інфармацыю ў адным месцы і падаючы магчымасць адмяніць непажаданыя дзеянні па выдаленні.
Дзякуй за гэтую фічу!
и .
У API дададзена падтрымка правілаў пуша для групы
(STARTER, PREMIUM, ULTIMATE, BRONZE, SILVER, GOLD)
Раней групавыя правілы пуша можна было наладзіць толькі наведваючы кожную групу індывідуальна праз карыстацкі інтэрфейс GitLab і ужываючы гэтыя правілы. Цяпер вы можаце кіраваць гэтымі правіламі праз API для падтрымкі вашых карыстацкіх інструментаў і аўтаматызацыі GitLab.
и .
Водгук асабістых токенаў доступу для самакіравальнай сховішчы уліковых дадзеных
(ULTIMATE)
дае адміністратарам інфармацыю, неабходную для кіравання ўліковымі дадзенымі карыстальнікаў іх інстансу GitLab. Паколькі арганізацыі, арыентаваныя на выкананне патрабаванняў, адрозніваюцца па строгасці сваіх правіл кіравання ўліковымі дадзенымі, мы дадалі кнопку, якая дазваляе адміністратарам пры жаданні адклікаць токен асабістага доступу карыстальніка (PAT). Цяпер адміністратары могуць лёгка адклікаць патэнцыйна скампраметаваныя PAT. Гэтая фіча карысная для арганізацый, якім патрэбныя больш гнуткія варыянты для забеспячэння выканання патрабаванняў, каб звесці да мінімуму адцягнення сваіх карыстальнікаў.
и .
Файл канфігурацыі для рэдактара статычных сайтаў
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
У GitLab 13.4/XNUMX мы прадстаўляем новы спосаб налады рэдактара статычных сайтаў. Хоць канфігурацыйны файл не захоўвае і не атрымлівае ніякіх параметраў у гэтым рэлізе, мы закладваем аснову для будучай налады паводзін рэдактара. У наступных рэлізах мы дадамо ў файл .gitlab/static-site-editor.yml параметры для ўстаноўкі , На якім , пераазначэнне налад сінтаксісу Markdown і іншых налад рэдактара.
и .
Рэдагаванне ўступнай часткі файла з дапамогай рэдактара статычных сайтаў
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Уступная частка (front matter) - гэта гнуткі і зручны спосаб вызначэння зменных старонкі ў файлах дадзеных, прызначаных для апрацоўкі генератарам статычных сайтаў. Звычайна яна выкарыстоўваецца для ўсталёўкі загалоўка старонкі, шаблону макета ці аўтара, але можа выкарыстоўвацца для перадачы любога тыпу метададзеных у генератар пры рэндэры старонкі ў HTML. Уключаная ў самы верх кожнага файла дадзеных, уступная частка звычайна фарматуецца як YAML ці JSON і патрабуе ўзгодненага і дакладнага сінтаксісу. Карыстальнікі, незнаёмыя з пэўнымі правіламі сінтаксісу, могуць ненаўмысна ўвесці недапушчальную разметку, што, у сваю чаргу, можа выклікаць праблемы з фарматаваннем ці нават збоі зборкі.
Рэжым рэдагавання WYSIWYG рэдактара статычных сайтаў ужо прыбірае ўступную частку з рэдактара, каб прадухіліць гэтыя памылкі фарматавання. Аднак гэта не дае вам змяніць значэння, якія захоўваюцца ў гэтай частцы, без вяртання да рэдагавання ў рэжыме зыходнага кода. У GitLab 13.4 вы можаце атрымаць доступ да любога поля і рэдагаваць яго значэнне ў знаёмым інтэрфейсе на аснове формаў. Пры націску кнопкі Налады (налады) адкрыецца панэль, на якой адлюстроўваецца поле формы для кожнага ключа, вызначанага ў пачатку. Палі запаўняюцца бягучым значэннем, і для рэдагавання любога з іх дастаткова проста ўвесці яго ў вэб-форме. Такое рэдагаванне ўступнай часткі дазваляе пазбегнуць складанасцяў у сінтаксісе і дае вам поўны кантроль над зместам, забяспечваючы пры гэтым аднастайнае фарматаванне канчатковага выніку.
и .
GitLab для Jira і DVCS Connector зараз у Core
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Для карыстальнікаў Jira у GitLab: и дазваляюць адлюстроўваць інфармацыю аб комітах і мерж-рэквестах GitLab непасрэдна ў Jira. У спалучэнні з нашай убудаванай інтэграцыяй з Jira вы можаце лёгка перамяшчацца паміж двума праграмамі падчас працы.
Гэтыя функцыі раней былі даступныя толькі ў нашым плане Premium, а зараз яны даступныя ўсім карыстачам!
и .
Галасаванне з большасцю галасоў для транзакцый кластара Gitaly (бэта-версія)
(CORE, STARTER, PREMIUM, ULTIMATE)
Кластар Gitaly дазваляе рэплікаваць рэпазітары Git на некалькі "цёплых" нод Gitaly. Гэта павялічвае адмоваўстойлівасць за кошт ухілення адзінкавых кропак адмовы. , прадстаўленыя ў GitLab 13.3, выклікаюць шырокавяшчальную перадачу змен на ўсе ноды Gitaly у кластары, але толькі ноды Gitaly, якія галасуюць па ўзгадненні з першаснай нодай, захоўваюць змены на дыск. Калі ўсе ноды-рэплікі не прыйшлі да згоды, толькі адна копія змены будзе захавана на дыску, ствараючы адзіную кропку адмовы да завяршэння асінхроннай рэплікацыі.
Галасаванне з большасцю галасоў павялічвае адмоваўстойлівасць, патрабуючы згоды большасці нод (а не ўсіх) перад захаваннем зменаў на дыску. Калі гэтая якая пераключаецца фіча ўключаная, запіс павінна будзе выканацца паспяхова на некалькіх нодах. Нязгодныя ноды аўтаматычна сінхранізуюцца з дапамогай асінхроннай рэплікацыі з тых нод, што ўтварылі кворум.
и .
Падтрымка карыстацкай схемы для валідацыі JSON у Web IDE
(PREMIUM, ULTIMATE, SILVER, GOLD)
Праекты, дзе людзі пішуць канфігурацыі ў фармаце JSON ці YAML, часта схільныя праблемам, таму што лёгка зрабіць памылку друку і нешта зламаць. Можна напісаць прылады праверкі, якія адлоўліваюць гэтыя праблемы ў канвееры CI, але выкарыстаць файл схемы JSON можа быць карысна, каб падаваць дакументацыю і падказкі.
Удзельнікі праекту могуць вызначыць у іх рэпазітары шлях да карыстацкай схемы ў файле. .gitlab/.gitlab-webide.yml, Які паказвае схему і шлях да файлаў для праверкі. Пры загрузцы вызначанага файла ў Web IDE будзе бачная дадатковая зваротная сувязь і праверка, якія дапамогуць стварыць файл.
и .
Мяжа галінавання накіраванага ацыклічнага графа (DAG) павялічаны да 50
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Калі вы карыстаецеся канвееры (Directed Acyclic Graph (DAG)), вы маглі выявіць, што абмежаванне ў 10 заданняў, якія заданне можа паказаць у needs:, занадта сурова. У 13.4/10 мяжа па змаўчанні быў павялічаны з 50 да XNUMX, каб забяспечыць больш складаныя сеткі ўзаемасувязяў паміж заданнямі ў вашых канвеерах.
Калі вы адміністратар карыстацкага інстанса GitLab, тыя вы можаце падняць гэтую мяжу яшчэ вышэй, наладзіўшы пераключаемую фічу, хоць мы не прапануем афіцыйную падтрымку для гэтага.
и .
Палепшаны паводзіны needs для прапушчаных заданняў
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
У некаторых выпадках прапушчанае заданне ў канвееры магло памылкова лічыцца паспяховым для залежнасцяў, указаных у needs, з-за чаго запускаліся наступныя заданні, чаго адбывацца не павінна было. Гэтыя паводзіны выпраўленыя ў версіі 13.4, і needs зараз карэктна апрацоўвае выпадкі прапушчаных заданняў.
и .
Замацуеце апошні артэфакт задання, каб прадухіліць яго выдаленне
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
GitLab зараз аўтаматычна блакуе апошні артэфакт паспяховага задання і канвеера на любой актыўнай галінцы, мерж-рэквесце або тэгу, каб прадухіліць яго выдаленне пасля заканчэння тэрміну дзеяння. Становіцца прасцей усталёўваць больш агрэсіўныя правілы тэрміна дзеяння для ачысткі старых артэфактаў. Гэта дапамагае зменшыць спажыванне дыскавай прасторы і гарантуе, што ў вас заўсёды будзе копія апошняга артэфакта з канвеера.
и .
Кіраўніцтва для CI/CD па аптымізацыі канвеера
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Аптымізацыя працы канвеера CI/CD можа павысіць хуткасць пастаўкі і зэканоміць грошы. Мы палепшылі нашу дакументацыю, дадаўшы кароткае кіраўніцтва па дасягненні максімальнай аддачы ад аптымізацыі вашых канвеераў.
и .
Справаздача аб тэсціраванні адсартавана па статусе тэсту
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
- гэта просты спосаб убачыць вынікі ўсіх тэстаў у канвееры. Аднак пры вялікай колькасці тэстаў пошук няўдалых тэстаў можа заняць шмат часу. Іншыя праблемы, з-за якіх можа быць складана выкарыстоўваць справаздачу, уключаюць цяжкасці з пракруткай доўгіх выходных дадзеных трасіроўкі і акругленне часу да нуля для тэстаў, якія выконваюцца менш чым за 1 секунду. Зараз па змаўчанні справаздачу аб тэсціраванні пры сартаванні спачатку змяшчае няўдалыя тэсты ў пачатак справаздачы, а потым сартуе тэсты па працягласці. Гэта спрашчае пошук збояў і працяглых тэстаў. Акрамя таго, працягласць тэстаў зараз адлюстроўваецца ў мілісекундах ці секундах, таму чытаць іх стала нашмат хутчэй, і таксама былі вырашаны папярэднія праблемы з пракруткай.
и .
Абмежаванні на памер файлаў, якія загружаюцца ў рэестр пакетаў
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Цяпер ёсць абмежаванні на памер файлаў пакетаў, якія можна загружаць у рэестр пакетаў GitLab. Абмежаванні былі дададзены для аптымізацыі прадукцыйнасці рэестра пакетаў і прадухілення злоўжыванняў. Абмежаванні залежаць ад фармату пакета. Для GitLab.com максімальныя памеры файлаў:
- Conan: 250MB
- Maven: 3GB
- NPM: 300MB
- NuGet: 250MB
- PyPI: 3GB
Для карыстацкіх інстансаў GitLab значэння па змаўчанні такія ж. Аднак адміністратар можа абнавіць абмежаванні з дапамогай .
и .
Выкарыстоўвайце CI_JOB_TOKEN для публікацыі пакетаў PyPI
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Вы можаце выкарыстоўваць рэпазітар GitLab PyPI для стварэння, публікацыі і сумеснага выкарыстання пакетаў Python разам з зыходным кодам і канвеерамі CI/CD. Аднак раней вы не маглі прайсці аўтэнтыфікацыю ў рэпазітары з дапамогай папярэдне вызначанай зменнай асяроддзя CI_JOB_TOKEN. У выніку вам даводзілася выкарыстоўваць свае асабістыя ўліковыя дадзеныя для абнаўлення рэпазітара PyPI, ці вы, магчыма, вырашалі наогул не выкарыстоўваць рэпазітар.
Цяпер стала прасцей выкарыстоўваць GitLab CI/CD для публікацыі і ўстаноўкі пакетаў PyPI з дапамогай наканаванага зменнага асяроддзя CI_JOB_TOKEN.
и .
Профілі сканара DAST па запыце
(ULTIMATE, GOLD)
Да сканаванні DAST па запыце, якое было , дадаліся профілі сканара DAST. Яны пашыраюць магчымасці канфігурацыі гэтага сканавання, дазваляючы хутка ствараць некалькі профіляў для ахопу некалькіх тыпаў сканавання. У 13.4/200 профіль сканара першапачаткова ўключае параметр тайм-аўту пошукавага робата, які ўсталёўвае, як доўга павінен працаваць пошукавы робат DAST, калі ён спрабуе выявіць усе старонкі сканаванага сайта. Профіль таксама ўключае параметр тайм-аўту мэтавага сайта, каб усталяваць, як доўга сканер павінен чакаць, пакуль сайт стане даступным, перш чым перапыніць сканаванне, калі сайт не адказвае кодам стану 300 ці XNUMX. Па меры таго, як мы будзем зноў і зноў паляпшаць гэтую фічу ў наступных рэлізах, у профіль сканара будуць дададзены дадатковыя параметры канфігурацыі.
и .
Просты файл канфігурацыі рэдырэктаў для GitLab Pages
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Калі вы выкарыстоўваеце GitLab Pages і жадаеце лепш кіраваць зменамі URL, тыя вы маглі заўважыць, што кіраваць рэдырэктамі на сваім сайце GitLab Pages было немагчыма. GitLab зараз дазваляе вам наладжваць правілы для перанакіравання аднаго URL на іншы для вашага сайта Pages, дадаўшы файл канфігурацыі ў рэпазітар. Гэтая функцыя стала магчымай дзякуючы ўдзелу Kevin Barnett (), нашага Eric Eastwood () і каманды GitLab. Дзякуй усім за ваш уклад.
и .
Стан Terraform, кіраваны GitLab
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Доступ да папярэдніх версій стану Terraform неабходзен як для адпаведнасці патрабаванням, так і для адладкі пры неабходнасці. Падтрымка кіравання версіямі стану Terraform, кіраванага GitLab, падаецца пачынальна з GitLab 13.4. Кіраванне версіямі ўключаецца аўтаматычна для новых файлаў стану Terraform. Існуючыя файлы стану Terraform будуць у пазнейшым рэлізе.
и .
Важныя дэталі абвесткі аб інцыдэнтах
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Пры апрацоўцы інцыдэнтаў вам трэба лёгка вызначаць, як доўга папярэджанне было адчынена і колькі разоў спрацоўвала падзея. Гэтыя дэталі часта маюць вырашальнае значэнне пры вызначэнні ўплыву на кліента і таго, чым ваша каманда павінна заняцца ў першую чаргу. На новай панэлі падрабязнасцяў інцыдэнтаў мы адлюстроўваем час пачатку абвесткі, колькасць падзей і спасылку на зыходнае абвестка. Гэтая інфармацыя даступная па інцыдэнтах, якія ствараюцца з абвестак.
и .
Устаноўка і рэдагаванне параметра сур'ёзнасці інцыдэнту
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Параметр "сур'ёзнасць інцыдэнту" дазваляе спецыялістам па рэагаванні і зацікаўленым бакам вызначаць наступствы перабою ў працы, а таксама метады і тэрміновасць рэагавання. Па меры таго як ваша каманда дзеліцца вынікамі падчас ухілення інцыдэнту і аднаўляе працаздольнасць, яны могуць змяняць гэты параметр. Цяпер вы можаце рэдагаваць сур'ёзнасць інцыдэнту на правай бакавой панэлі старонкі "Звесткі аб інцыдэнце", а ступень сур'ёзнасці адлюстроўваецца ў спісе інцыдэнтаў.
и .
Стварэнне, рэдагаванне і выдаленне правіл сеткавай бяспекі кантэйнераў
(ULTIMATE, GOLD)
Гэтае паляпшэнне рэдактара правіл сеткавай бяспекі кантэйнераў дазваляе карыстачам лёгка ствараць, рэдагаваць і выдаляць свае правілы прама з карыстацкага інтэрфейсу GitLab. Магчымасці рэдактара ўключаюць рэжым .yaml для вопытных карыстальнікаў і рэдактар правілаў з інтуітыўна зразумелым інтэрфейсам для тых, хто дрэнна знаёмы з сеткавымі правіламі. Вы можаце знайсці новыя магчымасці кіравання правіламі ў раздзеле Бяспека і адпаведнасць > Упраўленне пагрозамі > Правілы (Security & Compliance > Threat Management > Policies).
и .
Падтрымка сховішча blob-аб'ектаў Azure
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
І GitLab, і GitLab Runner зараз падтрымліваюць , што спрашчае запуск службаў GitLab у Azure.
Інстансы GitLab падтрымліваюць Azure для ўсіх тыпаў сховішчаў аб'ектаў, у тым ліку файлы LFS, артэфакты CI і . Каб наладзіць сховішча blob-аб'ектаў Azure, прытрымлівайцеся інструкцыям па ўсталёўцы або .
Апрацоўшчыкі заданняў GitLab таксама падтрымліваюць Azure для захоўвання . Сховішча Azure можна наладзіць з дапамогай часткі .
и .
Пакеты Omnibus ARM64 для Ubuntu і OpenSUSE
(CORE, STARTER, PREMIUM, ULTIMATE)
У адказ на які расце попыт на падтрымку запуску GitLab для 64-бітнай архітэктуры ARM, мы рады абвясціць аб даступнасці афіцыйнага пакета ARM64 Ubuntu 20.04/XNUMX Omnibus. Вялікі дзякуй Zitai Chen і Guillaume Gardet за велізарны фундуш, які яны ўнеслі — іх мерж-рэквесты згулялі ў гэтым ключавую ролю!
Каб спампаваць і ўсталяваць пакет для Ubuntu 20.04/XNUMX, перайдзіце на нашу і абярыце Ubuntu.
и .
Падтрымка аўтэнтыфікацыі з дапамогай смарт-карт для GitLab Helm chart
(PREMIUM, ULTIMATE)
Смарт-карты, напрыклад карты агульнага доступу (CAC), зараз можна выкарыстоўваць для аўтэнтыфікацыі ў інстансе GitLab, разгорнутым праз Helm chart. Смарт-карты аўтэнтыфікуюцца ў лакальнай базе даных з дапамогай сертыфікатаў X.509. Дзякуючы гэтаму падтрымка смарт-карт з Helm chart зараз знаходзіцца ў адпаведнасці з падтрымкай смарт-карт, даступнай у разгортваннях Omnibus.
и .
Падрабязныя release notes і інструкцыі па абнаўленні/усталёўцы можна прачытаць у арыгінальным англамоўным пасце: .
Над перакладам з ангельскай працавалі , , и .
Крыніца: habr.com