Проекти и про рішення щодо створення сервісу спільної розробки Git Forge, який буде збудовано з використанням платформи GitLab. GitLab стане первинною платформою для взаємодії з Git-репозиторіями та для хостингу проектів, пов'язаних із дистрибутивами CentOS та Fedora. Раніше використовуваний сервіс продовжить існувати, але буде передано на опіку спільноті, зацікавленій у продовженні розробки. Pagure буде виведено з-під супроводу працевлаштованої в Red Hat команди CPE (Community Platform Engineering), що займається підтримкою інфраструктури для розробки та публікації релізів Fedora та CentOS.
При оцінці можливих рішень для нового Git Forge розглядалися
Pagure та Gitlab. На підставі вивчення близько та побажань від учасників проектів Fedora, CentOS, RHEL та CPE, були сформовані вимоги до функціональності та зроблено вибір на користь Gitlab. Крім типових операцій з репозиторіями (злиття, створення форків, додавання коду тощо) серед ключових вимог було заявлено безпеку, зручність роботи та стабільність платформи.
До вимог увійшли такі можливості, як відправлення push-запитів по HTTPS, засоби обмеження доступу до гілок, підтримка приватних гілок, поділ доступу зовнішніх та внутрішніх користувачів (наприклад, для роботи над усуненням уразливостей під час ембарго на розкриття відомостей про проблему), звичність інтерфейсу, уніфікація підсистем для роботи з повідомленнями про проблеми, код, документацію та планування нових можливостей, наявність засобів для інтеграції з IDE, підтримка типових робочих процесів.
З можливостей GitLab, які остаточно вплинули на ухвалення рішення щодо вибору даної платформи, згадані підтримка підгруп з вибірковим доступом до репозиторій, можливість використання бота для автоматичних злиття (потрібно CentOS Stream для підтримки пакетів з ядром), наявність вбудованих засобів для планування розробки, можливість готового SAAS-сервісу з рівнем доступності, що гарантується (дозволить звільнити ресурси на підтримку серверної інфраструктури).
Рішення вже критику серед розробників, пов'язану з тим, що рішення було ухвалено без попереднього широкого обговорення. Також було висловлено побоювання, що сервіс не використовуватиме вільну Comminity-редакцію GitLab. Зокрема, можливості, необхідні для реалізації описаних в анонсі вимог до Git Forge, доступні лише у пропрієтарній версії .
Критиці також зазнав намір скористатися сервісом SAAS (додаток як сервіс), що надається компанією GitLab, замість розгортання GitLab на своїх серверах, що виводить сервіс з-під контролю (наприклад, неможливо бути впевненим, що всі вразливості в системі оперативно усуваються, підтримується інфраструктура, одного разу не буде і виключено диверсію з боку персоналу сторонньої компанії). Рішення також не поєднується з , в яких визначено, що проект має надавати перевагу вільним альтернативам.
Тим часом компанія GitLab про відкриття реалізацій 18 функціональних можливостей, які раніше пропонувалися тільки в пропрієтарних редакціях GitLab. Можливості охоплюють різні області управління повним циклом розробки програмного забезпечення, включаючи планування розробки, створення проектів, верифікацію, роботу з пакетами, формування релізів, налаштування та захист.
До вільних переведені такі функції:
- Прикріплення пов'язанихзасобів;
- Експорт issue з GitLab до CSV;
- Режим планування, упорядкування та візуалізації процесу розробки окремих функціональних можливостей чи релізів;
- Вбудована сервісна служба для зв'язування учасників проекту із сторонніми особами за допомогою електронної пошти.
- Web-термінал для Web IDE;
- Можливість синхронізації файлів для тестування змін у коді у web-терміналі;
- Засоби управління дизайном, що дозволяють завантажувати в issue макети та ресурси, використовуючи issue як єдину точку доступу до всього, що потрібне для розробки нової можливості;
- Звіти про якість коду;
- Підтримка пакетних менеджерів Conan (C/C++), Maven (Java), NPM (node.js) та NuGet (.NET);
- Підтримка канаркових розгортань, що дозволяють встановити нову версію програми на невеликій частині систем;
- Інкрементальні поширення, що дозволяють спочатку доставити нові версії лише для небагатьох систем, поступово доводячи охоплення до 100%;
- Прапори активації функціональності, що дають можливість постачати проект у різних редакціях, динамічно активуючи певні можливості;
- Оглядовий режим розгортань, що дозволяє оцінити стан кожного оточення безперервної інтеграції з урахуванням Kubernetes;
- Підтримка визначення кількох кластерів Kubernetes у конфігураторі (наприклад, можна використовувати окремі кластери Kubernetes для пробних впроваджень та робочих навантажень);
- Підтримка визначення політик мережевої безпеки контейнерів, що дозволяють розмежувати доступ між подами Kubernetes.
Додатково можна відзначити оновлень GitLab 12.9.1, 12.8.8 та 12.7.8 (Community Edition та Enterprise Edition), у яких усунуто вразливість. Проблема проявляється починаючи з випуску GitLab EE/CE 8.5 і дозволяє прочитати вміст будь-якого локального файлу при переміщенні між проектами.
Деталі про вразливість буде розкрито через 30 днів.
Джерело: opennet.ru