Вийшов GitLab 8.12

Поза залежності від масштабу вашого проекту, ваш інструментарій повинен:
а. бути зручним у роботі
б. давати корисну зворотний зв'язок.
В цьому місяці GitLab став краще по кожному з цих пунктів. GitLab 8.12 дає вам зворотний зв'язок про ефективність вашої роботи, допомагає шукати потрібний код по всій кодової базі, дозволяє убезпечити ваш робочий процес всього одним кліком і робить багато іншого.

MVP (Most Valuable Person) цього місяця — Джеймс Муннелли (James Munnelly): він інтегрував Kubernetes в GitLab CI. Ця фіча дозволяє легко запускати CI-тести на кластері Kubernetes. Джеймс відкрив цей мерж-реквест близько року тому, а потім терпляче і наполегливо доопрацьовував його за результатами рев'ю.
Дякую, Джеймс!
Аналітика циклу розробки ПО (Cycle Analytics)
Перший принцип conversational development (convdev) — зменшення часу циклу розробки ПЗ, тобто часу, за яке ідея реалізується і випускається на production. Чим коротше час циклу, тим вище ефективність вашої команди.
У GitLab 8.12 ми реалізували Cycle Analytics — інструмент, який показує середній час циклу у вашій команді.
Cycle Analytics in GitLab 8.12
Cycle Analytics показує вам тривалість вашого циклу розробки, розбиваючи його на окремі етапи, так що ви бачите місця, в яких можливі поліпшення, і можете точно передбачати строки розробки.
Сторінка Cycle Analytics знаходиться у вкладці Pipelines кожного проекту.
Детальніше про Cycle Analytics
Глобальний пошук коду (EE)
Якщо на вашому инстансе GitLab Enterprise Edition налаштований Elasticsearch, вам стане доступний пошук по коду всіх проектів відразу.
Global code search in GitLab EE 8.12
Використовуйте пошук так само, як ви робили це раніше; тільки тепер GitLab покаже вам результати з усіх проектів, до яких у вас є доступ.
Зверніть увагу на те, що ця можливість вимагає перестроювання індексу Elasticsearch.
Більше інформації про це ви можете знайти нижче, в розділі «Барометр оновлень».
Версії мерж-реквестов
Якщо ви додаєте нові коміти в мерж-реквест, дуже складно побачити діфф між одним з попередніх комітів і цільової гілкою.
Merge Request Versions in GitLab 8.12
З допомогою відстеження версій мерж-реквестов ви можете побачити попередні стани мерж-реквеста і порівняти будь-який з попередніх комітів з цільовою гілкою, або з іншим комітом.
Детальніше про версіях мерж-реквестов
Захист від публікації чутливої інформації (EE)
Коммитить секретну інформацію, таку як ключі і сертифікати — дуже, дуже груба помилка. Ці дані потраплять до кожного, хто зможе клонувати репозиторій, а щоб скомпрометувати інформацію, достатньо буде однієї витоку.
На жаль, таке трапляється досить часто.
Наприклад, ви пишете
git commit -am'хотфикс' && git push
, а потім виявляєте, що закоммитили те, що не слід було.
У GitLab з'явилася нова перевірка при пуше (push rule), яка блокує коміти з чутливою інформацією. Просто поставте відповідну галочку, і GitLab не дозволить закоммитить небезпечні файли, наприклад
.pem
та
.key
.
Prevent secrets in your repo in GitLab EE 8.12
У GitLab EE і раніше була можливість блокувати файли по регулярному виразу. Ви можете використовувати її, щоб налаштувати блокування того, що не увійшло в наш фільтр.
Детальніше про перевірки при пуше
Review Apps (експериментальна фіча)
Ми внесли кілька змін в GitLab CI. Разом вони створюють трохи чарівництва.
Тепер ви можете задавати імена оточень (environments) у змінних CI. Ви також можете вказати URL для конфігурації оточення у файлі
.gitlab-ci.yml
. Разом ці дві можливості становлять основу першої ітерації Review Apps.
Review apps — це автоматично створювані оточення, які розгортається код з кожної гілки. Це означає, що тепер кожному мерж-реквесту автоматично призначається працює оточення.
Ідея цієї фічі була взята у Heroku Review Apps, а компанія Heroku запозичила її у Fourchette.
Ці невеликі нововведення можуть зробити істотний вплив на ваш робочий процес. Рев'ю будь-якого аспекту роботи програми — від продуктивності до користувальницького інтерфейсу — стає простіше, коли є працююче оточення.
В даний момент фіча Review Apps вважається експериментальною, тому що оточення поки що не знищуються автоматично, коли перестають бути потрібні.
В даний момент ми пишемо нову статтю з прикладами Review Apps.
Авторизація в LFS через SSH
Якщо ви звикли робити пуши через SSH, то вводити свої логін і пароль щоразу при використанні LFS напевно дещо розчарувало.
GitLab тепер використовує SSH-ключ при використанні LFS. Тобто, якщо ви використовуєте LFS, підключаючись через SSH, вам більше не доведеться вручну вводити дані для ідентифікації
Передача файлів LFS все ще проводиться через HTTP.
Включення і відключення LFS
Git LFS (Large File Storage) — це добре, але використання цієї фічі, як мається на увазі в назві, може зажадати багато місця на диску. Щоб ви менше хвилювалися про витрачання дискового простору, ви можете включати і вимикати LFS для всього инстанса GitLab, для групи проектів або для конкретного проекту.
Обмеження розміру проекту (EE)
Крім обмеження розміру LFS, ви тепер можете обмежувати максимальний розмір проектів. Обмеження поширюється на всі дані репозиторію і об'єкти LFS і зупинить будь комміт, який перевищує встановлене обмеження.
Limit project size in GitLab EE 8.12
Адміністратор може встановити глобальний ліміт і змінити його на рівні групи та проекту. Таким чином ви можете виділити конкретних проектів додатковий простір.
Докладніше документації про обмеження розміру репозиторію
Поліпшення LDAP/Active Directory
В цьому релізі додані деякі удосконалення в підтримку LDAP/Active Directory для GitLab CE і EE:
  • CE/EE — Запитувати тільки LDAP-атрибути користувача/групи, які будуть потрібні GitLab (CE 6187 EE 712), зменшуючи кількість переданих даних між GitLab і сервером LDAP/Active Directory. Це також зменшує кількість зайнятої об'єктами пам'яті всередині GitLab .
  • EE — Прискорення вибірок вкладених груп і пагинрованных запитів користувачів (для великих груп) (719
  • EE — Додана опція 'Sync now' на сторінку члена команди, якщо присутні групові посилання LDAP (704
Відновлення токенів двофакторної аутентифікації через SSH
Тепер ви можете відновлювати ваші коди двофакторної аутентифікації використовуючи SSH. Відновити ваш аккаунт в разі його викрадення стало простіше, при цьому загальний рівень безпеки системи не знизився.
Докладніше документації про відновлення двофакторної аутентифікації через SSH.
Фільтр тегів по іменах
Хочете швидко знайти тег? Використовуйте для цього новий зручний фільтр у верхній частині сторінки:
Filter tags by name in GitLab 8.12
Доповнення до API
У GitLab 8.12 ми розширили наш API:
  • З'явилася можливість встановлювати параметр
    request_access_enabled
    для груп і проектів
  • Додано виклики API
    notification_settings
  • Додано API
    BroadcastMessage
  • Тепер ви можете форкаться в конкретні простору імен (namespaces) через API
  • Можливість вмикати/вимикати запити на доступ для груп і проектів
  • Додано поле
    web_url
    в тікети, мерж-реквесты і фрагменти (функціональність реалізована членами нашої спільноти)
  • Повернення
    sha
    та
    merge_commit_sha
    в API-запиті для мерж-реквестов. (функціональність реалізована членами нашого спільнот)
  • Розпізнавання позначки конфіденційності тікета (функціональність реалізована членами нашого спільнот)
  • Додана настройка проекту
    only_allow_merge_if_build_succeeds
    . (функціональність реалізована членами нашого спільнот)
  • Додано API-виклик, щоб перевірити ваш
    .gitlab-ci.yml
    файл на синтаксичну коректність (lint) (функціональність реалізована членами нашого спільнот)
  • Додано API для відображення ручних дій в розділах «Середовища розгортання» (Environments) і «Розгортання» (Deployments)
Покращений інструмент імпорту з GitHub
Інструмент імпорту з GitHub стає все краще і краще, спрощуючи міграцію в GitLab. У GitLab 8.12 інструмент імпорту буде також копіювати release notes в GitLab, а також дозволить вам вибирати простір імен, що імпортуються проекти.
Improved GitHub importer in GitLab 8.12
Це має полегшити процес міграції, якщо у вас вже є проекти в GitLab, або якщо вам потрібно щось, що відрізняється від дефолтного поведінки імпорту в GitLab.
Докладніше документації про імпорт репозиторіїв з GitHub.
Масове управління мерж-реквестами
Тепер ви можете редагувати кілька мерж-реквестов відразу. Одночасно змінити в декількох мерж-реквестах можна: статус, етап (milestone), ярлик (label), опис або розробника, на якого призначений мерж-реквест.
Bulk update Merge Requests in GitLab 8.12
Управління проектами з великою кількістю мерж-реквестов стане набагато легше!
Угруповання білдів
Якщо у вас багато схожих білдів, ваша схема конвеєра стає дуже довгою. Ми зробили невелику зміну щоб покращити вигляд: схожі білди будуть автоматично групуватися один з одним.
Build grouping in GitLab 8.12
Розширена підсвічування синтаксису
З переходом на rouge 2.0.6, ми додали підсвічування синтаксису для JSX, Prometheus, mxml, 1C (1С, Карл!), turtle/trig, vhdl, і поліпшили підсвічування для Swift 3.
Інтеграція Sentry в Workhorse
GitLab-Workhorse тепер може відправляти помилки програми у Sentry.
Докладніше документації по GitLab-Workhorse
GitLab Runner 1.6
Також ми сьогодні випускаємо GitLab Runner 1.6. Ключові моменти:
  • Kubernetes executor (30 and 277, this allows Kubernetes to automatically scale the number of CI runners. All your builds will be processed immediately without having idle machines running when it's not busy.
  • Autocompletion of /ci in GitLab URL while registering the Runner (289
  • Configuration options for specifying scripts executed before clone/fetch is done before and build script is executed (106
  • Improvements in passing CA certificate to builds (299
  • Improvement in disabling recursive submodules fetching/cloning (314
  • Improve docker machine logging (234
  • Add possibility to specify a list of volumes to inherit from another container (236
  • Generate a
    BuildError
    instead of
    SystemError
    when Docker/Kubernetes image is missing (295
Подивитися повний список змін можна changelog-файлі Runner.
GitLab Mattermost 3.4
GitLab 8.12 включає в себе Mattermost 3.4, альтернатива Slack з відкритим кодом, останній реліз якого пропонує 700 інтеграцій з повною підтримкою Markdown через Zapier, спрощеного бота і аутентифікацію через OAuth2, а також (додану представниками нашої спільноти) інтеграцію з Gitter, Heroku, Pivotal Tracker, Chef, Ansible і Yunohost.
Поліпшення продуктивності
  • Процеси Sidekiq тепер використовують пул з'єднань при використанні механізму кешування Rails: мерж-реквест
  • Тепер використовується гем
    oj
    для прискорення обробки JSON: мерж-реквест
  • Колонка
    projects.last_activity_at
    оновлюється один раз на годину, щоб зменшити навантаження на базу даних: мерж-реквест
  • Колонка
    projects.pushes_since_gc
    переміщено з бази даних у Redis, щоб зменшити навантаження на базу даних: мерж-реквест
  • Перевірка захищених гілок не провадиться, коли ім'я гілки невідомо, що зменшує кількість часу, витраченого на цей процес: мерж-реквест
  • Перевірка, чи може хто-небудь закрити коментар до коммиту, робиться тільки в тому випадку, коли коментарі взагалі можна закривати: мерж-реквест
  • Таблиця
    ci_runners
    тепер оновлюється рідше, щоб зменшити навантаження на базу даних: мерж-реквест
  • Зменшено число запитів до бази даних, використовуваних для вкладки "Builds" для комітів/мерж-реквестов: мерж-реквест
  • Зменшений максимальний розмір календаря дій:
    мерж-реквест
Зміни в правах доступу для збірок
GitLab 8.12 привніс важливі змін до права доступу для збірок
Ми вирішили, що права доступу у збірки повинні бути тісно пов'язані з правами доступу користувача, який запустив цю збірку. На те є наступні причини:
  • У нас вже є система прав доступу для користувачів (що базується на те, до якої групи або проекту належить користувач)
  • Ми знаємо, який користувач запускає білд (неважливо, як саме — використовуючи пуш в Git, через веб або через тригери).
  • Ми знаємо, що дозволено цьому користувачеві.
  • Збірок, які були запущені пушем, ми даємо ті ж права, що мав користувач, який зробив пуш (погодьтеся, зручно, коли ваша збірка має доступ до всього, до чого є доступ у вас)
  • Ми можемо створювати унікальні короткоживучі токени, надають необхідний доступ на час життя складання.
  • Це дуже добре співвідноситься з нашої філософії «все повинно бути інтегровано між собою)
  • Такий підхід дозволяє робити з правами доступу багато цікавого: наприклад, давати лише окремим користувачам доступ до runners, секретним змінним середах і розгортання (environments).
Тепер будь збірка, запущена користувачем, буде наділена правами доступу користувача. Коли користувач робить
git push
або змінює файли через користувальницький інтерфейс, ми створюємо новий конвеєр. Цей конвеєр буде належати тому, хто робив пуш, а білди, створені в цьому конвеєрі, будуть мати права доступу того, хто робив пуш.
Це дозволить нам полегшити процес пропагации доступу до всіх залежних проектів і образам контейнерів, до яких у автора збірки буде доступ. Права доступу надаються тільки на час дії складання; після завершення складання доступ буде відкликаний.
Детальніше про права доступу збірок і зміни у зв'язку з цим дивіться нашу документацію.
Якщо вам цікава історія і причини цієї зміни, ви можете прочитати повне обговорення статті.
Подмодули в CI
Подмодули (submodules) — це одна з причин, чому ми переробили права доступу для збірок. Тепер використовувати подмодули у ваших CI-збірках стало набагато простіше.
Для використання подмодулей у вас повинен бути файл
.gitmodules
, який виглядає приблизно так:
[submodule "tools"]
path = tools
url = git@gitlab.com/group/tools.git

Щоб використовувати нові права доступу збірок для ваших подмодулей, вам потрібно переробити ваші URL відносні:
[submodule "tools"]
path = tools
url = ../../group/tools.git

Це змусить Git використовувати ті самі ім'я і пароль, що і для доступу до исходниками проекту.
Останній крок — сказати GitLab CI викачати подмодули:
before_script:
- git submodule update --init --recursive

Ви можете дізнатися детальніше про підтримку подмодулей в нашій документации.
Інші зміни
В цьому релізі багато інших змін, включаючи різні виправлення безпеки. Щоб подивитися всі зміни, зверніться до сhangelog.
Барометр оновлень
Цей реліз зажадає додатковий час, так як додані зовнішні ключі, змінені типи колонок, а деякі колонки були переміщені між таблицями. Весь процес міграції для великих инстансов може зайняти до 30 хвилин. У невеликих інстансах затримка передбачається близько 10-15 хвилин.
(Тільки для EE) реиндексация Elasticsearch
Ми змінили структуру індексу Elasticsearch для репозиторіїв, використовуючи зв'язки типу «батько-нащадок». Вам доведеться повністю перебудувати весь індекс ES. Також Elasticsearch 2.3.x містить баг, який викликає відмова всіх запитів, які одночасно використовують фічу "highlight" і зв'язок «батько-нащадок», у зв'язку з чим ми рекомендуємо використовувати версію 2.4 або більш нову. Після поновлення на GitLab 8.12, вам потрібно видалити старий індекс та зібрати новий.
Щоб видалити старий індекс, зробіть наступний запит до Elasticsearch:
curl -XDELETE 'http://localhost:9200/gitlab-production/'

Потім перекомпілюйте програму \ нові індекси, як описано в документації щодо інтеграції Elasticsearch
Оновлення Ruby
попередньому релізному пості ми згадували, що підтримка Ruby 2.1.x в GitLab 8.13 буде припинена. Ми змінили своє рішення і не будемо припиняти підтримку Ruby 2.1.x в найближчому майбутньому.
Ми як і раніше рекомендуємо вам оновитися до Ruby 2.3, якщо ви запускаєте установку з вихідного, так як це та ж версія, яка поставляється разом з Omnibus.
Розширена відправка користувальницьких даних (EE)
Щоб дати нам більше інформації про сценарії використання нашого продукту, GitLab 8.12 EE тепер відправляє на сервер додаткові дані.
Ми не збираємо ніякої інформації (такої як назви проектів, коментарі, вміст файлів тощо). Ви можете переглядати дані, що пересилаються в адміністраторських налаштуваннях, де за бажанням цю фічу можна відключити.
Детальніша інформація — у відповідному мерж-реквесте
Секретний ключ GitLab-Workhorse
GitLab-Workhorse тепер використовує секретний ключ, щоб підписувати деякі повідомлення, що посилаються в Rails-додаток GitLab. Поки що це в першу чергу перевірка коректності конфігурації; в майбутніх релізах ми хочемо додати в GitLab-Workhorse фічі, яким потрібен цей секретний ключ для підтвердження довіри.
Якщо ви використовуєте Omnibus, або ви встановлювали GitLab з джерела з нашим офіційним init.d скриптом, ваш секретний ключ сгенерируется і встановиться автоматично. Якщо ви використовуєте свій init.d скрипт або користуєтеся пакетами, створеними не у GitLab Inc., вам знадобиться встановити опцію
secretPath
в GitLab-Workhorse.
Ще дещо
Ми припускаємо, що ви оновлюйтеся з останньої версії. Якщо це не так, ознайомтеся з «барометрами оновлень» проміжних версій, які ви пропускаєте. Якщо ви оновлюйтеся з GitLab до версії 8.0 у вас включена CI, вам слід спочатку оновитися до GitLab 8.0
будь Ласка, пам'ятайте, що вихідні пакети Omnibus зупиняться, запустять міграції і запрацюють знову, незалежно від того, наскільки «велика» або «маленьке» вийде оновлення. Щоб змінити цю поведінку, додайте файл
/etc/gitlab/skip-auto-migrations
.


Установка
Якщо ви встановлюєте GitLab з «нуля», перегляньте розділ.
Оновлення
Слідкуйте за нашими оновленнями.
Enterprise Edition
GitLab Enterprise Edition включає в себе додаткові функції типу підтримки LDAP-груп. Детальну інформацію можна подивитися у
описі GitLab EE.
GitLab EE доступний тільки з підписці.
Не вистачає часу на установку і настройку нового інструменту? У вартість передплати входять послуги з встановлення та оновлення GitLab на ваших серверах.


Переклад з англійської виконаний перекладацької артіллю «Надмозг і партнери», http://nadmosq.ru, над перекладом працювали nick_volynkin, rishavant і chebureque
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.