Реліз GitLab 8.13

Ми подорожуємо по світу і дуже раді зустрічам з нашими користувачами.
В цьому місяці ми з гордістю хочемо вам представити безліч нововведень, про які ви просили нас як особисто, так і через наш трекер задач.
Тепер можна створювати кілька дощок завдань (issue boards), а перебуваючи на сторінці дошки — швидко заводити нові завдання. Життя мерж-конфліктів стала ще важче і більш швидкоплинний, тому що тепер їх можна дозволяти безпосередньо в GitLab. Покращена система Cycle Analytics дозволяє ще простіше стежити за тим, яка версія коду виконується в кожному з оточень (environments), а також надає вам миттєву зворотний зв'язок.
Званням MVP цього місяця нагороджується Марк Зигфридт (Marc Siegfriedt) за його внесок у створення точки входу (endpoint) API для коміта кількох файлів одразу. Марк виявив терпіння і наполегливість у роботі над цим складним мерж-реквестом. Спасибі, Марку!

Кілька дощок завдань замість однієї (EE)
Тепер у кожному проекті GitLab Enterprise Edition може бути кілька дощок завдань.
Multiple Issue Boards in GitLab 8.13
Це дозволяє вам керувати кількома робочими процесами, так як мітки на завданнях оновлюються синхронно на всіх дошках. Наприклад, у вас є дошка завдань всієї компанії і окрема — для команди дизайнерів. Коли команда дизайнерів виконує свою частину завдання і передає завдання команді фронтенда, оновлюються обидві дошки.
Ми з нетерпінням чекаємо ваших розповідей про те, яке застосування ви знайдете дощок завдань.
Створення нових завдань безпосередньо на дошці завдань
При перегляді дошки завдань ви можете швидко додати ще одну в будь-список:
Create a new issue from the Issue Board in GitLab 8.13
Зрозуміло, вона відразу ж отримає відповідні мітки.
Редактор мерж-конфліктів.
GitLab 8.11 з'явилося дозвіл мерж-конфліктів, що дозволяє при вирішенні конфлікту вибирати між варіантом з поточної гілки і з тієї, яка мержится в поточну.
У GitLab 8.13 з'явився новий інструмент вирішення конфліктів. Тепер ви можете редагувати конфліктуючі зміни прямо в GitLab. Іншими словами, майже будь-які конфлікти можна вирішити не покидаючи сторінки браузера.
Solve Merge Conflicts through the editor in GitLab 8.13
Ми сподіваємося, це допоможе вам бути за всю біль мерж-конфліктів як страшний сон.
Групові мітки
Коли у вас є одна організація і кілька проектів, часто буває необхідно створювати однакові мітки з однаковою розстановкою пріоритетів відразу на декількох дошках завдань. Це досить нудна робота.
Щоб її спростити, ми реалізували групові мітки (group labels). Вони працюють так само, як і звичайні, але створюються і настроюються один раз для групи проектів, після чого доступні в кожному проекті.
level Group labels in GitLab 8.13
В даний момент створювати групові мітки можна тільки зі сторінки вашої групи. В майбутньому ми реалізуємо можливість перетворювати вже існуючі мітки проекту в групові.
Можливість зупинки Review Apps
Review Apps дозволяють вам розгорнути код будь-якого коміта у повноцінному працюючому оточенні для рев'ю і тестування. Тепер, коли таке оточення перестане бути вам потрібне, ви зможете зупинити його безпосередньо через інтерфейс GitLab.
Stop dynamic environments (review apps) in GitLab 8.13
Посилання на розгорнуті версії коду
GitLab створює спеціальні посилання (ref) на версії коду, які в даний момент розгорнуті на кожному з ваших оточень (environments). Вам достатньо один раз налаштувати ваш локальний репозиторій, щоб оновлювати ці посилання з допомогою простого
git fetch
.
Конвеєри в перегляді комітів
Тепер на сторінці перегляду комітів ми показуємо відповідні конвеєри, що дозволяє відразу побачити, що відбувалося з кожним з комітів.
Pipelines for commits in GitLab 8.13
Поліпшення Cycle Analytics
Змінено поведінка Cycle Analytics — тепер проводяться виміри всієї активності за певний проміжок часу, а не тільки відправки в продакшен. Само собою, стадії staging і production показують тільки те, що було відправлено в продакшен.
Призначення тікетів автору мерж-реквеста
Ви вказали посилання на певні тікети в своєму коммите або мерж-реквесте, але не призначили їх на себе або на автора мерж-реквеста? Тепер є простий спосіб зробити це:
Quickly assign
Обмеження видимості репозиторію проекту
З'явилася можливість обмеження доступу до сховища проекту, додатково до вже існуючої функціональності обмеження доступу до тикетам (issues) і фрагментів коду (snippets). Тепер можна прибрати доступ до сховища взагалі для всіх, або залишити доступ виключно для членів команди.
Project repository visibility
Слеш-команда /wip
Тепер можна використовувати наші чудові слеш-команди для швидкого зміни статусу мерж-реквеста з/на Work-In-Progress (WIP).
Просто введіть
/wip
і підтвердіть відправку вашого коментаря або опису мерж-реквеста.
WIP using slash commands in GitLab 8.13
Відстеження налагодження CI
За замовчуванням GitLab Runner не відображає велику частину інформації про процесі роботи із завданнями. Такий підхід перешкоджає надмірність логів складання, а також потраплянню в них секретної інформації, якщо тільки вона не виводиться на консоль з допомогою скрипта.
З іншого боку, з-за цього буває складно встановити причину неправильного виконання якого-небудь завдання. У такій ситуації ви можете включити відстеження налагодження в
.gitlab-ci.yml
, ця опція доступна в GitLab Runner починаючи з версії 1.7. Вона включає трасування shell, в результаті чого в логи збірки додається інформація про виконання всіх команд, присвоювання значень всіх змінних і т. д.
Перед підключенням даної опції переконайтеся, що логи збірки можуть проглядати тільки члени команди. Також, не забудьте видалити всі згенеровані логи перед тим, як знову відкриєте видимість для всіх.
Для ввімкнення відстеження налагодження назвіть змінної `CI_DEBUG_TRACE значення true:
job1:
variables:
CI_DEBUG_TRACE: "true"

Більш детальна інформація в документі з відстеження налагодження
Відключення операцій Git в CI
З'явилася можливість відключення операцій Git для прискорення збірок, які не потребують взаємодії з репозиторієм. Для цього потрібно вказати стратегію Git у файлі
.gitlab-ci.yml
:
variables:
GIT_STRATEGY: none

детальніше про стратегіях Git в CI можна почитати в нашій документації
Дата розгортання в мерж-реквестах
Невелике, але приємне нововведення — тепер дата розгортання вказується прямо в мерж-реквесте.
See when a deploy happened in GitLab 8.13
GitLab Runner
Також, разом з GitLab 8.13 був випущений GitLab Runner 1.7. Список найбільш цікавих змін:
  • Додано використання Go 1.7 — додає підтримку Runner на Mac OS X Sierra !323
  • Додана GIT_STRATEGY=none !332
  • Додана підтримка OffPeak для автоскейлинга !345
  • Введена змінна для включення режиму трасування shell в bash, cmd.exe і powershell.exe !339
  • В першу чергу завантажується конфіг InCluster, якщо завантаження невдала — конфіг kubectl !327
  • Godep: github.com/Sirupsen/logrus оновлено до версії 0.10.0 !344
  • Додано використання
    git clone –no-checkout
    та
    git checkout –force
    !341
  • Значення поля runner тепер переводиться в нижній регістр для сумісності з обмеженнями GCE !297
  • Додана обробка before_script при виконанні команди exec !355
  • Складання більше не позначаються як невдалі через помилки кешування !359
  • Внесені поліпшення в процедуру реєстрації !356
Повний список змін можна подивитися в чейнджлоге Runner'а.
GitLab Mattermost
У GitLab 8.13 включений Mattermost — альтернатива Slack з відкритим вихідним кодом, доступна на інтернеті, десктопі і мобільних усторйствах і інтеграцією більш ніж з 700 додатками за допомогою Zapier. У цьому місяці додана інтеграція з Slack, Gitter, XMPP і IRC. Mattermost тепер оновлюється 6 разів на рік; нові оновлення додаються в GitLab через місяць після їх виходу.
Нововведення в API
В даний реліз включено кілька нововведень в API:
Одночасний комміт кількох файлів
Завдяки MVP місяця Марку з'явилася можливість здійснювати через API комміт декількох файлів одночасно.
Документація по API на цю тему
Інтерфейс дошки завдань
Андре Гуэдэс (Andre Guedes) реалізував повноцінний API для дошки завдань. Спасибі, Андре!
Інформація про дії користувачів
З допомогою API тепер можна отримати інформацію про зміни, внесені в проект певним користувачем.
Документция на цю тему
Список видимих проектів
Завдяки Бену Бекелю (Ben Boeckel) з'явилася можливість переглянути список всіх видимих вам проектів через API.
Більше інформації в документації по API
Зміни в продуктивності
Зміни в CE:
  • Покращена продуктивність відображення сторінки group milestones: !6457
  • Зменшено кількість виконуваних запитів при обробці посилань Markdown: !6457 і !6545
  • Sidekiq тепер використовує пул зв'язків при роботі з кешем Rails: !6468 і !6657
  • Зменшено кількість оновлень таблиці
    ci_runners
    , завдяки чому зменшено кількість звернень до бази даних: !6537
  • Трохи зменшено кількість виконуваних запитів при пуше комітів: !6680
  • Додано щоденний попередній підрахунок рейтингу проектів для сторінки trending projects, що підвищує її продуктивність: !6749
  • Додана асинхронне завантаження diff'ів при створенні нового мерж-реквеста: !5844
  • При зміні timestamp'а останніх змін проекту більше не використовуються тимчасові посилання (leases) Redis: !6678
  • Секретний токен для gitlab-shell і API тепер зберігається в пам'яті, а не читається з диска при кожному запиті API: !6599
  • Зменшено кількість запитів, які використовуються при перевірці політик проекту: !6442
  • Worker, використовуваний для минає артефактів складання, тепер ефективніше розподіляє завдання і використовує більш ефективні запити SQL: !6732
  • Оновлення мерж-реквестов з допомогою пушей тепер використовують спеціальний Sidekiq worker: !6767
  • Хуки конвеєра CI тепер оновлюються асинхронно: !6824
  • Метрики конвеєра CI тепер оновлюються за допомогою Sidekiq worker: !6896
  • Покращена продуктивність і використання пам'яті завантажувача GitHub: !6552
  • Оптимізовано отримання URL для відтворення emoji в обговореннях.: !6848
  • При створенні проекту ми автоматично створюємо відповідний рядок
    project_features
    замість перевірки цього (і створення рядка при необхідності), коли б ми не просили проект бази даних. Це зменшує кількість запитів до бази даних, коли нам потрібно повернути проект з версії 2 в 1: !6908
  • Коміти конвеєра CI оновлюються тільки після створення конвеєра замість оновлення кожного окремо: !6986
  • Тривалості конвеєра CI оновлюються тільки в кінці конвеєра замість оновлення після кожного зміни стану: !6987
  • Оновлення кешу проекту тепер відбувається кожні 15 хвилин. Статистика може стати несвіжої (наприклад, підрахунок комітів), але істотно зменшиться навантаження на диск: !7017
  • Sidekiq тепер використовує різні черги для великої кількості різних працівників: !7006
  • Завдання в конвеєрі CI розподіляються розумніші, запобігаючи призначення декількох задач з одними і тими ж параметрами в один і той же час: !7005
  • Кешування полів markdown в базі даних !6095
Зміни в EE:
  • Дані про використання GitLab тепер кешуються: !779
Зміни в gitlab-shell:
  • Відстеження продуктивності Git тепер може бути включено за допомогою змінної оточення: !91
  • Покращено переміщення репозиторіїв між шардами: !97 і !96
Зміни пакета Omnibus GitLab
  • Jemalloc тепер використовується як аллокатор пам'яті за замовчуванням, що має знизити обсяг використовуваної пам'яті.
  • пакетного NGINX тепер є метод Status, включений за замовчуванням. Спасибі Luis Sagastume!
  • Нові опції конфігурацій додано в файл gitlab.rb
Інші зміни
В цьому релізі багато інших змін, включаючи різні виправлення безпеки. Щоб подивитися всі зміни, зверніться до changelog.
Барометр оновлень
Цей реліз містить значну кількість міграцій, які вимагають даунтайма. Адміністратори повинні приготуватися мінімум до 30 хвилин простою. Невеликі установки (наприклад, з кількома сотнями проектів) повинні завершувати процес міграцій за 5-10 хвилин.
Пам'ятайте, що ці оцінки часу приблизні і можуть відрізнятися в залежності від вашої ситуації.
Деякі з міграцій:
  • додають зовнішні ключі в існуючі таблиці
  • переміщують завдання Sidekiq з однієї черги до іншої
  • видаляють повторювані мітки (labels)
  • встановлюють пріоритети ярликів
  • виробляють інші чищення даних
Черзі Sidekiq
Цей реліз вніс кілька змін в Sidekiq. Раніше GitLab використовував обмежена кількість черг, яке було жорстко визначено в
bin/background_jobs
та Omnibus GitLab. Починаючи з версії 8.13 всі назви використовуються черг знаходяться в
config/sidekiq_queues.yml
. Користувачам, що використовують
bin/background_jobs
для запуску Sidekiq або Omnibus GitLab, більше не потрібно нічого робити вручну. Користувачам, запускає установку з исходников, потрібно внести зміни в налаштування, щоб упевнитися, що Sidekiq використовує цей конфігураційний файл. Для цього їм потрібно переконатися, що Sidekiq запускається наступним чином:
sidekiq -C path/to/gitlab/config/sidekiq_queues.yml
Якщо ви використовуєте кастомный файл конфігурації Sidekiq, вам потрібно додати зміст
sidekiq_queues.yml
в цей файл (і підтримувати його актуальним) або використовувати
sidekiq_queues.yml
та визначити кастомні налаштування за допомогою CLI (command line interface) для
sidekiq
.
Цей файл конфігурації також визначає вагу кожної черги. Навантаження на Redis трохи збільшиться, але Sidekiq тепер більш справедливо розподіляє роботу замість обробки черг по порядку. Назви та пріоритети черг можуть бути налаштовані користувачем.
Ще дещо
Ми припускаємо, що ви оновлюйтеся з останньої версії. Якщо це не так, ознайомтеся з барометрами оновлення проміжних версій, які ви пропускаєте. Якщо ви оновлюйтеся з 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 і sgnl_05.
Джерело: Хабрахабр

0 коментарів

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