Привет! Я Максим Рязанцев, DevOps-специалист в AGIMA. На днях GitLab выкатил новую версию — версию 15.8. Мы с коллегами внимательно ее изучили, разобрались, что нового. И теперь решили поделиться списком улучшений. Тем более что список внушительный. Правда, самые заметные изменения в касаются только облачной Ultimate-версии. Но мы-то знаем, что со временем фичи с облака мигрируют в Self-Managed-версию. Так что коротко расскажем обо всех новинках.
В версию 15.8 добавили фичу, которая блокирует мерж-реквест, если какие-то внешние сервисы недоступны. Фича будет полезна при проверке сервисов, нужных для сборки. Если сервисы доступны — сборка пройдет успешно. Если недоступны — система уведомит вас. Еще фича поможет в случае, если в мерж-реквесте появится новый функционал, которому нужны новые сервисы. Перед мерж-реквестом их хорошо бы проверить, и теперь GitLab сделает это за вас.
Теперь переносить проекты между GitLab-инстансами можно путем прямого переноса. Раньше, чтобы перенести проект, нужно было сначала скопировать его на локальную машину, создать новый проект в GitLab, а потом запушить в него скопированную версию. А теперь это просто кнопка Import Groups. Фича доступна во всех версиях облачного GitLab.
Поддержка SCIM для версии Self-Managed. Теперь в ней поддерживается стандарт кросс-доменной идентификации. Это позволяет создавать юзеров и деактивированных их в SCIM. Раньше эта функция была доступна только для облачной версии, а теперь переехала в Self-Managed.
В новой версии добавили возможность применять систему единого входа для членов группы выборочно. До этого, когда система единого входа SAML была включена, члены группы на GitLab не могли ее избежать. Система проверяла подлинность каждого участника проекта. Теперь попасть в проект можно без этой проверки, если задать для пользователя нужные параметры. Грубо говоря, теперь система авторизации стала гибче.
Теперь в Self-Managed-версии (Ultimate), когда заходишь в админку, видишь среднее время ожидания раннера. В GitLab пишут, что новая функция позволяет определить расчетное время ожидания. Это значит, что вы сможете заранее выявлять потенциальные проблемы с задачами CI и принять решение об изменениях конфигурации.
Также в новой версии 16 более мелких улучшений. Почти все они доступны во всех версиях GitLab. Вот некоторые из них:
Раньше GitLab проверял токены личного доступа только после начала миграции. То есть процесс уже запущен, время пошло, а система только-только выдала ошибку. Теперь же токен доступа будет проверяться сразу. Это позволяет избежать запуска миграций, которые точно не удастся выполнить.
Ранее запросы на доступ к группе отображались только в разделе «Участники группы». А теперь они автоматически появляются в списке To do владельца группы. Становится заметнее, что кто-то запросил доступ.
Гисты с GitHub теперь можно импортировать в GitLab.
Имя «протухшего» токена теперь будет появляться в уведомлении по электронной почте, чтобы его было проще найти.
Новые шрифты.
Теперь, если у тебя в группе несколько проектов, а ты хочешь мигрировать на другой инстанс, то можно забирать не все проекты.
Теперь GitLab позволяет переносить настройки безопасности. Это еще одно удобство при миграции с GitHub, которое позволяет не переносить настройки вручную.
Добавили в аналитику новые параметры, которые можно мониторить.
Какие еще новшества появились, можно посмотреть в чендж-логе GitLab-раннера. А еще мы рассказываем о разработке и DevOps в телеграм-канале AGIMA Dev.
funca
Gitlab пример продукта, где приоритеты разработки по всей видимости определяются сугубо хотелками кастомеров - кто в текущем сезоне денег занес, туда все и бегут. Как будто у себя ни головы, ни совести.
Тут на днях смотрел как наши девопсы отлаживают конфигурации пайплайнов, тыкаясь в юай этого гитлаба потому, что, говорят, ни тесты на это написать, ни запустить проверку в офлайн, нет ни какой возможности - дескать поломали несколько лет тому назад и не торопятся чинить.
Tony-Sol
Что-то похоже что такие себе девопсы, потому что я в своей практике успешно наворачивал линтеры и анализиторы на .gitlab-ci.yml по схеме (еще не будучи девопсом)
Плюс есть https://github.com/firecow/gitlab-ci-local
Да и поднять локально раннер и на нем потыкаться - не видится большой проблемой
funca
Локальный ранер, не будучи подключенным к серверу, нормально не работает. На самом деле вот ишуя: https://gitlab.com/gitlab-org/gitlab-runner/-/issues/2797 - которой уже скоро шесть лет исполнится и через год она пойдет в школу.
gitlab-ci-runner это альтернативная реализация, написанная за это время, фактически от безысходности, вообще другими людьми, под node.js. Естественно, что в ней не поддерживаются многие синтаксические конструкции, которые понимает настоящий ранер. Часть синтаксиса интерпретируется просто иначе. Поэтому результаты прогона мало что говорят о работоспособности в реальном окружении.
13werwolf13
там где-то рядом ещё ишуя про криво работающий ssh executor и ещё пачка заброшенных без исправления ишшуек. забить болт на много лет на крики о помощи там норма..
Hesed
Саппорт работает точно по тому же принципу. Бизнес захотел "уйти в облака", что подразумевало и миграцию в SaaS гитлаб. Миграция проходила с потерей ~5-7% мердж реквестов и комментариев. Баг удалось локализовать, зарепортить, поговорить с несколькими уровнями саппорта и некоей мадам-архитектором. Баг признан багом, прямым текстом назван ценник за устранение в течение полугода-года, а иначе никаких гарантий. Спасибо, остались на self hosted.