GitLab 11.10 з пайплайнами на панелі управління, пайплайнами для об'єднаних результатів та пропозиціями по кількох рядках у мердж-реквестах.
Зручні відомості про працездатність пайплайнів у різних проектах
GitLab продовжує збільшувати прозорість життєвого циклу DevOps. У цьому випуску на додано огляд статусу пайплайнів.
Це зручно, навіть якщо ви вивчаєте пайплайн одного проекту, але особливо корисно, якщо , - а так зазвичай і буває, якщо ви використовуєте мікросервіси і хочете запустити пайплайн для тестування та постачання коду з різних проектів репозиторіїв. Тепер ви одразу бачите працездатність де б вони не виконувались.
Запуск пайплайнів для об'єднаних результатів
Згодом вихідна та цільова гілки розходяться, і може виникнути ситуація, коли окремо вони справляються, а разом не працюють. Тепер можна . Так ви швидко помітите помилки, які проявилися б тільки при частому переміщенні змін між гілками, а значить набагато швидше виправте помилки пайплайну і ефективніше використовуватимете .
Подальша оптимізація спільної роботи
У GitLab 11.10 з'явилося ще більше можливостей для зручної спільної роботи та спрощених робочих процесів. У ми ввели пропозиції щодо мердж-реквестів, коли рецензент міг запропонувати зміну одного рядка у коментарі до мердж-реквесту, і його можна було одразу закомітіти прямо з треду коментарів. Нашим користувачам це сподобалося і вони попросили розширити цю фічу. Тепер ви можете пропонувати , вказуючи, які рядки видалити, а які додати.
Дякуємо за ваші відгуки та пропозиції!
І це ще не все…
У цьому випуску стільки приголомшливих фіч, наприклад, , більш ретельна , та можливість . Нижче подробиці про кожну з них.
Найцінніший співробітник цього місяця () - Такуя Ногуті
Цього місяця найціннішим співробітником став Такуя Ногуті (). Така : виправляв баги, доробляв недоробки в бекенді і фронтенді і покращував інтерфейс користувача. Дякую!
Головні фічі GitLab 11.10
Пайплайни на панелі керування
PREMIUM, ULTIMATE, SILVER, GOLD
На панелі керування GitLab відображаються відомості про проекти на всьому екземплярі GitLab. Ви додаєте окремі проекти по одному і можете вибирати, який вас цікавить проект.
У цьому випуску ми додали на панель управління інформацію про статус пайплайнів. Тепер розробники бачать працездатність пайплайнів у всіх потрібних проектах – в одному інтерфейсі.
Пайплайни для об'єднаних результатів
PREMIUM, ULTIMATE, SILVER, GOLD
Зазвичай згодом вихідна гілка відхиляється від цільової, якщо ви постійно не переміщаєте між ними зміни. В результаті пайплайни вихідної та цільової гілок «зелені» та конфліктів мерджа не виникає, але при об'єднанні відбувається збій через несумісність змін.
Коли пайплайн мердж-реквестів автоматично створює нове посилання, яке містить об'єднаний результат мерджа вихідної та цільової гілок, ми можемо запустити пайплайн за цим посиланням та гарантувати, що загальний результат буде робочим.
Якщо ви використовуєте пайплайни мердж-реквестів (у будь-якій якості) і використовуєте приватні GitLab-раннери версії 11.8 або старші, їх потрібно оновити, щоб не виникла проблема . Це не впливає на користувачів загальнодоступних 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
BRONZE, SILVER, GOLD
Користувачі з платними планами 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 кожен джоб у 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 ми надаємо звіти за метриками прямо в мердж-реквесті, який чекає на просту пару ключ-значення. Таким чином користувачі відстежують зміни в часі, включаючи метрики, і зміни метрик для певного мердж-реквеста. Використання пам'яті, тестування спеціалізованих навантажень та статуси працездатності можна перетворити на прості метрики, які можна переглядати прямо у мердж-реквестах поряд з іншими вбудованими звітами.
Підтримка мультимодульних проектів 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 ми запровадили змінну GIT_CLONE_PATH, за допомогою якої можна вказати конкретний шлях, куди GitLab Runner клонує проект до виконання завдання.
Просте маскування захищених змінних у логах
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
GitLab надає кілька способів и змінних у GitLab CI/CD. Але змінні все одно можуть навмисно чи випадково потрапити до журналів збірки.
GitLab серйозно ставиться до управління ризиками та аудиту і продовжує додавати фічі для дотримання вимог. У GitLab 11.10 ми ввели можливість маскувати деякі типи змінних у логах трасування джобів, додавши рівень захисту від випадкового потрапляння вмісту цих змінних до журналів. А ще GitLab тепер багато вбудованих змінних токенів.
Увімкнення та вимкнення Auto DevOps на рівні групи
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
З Auto DevOps у проекті GitLab.com можна без зайвого клопоту взятися за сучасні робочі процеси DevOps - від збирання до постачання.
Починаючи з GitLab 11.10, ви можете включати та відключати 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
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:
- 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 з . Рекомендуємо користувачам перейти на підтримувану версію LTS: Ubuntu 16.04 або Ubuntu 18.04.
Дата видалення: 22 травня 2019 р.
Обмеження максимальної кількості пайплайнів, створюваних однією відправкою
Раніше GitLab створював пайплайни для HEAD кожної гілки у відправленні. Це зручно для розробників, які відправляють відразу кілька змін (наприклад, у гілку фічі та у гілку develop).
Але при надсиланні великого репозиторію, де багато активних гілок (наприклад, для переміщення, віддзеркалення або розгалуження), не потрібно створювати пайплайн для кожної гілки. Починаючи з GitLab 11.10, ми створюємо при відправленні.
Дата видалення: 22 травня 2019 р.
Застарілі шляхи legacy коду GitLab Runner
Починаючи з Gitlab 11.9 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 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 налаштувати, як 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 на необмежений період
- Starter: для команд, що працюють в одному офісі над кількома проектами, яким потрібна професійна підтримка
- Premium: для розподілених команд, яким потрібні розширені функції, висока доступність та цілодобова підтримка.
- кінцевий: для підприємств, яким потрібна надійна стратегія та реалізація з покращеною безпекою та відповідністю вимогам.
- GitLab.com: розміщується, управляється та адмініструється GitLab по для окремих розробників та команд.
- Безкоштовна: необмежені приватні репозиторії та необмежену кількість учасників проекту. Закриті проекти мають доступ до фічів рівня Безкоштовна, у є доступ до фіч рівня золото.
- Bronze: для команд, яким потрібний доступ до розширених фіч робочого процесу.
- срібло: для команд, яким потрібні більш надійні можливості DevOps, відповідність вимогам та швидка підтримка.
- золото: підходить для багатьох джобів CI/CD. Всі відкриті проекти можуть безкоштовно використовувати фічі Gold незалежно від плану.
Джерело: habr.com