Вийшов реліз 13.4 зі сховищем HashiCorp для змінних CI, Kubernetes Agent і центром безпеки, а також фічами, що перемикаються в Starter
У GitLab ми завжди думаємо про те, як допомогти користувачам знизити ризики, підвищити ефективність та швидкість постачання на вашій улюбленій платформі. Цього місяця ми додали чимало корисних нововведень, які розширюють можливості безпеки, знижують кількість вразливостей, підвищують ефективність, спрощують роботу з GitLab та допомагають вашій команді постачати фічі ще швидше. Ми сподіваємося, що вам знадобляться основні фічі релізу, а також 53 інші нові фічі, додані у цьому релізі.
Розширені можливості безпеки
Ми намагаємось додавати кілька нових фіч до GitLab DevSecOps щомісяця, і цей реліз – не виняток. в рамках складання та розгортання. Крім того, організації, які хочуть підтримувати поділ обов'язків з розгортання коду, тепер можуть . Ця роль відповідає і дозволить підтверджувати мерж-реквести (у російській локалізації GitLab «запити на злиття») та розгортати код у захищених середовищах, не надаючи при цьому доступу для зміни самого коду.
Ще один спосіб знизити ризики - використання нового . Фахівці з експлуатації можуть розгортати кластери Kubernetes із GitLab без необхідності відкривати доступ до свого кластера для всього інтернету. Ми також представляємо автоматичну підтримку контролю версій для нових файлів стану Terraform з для підтримки відповідності вимогам та зручності у налагодженні. І нарешті, панель управління безпекою в інстансі перетворилася на зі звітами про вразливість та налаштування безпеки.
Більш зручна та ефективна робота з GitLab
Ми покращили наш глобальний пошук, додавши до нього , що дозволяє легко переходити до останніх тикетів, груп, проектів, налаштувань та розділів довідки. Ми раді оголосити, що в GitLab Pages для переадресації окремих сторінок та каталогів усередині сайту, що дозволить користувачам ефективніше розгортати свої сайти. А тим, хто хотів би отримати розширену інформацію про розгортання, цей реліз дозволяє !
Вклади з відкритим вихідним кодом
Ми представляємо , яке додав . Відмітки про покриття юніт-тестами зміненого коду дають розробникам наочне уявлення про покриття коду при рев'ї; ця інформація допомагає прискорити реву і зменшити час на мерж і розгортання нового коду. А ще ми та плануємо .
І це ще лише початок!
Як і завжди, у загальному огляді занадто мало місця, а класних фіч у релізі 13.4 дуже багато. Ось ще кілька:
- .
Якщо ви хочете заздалегідь дізнатися, що вас чекає у наступного релізі, подивіться .
.
цього місяця -
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 ми запровадили для них стратегії и , а до 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 дизайни наздоганяють коментарі до тикетів у використанні завдань, що робить роботу з ними більш послідовною та ефективною.
и .
Поліпшений посібник з усунення несправностей для 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 ми пропонуємо новий спосіб налаштування редактора статичних сайтів. Хоча конфігураційний файл не зберігає і не отримує жодних параметрів у цьому релізі, ми закладаємо основу для майбутнього настроювання поведінки редактора. У наступних релізах ми додамо до файлу .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, щоб забезпечити складніші мережі взаємозв'язків між завданнями у ваших конвеєрах.
Якщо ви адміністратор інстасу користувача 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 профіль сканера спочатку включає параметр тайм-ауту пошукового робота, який встановлює, як довго повинен працювати пошуковий робот DAST, коли він намагається виявити всі сторінки сайту, що сканується. Профіль також включає параметр тайм-ауту цільового сайту, щоб встановити, як довго сканер повинен чекати, поки сайт стане доступним, перш ніж перервати сканування, якщо сайт не відповідає коду стану 200 або 300. У міру того, як ми будемо знову і знову покращувати цю фічу в наступних релізах, до профілю сканера буде додано додаткові параметри конфігурації.
и .
Простий файл конфігурації редиректів для 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 Omnibus. Велике спасибі Zitai Chen і Guillaume Gardet за величезний внесок, який вони зробили - їх мерж-реквести зіграли у цьому ключову роль!
Щоб скачати та встановити пакет для Ubuntu 20.04, перейдіть на нашу і виберіть Ubuntu.
и .
Підтримка аутентифікації за допомогою смарт-карт для GitLab Helm chart
(PREMIUM, ULTIMATE)
Смарт-карти, наприклад, карти загального доступу (CAC), тепер можна використовувати для аутентифікації в інстансі GitLab, розгорнутому через Helm chart. Смарт-картки автентифікуються у локальній базі даних за допомогою сертифікатів X.509. Завдяки цьому підтримка смарт-карток з Helm chart тепер знаходиться у відповідності до підтримки смарт-карток, доступної в розгортанні Omnibus.
и .
Детальні release notes та інструкції по оновленню/установці можна прочитати в оригінальному англомовному пості: .
Над перекладом з англійської працювали , , и .
Джерело: habr.com