GitLab 11.10 з пайплайнамі на панэлі кіравання, пайплайнамі для аб'яднаных вынікаў і прапановамі па некалькіх радках у мердж-рэквестах.
Зручныя звесткі аб працаздольнасці пайплайнаў у розных праектах.
GitLab працягвае павялічваць празрыстасць жыццёвага цыклу DevOps. У гэтым выпуску на дададзены агляд статусу пайплайнаў.
Гэта зручна, нават калі вы вывучаеце пайплайн аднаго праекта, але асабліва карысна, калі , — а так звычайна і бывае, калі вы выкарыстоўваеце мікрасэрвісы і жадаеце запусціць пайплайн для тэставання і пастаўкі кода з розных рэпазітараў праектаў. Цяпер вы адразу бачыце працаздольнасць , дзе б яны ні выконваліся.
Запуск пайплайнаў для аб'яднаных вынікаў
З часам зыходная і мэтавая галінкі разыходзяцца, і можа ўзнікнуць сітуацыя, калі па асобнасці яны спраўляюцца, а разам не працуюць. Цяпер можна . Дык вы хутка заўважыце памылкі, якія выявіліся б толькі пры частым перасоўванні змен паміж галінкамі, а значыць значна хутчэй выправіце памылкі пайплайна і будзеце эфектыўней выкарыстаць .
Далейшая аптымізацыя сумеснай працы
У GitLab 11.10/XNUMX з'явілася яшчэ больш магчымасцяў для зручнай сумеснай працы і спрошчаных працоўных працэсаў. У мы ўвялі прапановы па мердж-рэквестах, калі рэцэнзент мог прапанаваць змену аднаго радка ў каментары да мердж-рэквеста, і яго можна было адразу закаміціць прама з трэда каментароў. Нашым карыстальнікам гэта спадабалася, і яны папрасілі пашырыць гэтую фічу. Цяпер вы можаце прапаноўваць , паказваючы, якія радкі выдаліць, а якія - дадаць.
Дзякуй за вашыя водгукі і прапановы!
І гэта яшчэ не ўсё…
У гэтым выпуску столькі ўзрушаючых фіч, напрыклад, , больш дбайная , і магчымасць . Ніжэй падрабязнасці аб кожнай з іх.
Самы каштоўны супрацоўнік гэтага месяца () - Такуя Нагуці
У гэтым месяцы самым каштоўным супрацоўнікам стаў Такуя Нагуці (). Такая : выпраўляў багі, дарабляў недапрацоўкі ў бэкендзе і франтэндзе і паляпшаў карыстацкі інтэрфейс. Дзякуй!
Галоўныя фічы GitLab 11.10
Пайплайны на панэлі кіравання
PREMIUM, ULTIMATE, SILVER, GOLD
На панэлі кіравання ў GitLab адлюстроўваюцца звесткі аб праектах на ўсім асобніку GitLab. Вы дадаеце асобныя праекты па адным і можаце выбіраць, які праект вас цікавіць.
У гэтым выпуску мы дадалі на панэль кіравання інфармацыю аб статусах пайплайнаў. Зараз распрацоўшчыкі бачаць працаздольнасць пайплайнаў ва ўсіх патрэбных праектах – у адным інтэрфейсе.
Пайплайны для аб'яднаных вынікаў
PREMIUM, ULTIMATE, SILVER, GOLD
Звычайна з часам зыходная галінка адхіляецца ад мэтавай, калі вы ўвесь час не перасоўваеце паміж імі змены. У выніку пайплайны зыходнай і мэтавай галінак "зялёныя" і канфліктаў мерджа не ўзнікае, але пры аб'яднанні адбываецца збой з-за несумяшчальнасці змен.
Калі пайплайн мердж-рэквестаў аўтаматычна стварае новую спасылку, якая змяшчае аб'яднаны вынік мерджа зыходнай і мэтавай галінак, мы можам запусціць пайплайн па гэтай спасылцы і гарантаваць, што агульны вынік будзе працоўным.
Калі вы выкарыстоўваеце пайплайны мердж-рэквестаў (у любой якасці) і задзейнічаеце прыватныя GitLab-раннеры версіі 11.8/XNUMX або старэй, іх трэба абнавіць, каб не ўзнікла праблема . Гэта не ўплывае на карыстачоў агульнадаступных GitLab-ранэраў.
Прапанова змен у некалькіх радках
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Пры сумеснай працы над мердж-рэквестамі вы часта заўважаеце праблемы і прапануеце рашэнні. З версіі GitLab 11.6 мы падтрымліваем для аднаго радка.
У версіі 11.10 у каментарах да дыфу мердж-рэквеста можна прапаноўваць змены для некалькіх радкоў, а потым любы карыстач з дазволамі на запіс у зыходную галінку можа прыняць іх адным націскам. Дзякуючы новай фічы можна пазбегнуць капіпасты, як у папярэдніх версіях.
Цэтлікі ў адной вобласці
PREMIUM, ULTIMATE, SILVER, GOLD
З цэтлікамі ў адной вобласці каманды могуць ужываць узаемавыключальныя цэтлікі (у адной і той жа вобласці) для задачы, мердж-рэквеста ці эпіка ў сцэнарах з кастамнымі палямі ці кастамнымі станамі працоўнага працэсу. Яны настройваюцца з дапамогай спецыяльнага сінтаксісу з двукроп'ем у загалоўку ярлыка.
Дапусцім, вам трэба кастамнае поле ў задачах, каб адсочваць аперацыйную сістэму платформы, на якую нацэлены вашыя функцыі. Кожная задача павінна ставіцца толькі да адной платформы. Можна ствараць цэтлікі platform::iOS, platform::Android, platform::Linux і іншыя па неабходнасці. Калі прымяніць адзін такі ярлык да задачы, аўтаматычна выдаліцца іншы існуючы ярлык, які пачынаецца з platform::.
Дапушчальны, у вас ёсць цэтлікі workflow::development, workflow::review и workflow::deployed, якія абазначаюць стан працоўнага працэсу ў вашай камандзе. Калі ў задачы ўжо ёсць ярлык workflow::development, а распрацоўшчык хоча перавесці задачу на стадыю workflow::review, ён проста ўжывае новы ярлык, а стары (workflow::development) аўтаматычна выдаляецца. Гэтыя паводзіны ўжо існуе, калі вы перасоўвае задачы паміж спісамі цэтлікаў на дошцы задач, якая прадстаўляе працоўны працэс вашай каманды. Цяпер чальцы каманды, якія не працуюць з дошкай задач напроста, могуць змяніць стан працоўнага працэсу ў саміх задачах.
Больш дбайная ачыстка рэестра кантэйнераў
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Пры звычайным выкарыстанні рэестра кантэйнераў з CI-пайплайнамі вы адпраўляеце некалькі асобных змен у адзін тэг. З-за рэалізацыі размеркавання Docker паводзіны па змаўчанні - захаваць усе змены ў сістэме, але ў выніку яны займаюць шмат памяці. Калі выкарыстоўваць параметр -m с registry-garbage-collect, можна хутка выдаліць усе папярэднія змены і вызваліць каштоўнае месца.
Купля дадатковых хвілін CI Runner
БРОНЗА, СЕРАБРА, ЗОЛАТА
Карыстальнікі з платнымі планамі GitLab.com (Gold, Silver, Bronze) зараз могуць купляць дадатковыя хвіліны CI Runner. Раней трэба было ўкладвацца ў квоту, прадугледжаную планам. Дзякуючы гэтаму паляпшэнню можна загадзя купляць хвіліны звыш квоты, каб пазбегнуць перапынкаў у працы з-за прыпынку пайплайнаў.
Цяпер 1000 хвілін каштуюць 8 долараў, і купляць іх можна колькі заўгодна. Дадатковыя хвіліны пачнуць расходавацца, калі вы патраціце ўсю месячную квоту, а астатак дадатковых хвілін пераносіцца на наступны месяц. У мы хочам дадаць гэтую фічу і ў бясплатныя планы.
Кампануемы Auto DevOps
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
З Auto DevOps каманды пераходзяць на сучасныя практыкі DevOps амаль без намаганняў. Пачынаючы з GitLab 11.10/XNUMX кожны джоб у Auto DevOps прадастаўляецца ў выглядзе . Карыстальнікі могуць выкарыстоўваць у GitLab CI, каб уключаць асобныя стадыі Auto DevOps і пры гэтым выкарыстоўваць свой кастамны файл gitlab-ci.yml. Такім чынам можна ўключаць толькі патрэбныя джобы і карыстацца перавагамі абнаўленняў у upstream.
Аўтаматычнае кіраванне чальцамі групы на GitLab.com з дапамогай SCIM
СРЭБА, ЗАЛАТЫ
Раней кіраваць сяброўствам у групах на GitLab.com прыходзілася ўручную. Цяпер можна выкарыстоўваць SAML SSO і кіраваць сяброўствам з дапамогай SCIM, каб ствараць, выдаляць і абнаўляць карыстальнікаў на GitLab.com.
Гэта асабліва карысна для кампаній з вялікай колькасцю карыстальнікаў і цэнтралізаванымі пастаўшчыкамі пасведчанняў. Цяпер у вас можа быць адзіная крыніца ісціны, напрыклад Azure Active Directory, і карыстачы будуць стварацца і выдаляцца аўтаматычна праз пастаўшчыка пасведчанняў, а не ўручную.
Уваход на GitLab.com праз пастаўшчыка SAML
СРЭБА, ЗАЛАТЫ
Раней пры выкарыстанні SAML SSO для груп карыстач павінен быў уваходзіць з уліковымі дадзенымі GitLab і пастаўшчыком пасведчанняў. Зараз можна напроста ўваходзіць праз SSO як карыстач GitLab, прывязаны да наладжанай групы.
Карыстачам не давядзецца двойчы выконваць уваход, таму кампаніям зручней выкарыстоўваць SAML SSO для GitLab.com.
Іншыя паляпшэнні ў GitLab 11.10
Схема даччыных эпікаў
ULTIMATE, GOLD
У папярэднім выпуску мы дадалі даччыныя эпікі (эпікі эпікі), каб вам было зручней кіраваць структурай размеркавання заданняў. Даччыныя эпікі адлюстроўваюцца на старонцы бацькоўскага эпіка.
У гэтым выпуску на старонцы бацькоўскага эпіка адлюстроўваецца схема даччыных эпікаў, таму каманды бачаць храналогію даччыных эпікаў і могуць кіраваць часовымі залежнасцямі.
Усплывальныя экраны мердж-рэквестаў
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
У гэтым выпуску мы прадстаўляем інфарматыўныя экраны, якія ўсплываюць пры навядзенні курсора на спасылку мердж-рэквеста. Раней мы паказвалі толькі загаловак мердж-рэквеста, а зараз яшчэ і статут мердж-рэквеста, статут CI-пайплайна і кароткі URL.
У будучых выпусках мы плануем дадаць больш важных звестак, напрыклад, , а яшчэ ўвядзем усплывальныя экраны для .
Фільтраванне мэрдж-рэквестаў па мэтавым галінкам
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Працоўныя працэсы Git для выпуску ці пастаўкі ПА часта злучаны з некалькімі доўгатэрміновымі галінкамі — для занясення выпраўленняў у папярэднія версіі (напрыклад, stable-11-9) або пераходу ад праверкі якасці да вытворчасці (напрыклад, integration), але не так-то проста знайсці мердж-рэквесты для гэтых галінак сярод мноства адкрытых мердж-рэквестаў.
Спіс мердж-рэквестаў для праектаў і груп зараз можна фільтраваць па мэтавай галінцы мердж-рэквеста, каб было прасцей знаходзіць патрэбны.
Дзякуй, Хироюки Сато ()!
Адпраўка і мердж пры паспяховым пайплайне
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Калі мы выкарыстоўваем метад распрацоўкі Trunk-based development, мы павінны пазбягаць доўгажывучых галінак на карысць невялікіх часавых галінак з адным уладальнікам. Дробныя змены часта адпраўляюцца прама ў мэтавую галінку, але пры гэтым мы рызыкуем парушыць зборку.
У гэтым выпуску GitLab падтрымлівае новыя параметры адпраўкі ў Git, каб аўтаматычна адчыняць мердж-рэквесты, задаваць мэтавую галінку і забяспечыць мердж пры паспяховым пайплайне з камандай радка падчас адпраўкі ў галінку.
Палепшаная інтэграцыя з вонкавымі панэлямі маніторынгу
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
GitLab можа звяртацца да некалькіх сервераў Prometheus (на ўзроўні асяроддзя, праекту і ), але наяўнасць некалькіх канчатковых кропак можа ўскладняць сістэму або не падтрымлівацца стандартнымі панэлямі маніторынгу. У гэтым выпуску каманды могуць выкарыстоўваць адзін API Prometheus, што значна спрашчае інтэграцыю з такімі сервісамі, як Grafana.
Сартаванне Wiki-старонак па даце стварэння
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
У Wiki праекты каманды могуць дзяліцца дакументацыяй і іншай важнай інфармацыяй нараўне з зыходным кодам і задачамі. У гэтым выпуску спіс старонак у Wiki можна сартаваць па даце стварэння і загалоўку, каб хутка знаходзіць нядаўна створанае змесціва.
Маніторынг рэсурсаў, запытаных кластарам
ULTIMATE, GOLD
GitLab дапамагае маніторыць кластар Kubernetes для распрацоўваных і працоўных прыкладанняў. Пачынаючы з гэтага выпуску адсочвайце запытаныя кластарам рэсурсы працэсара і памяць, каб заўважыць патэнцыйныя складанасці, пакуль яны не сталі праблемамі.
Прагляд метрык балансавальніка нагрузкі на панэлі маніторынгу Grafana
CORE, STARTER, PREMIUM, ULTIMATE
Вельмі важна сачыць за працаздольнасцю асобніка GitLab. Раней мы давалі панэлі маніторынгу па змаўчанні праз убудаваны асобнік Grafana. Пачынальна з гэтага выпуску мы ўлучылі дадатковыя панэлі для маніторынгу балансавальнікаў нагрузкі NGINX.
SAST для Elixir
ULTIMATE, GOLD
Мы працягваем пашыраць падтрымку моў і паглыбляць праверкі бяспекі. У гэтым выпуску мы ўключылі праверкі бяспекі для праектаў на і праектаў, створаных на .
Некалькі запытаў у адной дыяграме
PREMIUM, ULTIMATE, SILVER, GOLD
У GitLab можна ствараць дыяграмы, каб візуалізаваць збіраныя метрыкі. Часта - напрыклад, калі трэба паглядзець максімальнае або сярэдняе значэнне метрыкі, - хочацца вывесці некалькі значэнняў на адной дыяграме. Пачынаючы з гэтага выпуску, у вас ёсць такая магчымасць.
Вынікі DAST на панэлі бяспекі групы
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Мы дадалі вынікі дынамічнага тэсціравання абароненасці прыкладанняў (Dynamic Application Security Testing, DAST) на панэль бяспекі групы ў дадатак да SAST, сканаванні кантэйнераў і сканаванню залежнасцяў.
Даданне метададзеных у справаздачу аб сканаванні кантэйнераў
ULTIMATE, GOLD
У гэтым выпуску ў справаздачы аб сканаванні кантэйнераў змяшчаецца больш метададзеных - мы дадалі які закранаецца кампанент (фіча Clair) у існуючыя метададзеныя: прыярытэт, ідэнтыфікатар (са спасылкай на mitre.org) і закранаемы ўзровень (напрыклад, debian:8).
Даданне тыпу справаздачы па метрыках у мердж-рэквесты
PREMIUM, ULTIMATE, SILVER, GOLD
GitLab ужо дае некалькі тыпаў справаздач, якія можна ўключаць прама ў мердж-рэквесты: ад справаздач аб и на этапе праверкі да и на этапе абароны.
І хаця гэта важныя справаздачы, базавыя звесткі, прыдатныя для розных сцэнарыяў, таксама патрэбныя. У GitLab 11.10/XNUMX мы даем справаздачы па метрыках прама ў мердж-рэквесце, які чакае простую пару ключ-значэнне. Такім чынам карыстачы адсочваюць змены ў часе, уключаючы карыстацкія метрыкі, і змены метрык для вызначанага мердж-рэквеста. Выкарыстанне памяці, тэставанне спецыялізаваных нагрузак і статуты працаздольнасці можна пераўтварыць у простыя метрыкі, якія можна праглядаць прама ў мердж-рэквестах нараўне з іншымі ўбудаванымі справаздачамі.
Падтрымка мультымодульных праектаў Maven для сканавання залежнасцяў
ULTIMATE, GOLD
У гэтым выпуску мультымодульныя праекты Maven падтрымліваюць сканіраванне залежнасцяў GitLab. Раней, калі ў падмодуля была залежнасць ад іншага падмодуля таго ж узроўня, ён не мог дазволіць загрузку з цэнтральнага рэпазітара Maven. Цяпер мультымодульны праект Maven ствараецца з двума модулямі і залежнасцю паміж двума модулямі. Залежнасць паміж модулямі аднаго ўзроўня зараз даступная ў лакальным рэпазітары Maven, каб можна было працягнуць зборку.
Карыстальнікі могуць мяняць шлях для кланавання ў CI
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Па змаўчанні GitLab Runner клануе праект ва ўнікальны ўкладзены шлях у $CI_BUILDS_DIR. Але для некаторых праектаў, напрыклад Golang, код трэба кланаваць у пэўны каталог, каб яго можна было сабраць.
У GitLab 11.10/XNUMX мы ўвялі зменную GIT_CLONE_PATH, з дапамогай якой можна пазначыць пэўны шлях, куды GitLab Runner клануе праект да выканання задачы.
Простая маскіроўка абароненых зменных у логах
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
GitLab дае некалькі спосабаў и зменных у GitLab CI/CD. Але зменныя ўсё роўна могуць наўмысна ці выпадкова патрапіць у часопісы зборкі.
GitLab сур'ёзна ставіцца да кіравання рызыкамі і аўдыту і працягвае дадаваць фічы для захавання патрабаванняў. У GitLab 11.10/XNUMX мы ўвялі магчымасць маскіраваць некаторыя тыпы зменных у логах трасіроўкі джобаў, дадаўшы ўзровень абароны ад выпадковага траплення змесціва гэтых зменных у часопісы. А яшчэ GitLab зараз многія убудаваныя зменныя токенаў.
Уключэнне і адключэнне Auto DevOps на ўзроўні групы
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
З Auto DevOps у праекце GitLab.com можна без лішніх клопатаў узяцца за сучасныя працоўныя працэсы DevOps – ад зборкі да пастаўкі.
Пачынаючы з GitLab 11.10/XNUMX вы можаце ўключаць і адключаць Auto DevOps для ўсіх праектаў у адной групе.
Спрошчаная і палепшаная старонка ліцэнзій
STARTER, PREMIUM, ULTIMATE
Каб кіраваць ключамі ліцэнзіі было зручней і прасцей, мы змянілі дызайн старонкі ліцэнзій на панэлі адміністратара і вылучылі найважнейшыя элементы.
Абнаўленне селектара ярлыкоў для дэплояў Kubernetes
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
На панэлях дэплою адлюстроўваюцца звесткі аб усіх дэплоях Kubernetes.
У гэтым выпуску мы змянілі спосаб супастаўлення цэтлікаў з дэплоямі. Цяпер даступныя супадзенні па app.example.com/app и app.example.com/env або app. Гэта дазволіць пазбегнуць канфліктаў пры фільтрацыі і рызыкі няправільных дэплояў, звязаных з праектам.
Акрамя таго, у версіі GitLab 12.0 мы , і супадзенне будзе магчыма толькі па app.example.com/app и app.example.com/env.
Дынамічнае стварэнне рэсурсаў Kubernetes
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Інтэграцыя Kubernetes у GitLab дазваляе выкарыстоўваць функцыю RBAC з дапамогай акаўнта сэрвісу і вылучанай прасторы імёнаў для кожнага праекту GitLab. Пачынаючы з гэтага выпуску для максімальнай эфектыўнасці гэтыя рэсурсы будуць стварацца, толькі калі патрэбны для дэплою.
Пры дэплоі Kubernetes GitLab CI будзе ствараць гэтыя рэсурсы перад дэплоем.
Групавыя раннеры для кластараў на ўзроўні групы
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Кластары на ўзроўні групы зараз падтрымліваюць усталёўку GitLab Runner. Ранэры Kubernetes на ўзроўні групы адлюстроўваюцца для даччыных праектаў як групавыя раннеры, пазначаныя ярлыкамі. cluster и kubernetes.
Лічыльнік выкліку для функцый Knative
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Функцыі, разгорнутыя з , зараз паказваюць колькасць атрыманых выклікаў для асобнай функцыі. Для гэтага трэба ўсталяваць Prometheus на кластары, дзе ўсталяваны Knative.
Кантроль параметраў git clean для джобаў GitLab CI/CD
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Па змаўчанні GitLab Runner выконвае git clean падчас выгрузак кода пры выкананні джоба ў GitLab CI/CD. Пачынальна з GitLab 11.10 карыстачы могуць кантраляваць параметры, перададзеныя камандзе git clean. Гэта зручна для каманд з выдзеленымі раннерамі, а таксама для каманд, якія збіраюць праекты з вялікіх монорепозиториев. Цяпер яны могуць кіраваць працэсам выгрузкі да выканання скрыптоў. Новая пераменная GIT_CLEAN_FLAGS па змаўчанні мае значэнне -ffdx і прымае ўсе магчымыя параметры каманды [git clean](https://git-scm.com/docs/git-clean).
Вонкавая аўтарызацыя ў Core
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Абароненыя асяроддзі могуць патрабаваць дадатковы вонкавы рэсурс аўтарызацыі для доступу да праекту. Мы дадалі падтрымку дадатковага ўзроўню кантролю доступу ў і атрымалі шмат просьбаў адкрыць гэты функцыянал у Core. Мы рады прадставіць знешнюю аўтарызацыю і дадатковы ўзровень бяспекі для асобнікаў Core, раз гэтая фіча патрэбна асобным удзельнікам.
Магчымасць стварэння праектаў у групах у Core
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Роля Developer можа ствараць праекты ў групах , а зараз гэта магчыма і ў Core. Стварэнне праектаў – гэта ключавая магчымасць для прадуктыўнай працы ў GitLab, і дзякуючы ўключэнню гэтай функцыі ў Core удзельнікам асобніка зараз прасцей заняцца чымсьці новым.
GitLab Runner 11.10/XNUMX
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Сёння мы выпусцілі GitLab Runner 11.10/XNUMX! GitLab Runner - гэта праект з адкрытым зыходным кодам, які выкарыстоўваецца для запуску заданняў CI/CD і адпраўкі вынікаў назад у GitLab.
Самыя цікавыя змены:
- .
- .
- .
- .
- .
Поўны спіс змен можна знайсці ў часопісе змен GitLab Runner: .
Выпраўленне вяртаемага project_id у API пошуку blob у Elasticsearch
STARTER, PREMIUM, ULTIMATE
Мы выправілі памылку ў API пошуку blob у Elasticsearch, які памылкова вяртаў 0 для project_id. Трэба будзе , каб атрымліваць правільныя значэння project_id пасля ўстаноўкі гэтай версіі GitLab.
Паляпшэнні Omnibus
CORE, STARTER, PREMIUM, ULTIMATE
Мы ўнеслі наступныя паляпшэнні ў Omnibus ў GitLab 11.10/XNUMX:
- GitLab 11.10 уключае , , У апошні выпуск якога ўваходзіць новы каталог інтэграцыі для простага пераносу дадзеных з Hipchat і шмат чаго яшчэ. Гэтая версія ўключае , і мы раім абнавіцца.
- Мы , і зараз пачаць маніторынг асобніка GitLab стала зусім проста.
- Мы дадалі падтрымку выдалення старых вобразаў кантэйнераў з рэестра Docker.
- Мы абнавілі ca-certs да 2019/01/23.
паляпшэння прадукцыйнасці
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Мы працягваем паляпшаць прадукцыйнасць GitLab з кожным выпускам для асобнікаў GitLab любога памеру. Некаторыя паляпшэнні ў GitLab 11.10:
- .
- .
- .
- .
- .
- .
- .
- .
Паляпшэнне дыяграм GitLab
CORE, STARTER, PREMIUM, ULTIMATE
Мы ўнеслі наступныя паляпшэнні ў дыяграмы GitLab:
- .
Састарэлыя фічы
GitLab Geo забяспечыць хэшаванае захоўванне ў GitLab 12.0
GitLab Geo патрабуецца для змякчэння канкурэнцыі на другасных нодах. Гэта было адзначана ў .
У GitLab мы дадалі гэтае патрабаванне ў дакументацыю Geo: .
У GitLab sudo gitlab-rake gitlab:geo:check правярае, ці ўключана хэшаванае сховішча і ці ўсе праекты пераносяцца. Глядзі. . Калі вы карыстаецеся Geo, калі ласка, запусціце гэтую праверку і мігруйце як мага хутчэй.
У GitLab пастаянна адключанае папярэджанне будзе адлюстроўвацца на старонцы Вобласць адміністратара > Geo > Nodes, калі вышэйзгаданыя праверкі не дазволеныя.
У GitLab Geo будзе выкарыстоўваць патрабаванні да хэшаванага сховішча. Глядзі. .
Дата выдалення: 22 чэрвеня 2019 г.
Падтрымка Ubuntu 14.04
GitLab 11.10 стане апошнім выпускам з .
Canonical абвясціла аб спыненні стандартнай падтрымкі Ubuntu 14.04/XNUMX з . Раім карыстальнікам перайсці на падтрымліваемую версію LTS: Ubuntu 16.04/18.04 або Ubuntu XNUMX/XNUMX.
Дата выдалення: 22 мая 2019 г.
Абмежаванне максімальнай колькасці пайплайнаў, якія ствараюцца адной адпраўкай
Раней GitLab ствараў пайплайны для HEAD кожнай галінкі ў адпраўцы. Гэта зручна для распрацоўшчыкаў, якія адпраўляюць адразу некалькі змен (напрыклад, у галінку фічы і ў галінку develop).
Але пры адпраўцы вялікага рэпазітара, дзе шмат актыўных галінак (напрыклад, для перасоўвання, отзеркаливания ці разгалінавання), не трэба ствараць пайплайн для кожнай галінкі. Пачынаючы з GitLab 11.10/XNUMX мы ствараем пры адпраўцы.
Дата выдалення: 22 мая 2019 г.
Састарэлыя шляхі legacy кода GitLab Runner
Пачынаючы з Gitlab 11.9/XNUMX GitLab Runner выкарыстоўвае кланавання/выкліку рэпазітара. У цяперашні час GitLab Runner будзе выкарыстоўваць стары метад, калі новы не падтрымліваецца. Падрабязней глядзіце ў .
У GitLab 11.0 мы змянілі выгляд канфігурацыі сервера метрык для GitLab Runner. metrics_server будзе выдалены на карысць listen_address у GitLab 12.0. Падрабязней глядзіце ў .
У версіі 11.3 GitLab Runner пачаў падтрымліваць ; што прывяло да новых налад для . У , прыведзена табліца змен і інструкцыі па пераходзе да новай канфігурацыі. Падрабязней глядзіце ў .
Гэтыя шляхі будуць недаступныя ў GitLab 12.0. Як карыстачу, вам не трэба нічога змяняць, толькі пераканацца, што асобнік GitLab працуе з версіяй 11.9+ пры абнаўленні да GitLab Runner 12.0.
Дата выдалення: 22 чэрвеня 2019 г.
Састарэлы параметр для фічы кропкі ўваходу для GitLab Runner
У 11.4/XNUMX GitLab Runner прадстаўлены параметр фічы для выпраўлення такіх праблем, як и .
У GitLab 12.0 мы пераключымся на правільныя паводзіны, як калі б параметр фічы быў адключаны. Падрабязней глядзіце ў .
Дата выдалення: 22 чэрвеня 2019 г.
Састарэлая падтрымка дыстрыбутыва Linux, які дасягнуў EOL, для GitLab Runner
Некаторыя дыстрыбутывы Linux, у якія можна ўсталяваць GitLab Runner, сваё адслужылі.
У GitLab 12.0 GitLab Runner больш не будзе размяркоўваць пакеты ў такія дыстрыбутывы Linux. Поўны спіс дыстрыбутываў, якія больш не падтрымліваюцца, можна знайсці ў нашай . Дзякуй Хаўеру Ардо () за !
Дата выдалення: 22 чэрвеня 2019 г.
Выдаленне старых каманд GitLab Runner Helper
У рамках намаганняў па падтрымцы прыйшлося адмовіцца ад некаторых старых каманд, якія выкарыстоўваюцца для .
У GitLab 12.0 GitLab Runner запускаецца з дапамогай новых каманд. Гэта датычыцца толькі карыстальнікаў, якія . Падрабязней глядзіце ў .
Дата выдалення: 22 чэрвеня 2019 г.
Выдаленне legacy механізму git clean з GitLab Runner
У GitLab Runner 11.10/XNUMX наладзіць, як Runner выконвае каманду git clean. Акрамя таго, новая стратэгія ачысткі выдаляе выкарыстанне git reset і змяшчае каманду git clean пасля кроку выгрузкі.
Раз гэта змена паводзін можа паўплываць на некаторых карыстальнікаў, мы падрыхтавалі параметр FF_USE_LEGACY_GIT_CLEAN_STRATEGY. Калі ўсталяваць значэнне true, ён адновіць legacy-стратэгію ачысткі. Больш аб выкарыстанні параметраў функцый у GitLab Runner можна знайсці .
У GitLab Runner 12.0 мы выдалім падтрымку legacy-стратэгіі ачысткі і магчымасць аднаўляць яе з дапамогай параметра функцыі. Падрабязней глядзіце ў .
Дата выдалення: 22 чэрвеня 2019 г.
Раздзел System Info у панэлі адміністратара
GitLab прадстаўляе інфармацыю аб вашым экзэмпляры GitLab у admin/system_info, Але гэтая інфармацыя можа быць недакладнай.
Мы панэлі адміністратара ў GitLab 12.0 і рэкамендуемы выкарыстоўваць .
Дата выдалення: 22 чэрвеня 2019 г.
часопіс змяненняў
Шукайце ўсе гэтыя змены ў часопісе змен:
Ўстаноўка
Калі вы наладжваеце новую ўстаноўку GitLab, наведайце .
Абнаўленне
Зазірніце на .
Планы падпіскі GitLab
GitLab даступны ў двух варыянтах: и .
: лакальна або на упадабанай хмарнай платформе.
- Core: для невялікіх каманд, персанальных праектаў або пробнай версіі GitLab на неабмежаваны перыяд.
- пускатель: для каманд, якія працуюць у адным офісе над некалькімі праектамі, якім патрэбна прафесійная падтрымка.
- прэмія: для размеркаваных каманд, якім патрэбны пашыраныя функцыі, высокая даступнасць і кругласутачная падтрымка.
- Канчатковы: для прадпрыемстваў, якім патрабуецца надзейная стратэгія і рэалізацыя з палепшанай бяспекай і адпаведнасцю патрабаванням.
- GitLab.com: размяшчаецца, кіруецца і адмініструецца GitLab па для асобных распрацоўшчыкаў і каманд.
- Free: неабмежаваныя прыватныя рэпазітары і неабмежаваную колькасць удзельнікаў праекта. У зачыненых праектаў ёсць доступ да фічаў узроўня Free, У ёсць доступ да фіч ўзроўню золата.
- Бронза: для каманд, якім патрэбен доступ да пашыраных фічоў працоўнага працэсу.
- срэбра: для каманд, якім патрэбны больш надзейныя магчымасці DevOps, адпаведнасць патрабаванням і хуткая падтрымка.
- золата: падыходзіць для мноства джобаў CI/CD. Усе адкрытыя праекты могуць бясплатна выкарыстоўваць фічы Gold незалежна ад плана.
Крыніца: habr.com