В GitLab 12.4 появилось несколько улучшений в сфере управления, включая Audit API, утверждение от владельца кода для защищенных веток и контроль доступа для Pages. Зависимости мердж-реквестов помогают управлять работой в командах, а другие замечательные фичи позволяют работать эффективнее и быстрее поставлять ПО лучшего качества.
Зависимости мердж-реквестов
GitLab улучшает прозрачность, совместную работу и продуктивность. Когда разработчики вместе работают над большим проектом, небольшие изменения часто нужно применять в определенной последовательности. Чтобы упросить эту задачу, функция зависимости мердж-реквестов позволяет определять зависимости в мердж-реквестах, чтобы изменения не поступали в хаотичном порядке и можно было видеть все зависимости во время ревью кода. Эта фича была представлена как зависимости мердж-реквестов между проектами в релизе 12.2, но теперь переименована в зависимости мердж-реквестов и поддерживает больше типов зависимостей. Сюда входят зависимости мердж-реквестов как между проектами, так и в одном проекте.
Мы понимаем, как важно всем управлять. Вот несколько улучшений в релизе 12.4, с которыми управление станет проще.
Audit Events API
GitLab помогает обеспечить полную прозрачность всего жизненного цикла обработки и при этом оптимизировать процессы. Поэтому GitLab хорошо сочетается с другими решениями, и в версии 12.4 мы представляем API для событий аудита на уровне экземпляра. Audit Events — это эффективный инструмент контроля соблюдения политик. Используя Audit Events API, администраторы могут с помощью кода получать события и настраивать эффективные оповещения и мониторинг в зависимости от конкретных потребностей.
Контроль доступа к Pages на GitLab.com
Контроль доступа для Pages был доступен для самоуправляемых экземпляров, а теперь предоставляется на GitLab.com. Он позволяет авторизованным администраторам ограничивать доступ к сайту Pages или делать его общедоступным. Все это благодаря работе сообщества, и мы очень рады, что включили эту функцию на GitLab.com!
Утверждение от владельца кода для защищенных веток
Еще одна фича для управления — утверждения от владельцев кода для защищенных веток. Утверждение мердж-реквестов ограничивает отправку кода в защищенные ветки, и это позволяет повысить качество кода и реализовать меры контроля за соблюдением требований. Но не все мердж-реквесты предназначены для стабильных веток и не все стабильные ветки требуют одинакового контроля. В GitLab 12.4 можно предотвращать отправку изменений в файлы напрямую или слияние изменений без одобрения владельца кода для определенных веток.
И это еще не все!
В GitLab 12.4 столько классных фич, что обо всех рассказать просто невозможно. Вот лучшие из них: уведомления для релизов, возможность просматривать логи подов из любой среды и поддержка частных проектов для онлайн-просмотра HTML-артефактов. Продолжайте читать и узнайте больше о каждой фиче.
Обязательно почитайте, как прошла наша первая Европейская конференция пользователей 9 октября. Следующая конференция пользователей GitLab состоится в январе в Сан-Франциско. Регистрация уже открыта.
Самый ценный сотрудник этого месяца (MVP) — Туомо Ала-Ваннеслуома (Tuomo Ala-Vannesluoma).
Благодаря Туомо в GitLab 12.4 есть поддержка частных проектов для просмотра HTML-артефактов, о которой все давно мечтали и которая набрала почти 300 голосов! Туомо уже во второй раз становится самым ценным сотрудником месяца — в GitLab 11.5 он реализовал контроль доступа для Pages. Спасибо тебе за вклад и за активную работу в этот год. Мы очень это ценим!
Главные фичи GitLab 12.4
Зависимости мердж-реквестов
PREMIUM, ULTIMATE, SILVER, GOLD
Разработчики часто работают вместе над большим проектом, внося небольшие изменения. Эти изменения нужно применять в определенной последовательности, чтобы все работало, как надо, но в этих зависимостях можно запутаться и ошибиться.
Функция зависимостей мердж-реквестов позволяет определять зависимости в мердж-реквестах, чтобы изменения не применялись в неправильном порядке. А еще эти зависимости удобно просматривать в ревью кода, чтобы ревьюерам было проще разобраться во всех предложенных изменениях. Эта фича была представлена в версии 12.2, а в 12.4 она была улучшена и теперь поддерживает зависимости мердж-реквестов в одном проекте.
Audit Events API
PREMIUM, ULTIMATE
Audit Events — это эффективный инструмент для понимания происходящего на GitLab. С помощью событий аудита организации могут контролировать соответствие действий пользователей политикам, а это очень важно для предприятий под строгим надзором.
Чтобы упростить автоматизацию этих задач, мы представляем API для событий аудита на уровне экземпляра. Используя Audit Events API, администраторы могут с помощью кода получать события и настраивать эффективные оповещения и мониторинг в зависимости от конкретных потребностей организации.
Утверждение от владельца кода для защищенных веток
PREMIUM, ULTIMATE, SILVER, GOLD
Утверждение мердж-реквестов ограничивает отправку кода в защищенные ветки, и это позволяет повысить качество кода и реализовать меры контроля за соблюдением требований. Но не все мердж-реквесты предназначены для стабильных веток и не все стабильные ветки требуют одинакового контроля.
В GitLab 12.4 можно требовать утверждения от владельца кода для некоторых веток, чтобы предотвратить отправку изменений в файлы напрямую или слияние изменений без утверждения владельца кода.
Если владелец кода должен был утверждать изменения в предыдущих параметрах проекта, эти настройки применяются к существующим защищенным веткам.
Контроль доступа для Pages теперь включен на GitLab.com
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Контроль доступа для Pages позволяет авторизованным администраторам ограничивать доступ к сайту Pages или делать его общедоступным. Теперь для доступа к контенту, опубликованному частными проектами, может требоваться логин и пароль, чтобы защитить содержимое опубликованного сайта, поэтому стало проще публиковать служебную документацию и контролировать к ней доступ.
Посмотрите короткий ролик о контроле доступа для Pages.
Уведомления о релизах
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Теперь можно подписываться на новости о новых релизах в проекте, чтобы узнавать о новых версиях даже для проектов, в которых вы не участвуете. С помощью этой фичи можно следить за новыми релизами проектов, от которых вы зависите, не проверяя их вручную.
Посмотрите короткий ролик об уведомлениях о релизах.
Просмотр логов подов из любой среды
ULTIMATE, GOLD
Раньше логи GitLab, в основном, просматривали на странице Environments. Поэтому было сложно переключаться между логами из разных сред для устранения неполадок. Кроме того, нужно было сначала войти в определенную среду.
В GitLab 12.4 вы можете просматривать любые логи из любой среды или пода. На странице сред теперь есть две кнопки для просмотра любых логов подов из кластеров Kubernetes. Мы продолжим совершенствовать доступ к логам, например, включим ссылку на логи Logging прямо в меню Operations.
Другие улучшения в GitLab 12.4
Использование Jaeger в интерфейсе GitLab
ULTIMATE, GOLD
Трассировака предоставляет сведения о производительности и работоспособности развернутого приложения, отслеживая каждую функцию или микросервис, который обрабатывает определенный запрос.
Jaeger — это открытая комплексная система распределенной трассировки, которая используется для мониторинга и устранения неисправностей распределенных систем на основе микросервисов.
С GitLab 12.4 пользователи, которые используют Jaeger, могут просматривать сведения о производительности и работоспособности развернутых приложений прямо в интерфейсе GitLab.
Поддержка расширения переменных для пайплайнов с несколькими проектами
PREMIUM, ULTIMATE, SILVER, GOLD
Если у вас пайплайны с несколькими проектами, и один пайплайн запускает другой, бывает полезно хранить динамическое значение в переменной выше, чтобы ссылаться на нее в нижестоящих пайплайнах. Например, если пайплан выполняется в ветке, и вы хотите предоставить доступ к $CI_COMMIT_REF_NAME в этой ветке для всех нижестоящих пайплайнов.
Раньше переменная не расширялась, поэтому вызов переменной в нижестоящих пайплайнах через ключевое слово trigger приводил к ошибке no ref name. Чтобы осуществить такой рабочий процесс, требовалось создавать отдельное задание с единственной целью — выполнить команду c URL для передачи состояния переменной. Такое обходное решение требовало дополнительной настройки и ресурсов, а еще затрудняло просмотр отношений между пайплайнами в пользовательском интерфейсе.
Теперь GitLab будет расширять переменные внутри свойства branch ключевого слова trigger, и вам будет проще организовывать пайплайны и налаживать их последовательный запуск при использовании нескольких проектов.
DAST для главной ветки
ULTIMATE, GOLD
С радостью объявляем, что сканы DAST теперь можно выполнять для ветки проекта по умолчанию внутри специального приложения для ревью. Раньше DAST был доступен только веткам фич. Это улучшение позволяет создать контрольные результаты DAST для ветки по умолчанию, с которыми будут сравниваться мердж-реквесты. Теперь можно выявить ту самую ветку, в которой появились новые проблемы с безопасностью.
Проверка существования файлов в пайплайнах
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Мы дополняем синтаксис rules:, впервые представленный в GitLab 12.3, новым правилом rules:exists, которое принимает массив путей и проверяет, существуют ли эти пути в виде файлов в репозитории. Это полезно, когда вам нужно запустить задание CI только в том случае, если определенные файлы существуют. Например, вы запускаете пайплайн tests, только если есть файл tests.yml. Это правило ускоряет пайплайны, потому что пропускает лишние этапы.
Нативная поддержка Geo для репликации хранилища объектов
PREMIUM, ULTIMATE
В GitLab 12.4 Geo нативно поддерживает репликацию данных в хранилище объектов, например объекты LFS, артефакты заданий и загрузки. Раньше Geo можно было настроить для работы с хранилищем объектов, но репликация содержимого всегда оставалась за поставщиком хранилища объектов. Это накладывало определенные ограничения, когда пользователям приходилось полагаться на локальное оборудования для хранилища, которое не поддерживало логику репликации.
Нативная поддержка Geo позволяет реплицировать данные по разным поставщикам хранилища объектов в разных регионах (например, Amazon в Европе и Microsoft в США). Пользователи Geo могут использовать и локальное хранилище, например через MinIO, и с помощью Geo реплицировать данные на вторичные узлы.
Нативная поддержка Geo для репликации хранилища объектов пока представлена в бета-версии и еще не готова для рабочей среды.
Улучшенная обработка больших файлов через Git Partial Clone (альфа)
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Обычно мы не рекомендуем хранить большие двоичные файлы в Git, иначе репозиторий разрастается, а клонирование и получение изменений занимает очень много времени. Мы предложили Git LFS, чтобы хранить большие файлы за пределами репозитория Git и загружать их по требованию.
В GitLab 12.4 мы добавляем экспериментальную поддержку частичного клонирования Partial Clone, с которым большие файлы можно исключить при клонировании репозитория и получении изменений. Теперь не придется выбирать, какие файлы хранить в Git, а какие — вне репозитория с помощью Git LFS. Поддержка Partial Clone отключена по умолчанию, но ее можно включать в отдельных проектах. Требуется версия Git не ниже 2.22.0.
По сравнению с Git LFS, когда большим файлам требовалось особое внимание при создании коммита, Partial Clone позволяет разработчикам, CI-раннерам или другим клиентам Git указывать, какие файлы нужно загрузить. Теперь можно не рассказывать людям, какие файлы нужно отправлять в Git LFS, не будут возникать проблемы с попыткой переписать историю и перенести большие файлы в Git LFS, и можно будет избежать неприятностей со случайной отправкой большого файла в репозиторий Git, когда ему самое место в Git LFS. Большие файлы просто будут работать и так.
Выбор дат для Productivity Analytics
PREMIUM, ULTIMATE, SILVER, GOLD
Раньше нельзя было выбрать конкретный диапазон дат для метрик в аналитике цикла и производительности. То есть нельзя было изучить или включить в отчет производительность во время конкретного спринта или периода, потому что можно было выбрать только заданный интервал: 7, 30, 60 или 90 дней. В этом релизе пользователи могут просматривать данные за любой отрезок времени.
Виртуальное частное облако по умолчанию при создании кластера GKE на GitLab
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Google Kubernetes Engine позволяет создавать кластеры для виртуальных частных облаков, которые используют IP-псевдонимы и предоставляют интегрированную поддержку виртуальных частных облаков для контейнерных сетей, в результате чего получается более масштабируемая, безопасная и простая система, которая подходит для сложных развертываний и сценариев.
Начиная с GitLab 12.4 в интеграции GitLab с GKE это будет параметр по умолчанию при создании кластера GKE.
Ограничение разрешений для заданий CI, выполняемых вручную
PREMIUM, ULTIMATE, SILVER, GOLD
Разработчикам часто приходится создавать задания, которые выполняются вручную, например, для развертываний, нестрогого одобрения и других операций, но в GitLab неочевидно, как ограничить эти разрешения, чтобы эти действия не мог выполнять кто угодно.
Вообще-то это уже было возможно, но без четкой документации. В этом релизе мы значительно улучшили документацию для защиты выполняемых вручную заданий, чтобы было понятно, как их настраивать.
Удаление дизайнов в Design Management
PREMIUM, ULTIMATE, SILVER, GOLD
Иногда случаются ошибки или меняются цели дизайна и нужна возможность удалить дизайн из версии. С помощью функции удаления в Design Management можно выбрать один или несколько дизайнов и удалить их из последней версии. Теперь последняя версия дизайна будет представлять настоящее положение дел.
Дополнение API для сред и развертываний
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Мы добавили функцию API, которая будет возвращать атрибуты сред state (состояние) и last deployment (последнее развертывание). Эту информацию можно использовать, например, при написании скрипта для удаления неиспользуемых сред.
Улучшенная документация по апгрейду Geo
PREMIUM, ULTIMATE
В рамках нашей работы по упрощению процесса апгрейда Geo мы переделали большие части соответствующей документации. GitLab Geo можно развертывать в разных конфигурациях, и процедура апгрейда зависит от этих конфигураций. Сейчас апгрейд Geo во многом выполняется вручную и состоит из множества этапов. Чтобы упростить этот процесс в целом, мы сначала взялись за улучшение документации по апгрейду Geo. Теперь документация актуальна и охватывает все сценарии.
Мы переписали общие инструкции по обновлению, заархивировали старые инструкции, обновили инструкции по апгрейду без простоя для простых развертываний и пересмотрели многие другие разделы документации.
Мы работаем над инструкциями по обновлениям без простоя для высокодоступного кластера Geo со множеством узлов; но пока еще тестируем их.
Затем мы займемся улучшением автоматизации и тестирования и сделаем некоторые процедуры апгрейда более эффективными.
Ссылки на мердж-реквесты теперь отображаются в представлении пайплайна
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
При просмотре пайплайна иногда хочется перейти к связанным с ним мердж-реквестам. Мы добавили прямые ссылки на них, чтобы упростить работу и повысить продуктивность.
Вставка заданий в начало или конец пайплайна с помощью include
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Чаще всего include используется для добавления задания в начало или в конец пайплайна. Но если у вас общий include, вы можете не знать, как называется первый или последний этап, поэтому с заданием в начале или в конце пайплайна могут возникнуть проблемы.
В GitLab 12.4 этапы .preи .post гарантируют запуск в начале или в конце пайплайна.
Обновление приложения Kubernetes NGINX Ingress при установке через интеграцию с Kubernetes
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Когда ваши приложения, развернутые в Kubernetes, работают в последней версии, вы используете преимущества новейших функций и актуальных средств безопасности. GitLab 12.4 позволяет использовать последнюю версию NGINX Ingress при установке через GitLab Managed Apps. Чтобы обновить существующую версию, удалите приложение Ingress и снова установите его через GitLab.
Конечная точка API для статических имен проверки статуса в интеграции GitHub
PREMIUM, ULTIMATE, SILVER, GOLD
Теперь можно настроить статические имена проверки статуса в интеграции GitHub через API, чтобы было проще менять этот параметр в большом количестве проектов.
GitLab Runner 12.4
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Сегодня мы выпустили GitLab Runner 12.4! GitLab Runner — это проект с открытым исходным кодом, который используется для запуска заданий CI/CD и отправки результатов обратно в GitLab.
Изменения:
- Дополнена конфигурации пользовательского исполнителя.
Можно использовать certutil, чтобы создать цепочку сертификатов для Git.- Используемая версия Go увеличена до 1.10.8.
- Клиентская библиотека Kubernetes обновлена до 11.0.
- Добавлено время ожидания для окончания сборки.
Полный список изменений можно найти в журнале изменений GitLab Runner: CHANGELOG.
Улучшения производительности
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Мы продолжаем улучшать производительность GitLab с каждым выпуском для экземпляров GitLab любого размера.
Некоторые улучшения в GitLab 12.4:
- Число комментариев для комментируемых элементов ограничено до 5000.
- Заголовки кэша для аватаров устанавливаются правильно при использовании хранилища объектов и загрузках через прокси.
- Ускорен Jira DVCS API для Jira Server.
- Автоответчикам в электронной почте теперь запрещено добавлять комментарии к задачам.
- Ограничена область поиска сниппетов.
- Ограничено количество результатов поиска для сниппетов.
- Добавлен триграммный индекс в контент сниппетов.
- Значительно сокращено время загрузки для рендерера markdown.
Админы могут отменять ограничения размера артефактов в проектах или группах
CORE, STARTER, PREMIUM, ULTIMATE
Сейчас по умолчанию максимальный размер артефакта составляет 100 МБ, но в некоторых проектах нужно выйти за пределы этого ограничения (по усмотрению администратора). Для этого мы добавили возможность переопределять лимит размера артефактов на уровне группы или проекта, как для лимита размера репозитория.
Поддержка частных проектов для онлайн-просмотра HTML-артефактов
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Возможность просматривать HTML-артефакты повышает эффективность работы. Эта задача выполняется часто, поэтому нужен способ быстро открывать и просматривать артефакты. Без онлайн-представления приходится загружать артефакт и использовать веб-сервер локально, чтобы просмотреть отчет. Если делать это для каждого HTML-артефакта для всех сборок, потребуется целая куча времени и постоянные переключения между контекстами.
Раньше можно было просматривать HTML-артефакты в окне браузера через GitLab Pages, чтобы не загружать их локально, но эта возможность была только у открытых проектов. Это было неудобно для многий организаций, которые используют GitLab, в основном, для частных проектов. У них такого онлайн-представления не было. А теперь, благодаря стараниям члена сообщества Туомо Ала-Ваннеслуома (Tuomo Ala-Vannesluoma), мы добавили поддержку онлайн-представления HTML-артефактов и для частных проектов. Для этого нужно включить контроль доступа для GitLab Pages.
Включение Cloud Run on GKE при создании кластера через интеграцию с GKE
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
При создании кластера Kubernetes через интеграцию GitLab и GKE пользователи теперь могут по желанию включать «Cloud Run on GKE» одним щелчком. GKE автоматически инициализирует кластер с Knative, Istio и балансировкой нагрузки по HTTP. После установки пользователи могут и дальше наслаждаться преимуществами GitLab Serverless, чтобы развертывать сервисы Knative с минимальной конфигурацией.
Примечание. «Cloud Run for GKE» недавно переименовали в «Cloud Run for Anthos». Мы планируем изменить имя на новое в следующем месяце.
Общие конечные точки для оповещений
ULTIMATE, GOLD
Люди используют разные инструменты для мониторинга сред приложений. Эти инструменты отправляют критические и срочные оповещения, если произошел инцидент и нужно принять меры. Теперь возможности управления инцидентами на GitLab включают общую конечную точку REST, куда можно отправлять оповещения из любого инструмента. Когда GitLab получает запрос POST к этой конечной точке, он автоматически создает задачу для инцидента. В описание задачи входят данные об инциденте, и распространенные поля анализируются автоматически. Поэтому теперь можно использовать задачи GitLab как центральное место для реагирования на инциденты на основе данных от других инструментов.
Посмотрите короткий ролик о добавлении общей конечной точки для оповещений.
Поддержка Geo через единый Git URL с учетом местоположения
PREMIUM, ULTIMATE, SILVER, GOLD
Теперь Geo поддерживает предоставление пользователям единого удаленного URL, который автоматически использует ближайший узел Geo. Это значит, что пользователям не нужно обновлять конфигурацию Git, чтобы использовать ближайшие узлы Geo при перемещении. Конечным пользователям даже необязательно знать, что они используют локальный узел Geo при изначальном клонировании проекта. А системным администраторам не придется поддерживать различные конфигурации Git для пользователей в разных местах. Все это благодаря тому, что push-запросы Git можно автоматически перенаправлять (HTTP) или проксировать (SSH) с вторичных узлов на первичный.
Geo можно настроить для использования разных сервисов, например AWS Route53 или Cloudflare.
Действия Git добавлены в ограничение по IP-адресу группы
ULTIMATE, GOLD
В GitLab 12.0 представлено ограничение действий группы по IP-адресу. В GitLab 12.3 мы включили действия API в ограничение доступа. В GitLab 12.4 мы добавляем действия Git через SSH.
Расширенная возможность теперь отклоняет действия в пользовательском интерфейсе, API и Git, если они не соответствуют ограничению IP-адреса группы. Для организаций, строго соблюдающих нормативные требования, особенно на GitLab.com, это обеспечивает комплексный уровень защиты.
Диаграмма разброса для Productivity Analytics
PREMIUM, ULTIMATE, SILVER, GOLD
Раньше не существовало простого способа визуализировать и измерять скорость с течением времени. Чтобы обеспечить эту возможность, мы добавляем диаграммы разброса в Productivity Analytics, где можно выбрать «Time to Merge» (время слияния) или другие метрики, связанные с мердж-реквестами, чтобы замечать тренды или отклонения. А еще можно подробно изучить конкретный диапазон дат, чтобы проанализировать определенные наборы данных.
API для создания развертываний вручную
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Мы добавили API для создания развертываний. Этот функционал меняет развертывания, и сборка соответствующего CI теперь необязательна. Это необходимо, чтобы заложить фундамент для поддержки внешних сред и развертываний на GitLab.
Установка группового раннера в Kubernetes одним щелчком
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Теперь стало совсем просто создавать общий раннер на уровне группы, если вы используете GitLab с Kubernetes. В проектах уже можно устанавливать раннер одним щелчком, но групповые раннеры приходилось устанавливать вручную. Теперь можно просто нажать на кнопку, и GitLab установит общий групповой раннер автоматически.
Системные заметки для Design Management
PREMIUM, ULTIMATE, SILVER, GOLD
В GitLab 12.2 мы представили первую версию Design Management, которая позволяет загружать дизайны прямо в задачи. Они загружались на отдельную вкладку, и действия по ним не записывались в журнал, поэтому было сложно определить, добавлены ли в задачу дизайны. Начиная с GitLab 12.4 при загрузке дизайнов в треде задачи создаются системные заметки, чтобы уведомить участников. В будущем мы включим в дизайны статусы и число комментариев, чтобы пользователи лучше понимали происходящее.
Статические имена проверки статуса по умолчанию в интеграции с GitHub
PREMIUM, ULTIMATE, SILVER, GOLD
Мы изменили параметр по умолчанию для интеграции с GitHub, чтобы устанавливать static status check names (статические имена проверки статуса) по умолчанию в новых проектах. Когда этот параметр включен на странице интеграции, к имени проверки статуса будет добавляться имя хоста вашего экземпляра GitLab (если выбраны динамические имена, добавляется имя ветки). Это более разумный начальный параметр, который гарантирует обязательные проверки статуса без дополнительной настройки для тех, кто использует GitLab CI/CD в репозитории GitHub.
Выбор и перемещение нескольких карточек задач
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Иногда мелочи очень важны. Если вы начинаете новый спринт или просто любите перетаскивать задачи по доске, вам понравится новая возможность выбирать несколько карточек задач с помощью Cmd + клик на Mac или Ctrl + клик в Windows и перемещать их все сразу в другой список.
Сортировка пакетов в интерфейсе Registry
PREMIUM, ULTIMATE, SILVER, GOLD
В GitLab Package Registry можно собирать, публиковать и отправлять пакеты npm, Maven и (скоро) Conan. GitLab предоставляет пользовательский интерфейс, где отображаются метаданные пакетов и можно легко найти пакеты группы или своего проекта. Но до недавнего времени приходилось прокручивать список пакетов вручную, чтобы найти нужные.
В GitLab 12.4 мы с радостью представляем сортировку в интерфейсе Package Registry, чтобы пакеты было проще искать. Теперь можно сортировать пакеты на уровне проекта и группы по created date (дате создания), name (имени), version (версии) и type (типу). Еще мы работаем над добавлением последнего коммита и ветки и собираемся изменить пользовательский интерфейс, чтобы включить все соответствующие метаданные.
Глобальное представление для сред и развертываний кластера на уровне экземпляра
PREMIUM, ULTIMATE, SILVER, GOLD
Представление Environments появилось в GitLab 12.3 для кластеров на уровне группы. Раздел Environments (Среды) на странице кластера содержит обзор всех проектов, которые используют кластер Kubernetes, включая подготовленные среды и развертывания и число подов в каждой среде. В 12.4 представление Environments доступно для кластеров на уровне экземпляра. Перейдите на страницу экземпляра Kubernetes и откройте вкладку Environments. Для кластеров на уровне группы представление Environments расширено до кластеров на уровне экземпляра.
Раздел Environments (Среды) на странице кластера содержит обзор всех проектов, которые используют кластер Kubernetes, включая подготовленные среды и развертывания и число подов в каждой среде.
S/MIME теперь можно настраивать в Helm-чарте GitLab
CORE, STARTER, PREMIUM, ULTIMATE
Электронная почта с подписью S/MIME повышает безопасность, сокращая поверхность атаки для фишинга, атак типа «человек посередине» и других. И хотя возможность подписывать электронные письма с S/MIME была добавлена в Omnibus в версии 12.3, нельзя было настраивать S/MIME при установке GitLab в Kubernetes. В версии 12.4 параметры S/MIME для уведомлений по электронной почте от GitLab можно настраивать глобально для Helm-чартов GitLab.
Обновление приложения Cert-Manager Kubernetes при установке через интеграцию с Kubernetes
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Если своевременно обновлять сертификаты безопасности для приложений, развернутых в Kubernetes, можно обеспечить их безопасную и стабильную поставку. Начиная с GitLab 12.4 можно обновлять приложение Cert-Manager через интеграцию GitLab с Kubernetes. Чтобы обновиться до последней версии, поддерживаемой GitLab, перейдите на страницу кластера из меню Operations > Kubernetes, удалите и переустановите Cert-Manager.
Улучшения Omnibus
CORE, STARTER, PREMIUM, ULTIMATE
- GitLab 12.4 включает 5.15, альтернативу Slack с открытым кодом. Эта версия Mattermost сосредоточена на повышении качества.
- OpenSSL обновлен до версии 1.1.1d, где исправлено несколько CVE. Больше об изменениях в этом дополнительном релизе можно узнать на веб-сайте OpenSSL.
- Теперь можно пропускать бэкап баз данных во время апгрейда. Бэкапы баз данных могут замедлять апгрейд, и в некоторых случаях лучше пропустить этот шаг, чтобы апгрейд закончился быстрее. Узнайте больше, как пропустить бэкап баз данных при апгрейде, в документации по апгрейду Omnibus. Если вы пропустили автоматические бэкапы, **не забудьте сделать это вручную до апгрейда***.
Устаревшие фичи
Let’s Encrypt заблокирует версии Cert-Manager до 0.8.0 с 1 ноября
До GitLab 12.4 интеграция с Kubernetes позволяла устанавливать Cert-Manager v0.5.2 на кластер Kubernetes. Let’s Encrypt будет блокировать запросы от версий Cert-Manager ниже 0.8.0 с 1 ноября 2019 года. Нужно удалить Cert-Manager и установить его снова. Не забудьте сделать бэкап дополнительных конфигураций до апгрейда на случай потери данных.
Дата удаления: 1 ноября 2019 г.
Конфигурация резервных путей перенесена из gitlab.rb в пользовательский интерфейс GitLab
Конфигурация резервных путей перенесена в пользовательский интерфейс GitLab, и теперь все параметры, связанные с троттлингом, можно настраивать в одном месте. Раньше ограничения для пользователей и IP задавались в интерфейсе, а резервные пути указывались в /etc/gitlab/gitlab.rb. Настройка резервных путей в gitlab.rb считается устаревшей в GitLab 12.4 и будет удалена в GitLab 13.0. Чтобы узнать больше о том как настраивать резервные пути в интерфейсе и перенести настройки троттлинга для резервных путей из Omnibus GitLab 12.3 (или предыдущих версий) в пользовательский интерфейс, изучите документацию по резервным путям.
Дата удаления: GitLab 13.0
Elasticsearch 5.6 больше не поддерживается
Мы продолжаем совершенствовать интеграцию с Elasticsearch и прекращаем поддержку Elasticsearch 5.6.x с релиза GitLab 12.7. Elasticsearch 5.6 достиг конца срока службы после релиза Elasticsearch 7.x.
Обновленные требования к версии для GitLab 12.7 будут включать поддержку только для Elasticsearch 6.x. Пока мы не можем сказать, когда будем поддерживать Elasticsearch 7.x на GitLab. Следите за этой задачей. GitLab рекомендует клиентам с самоуправляемыми экземплярами обновиться до ElasticSearch 6.x.
Дата удаления: 22 января 2020 г.
Прекращается поддержка openSUSE Leap 15.0
Срок службы openSUSE 15.0 заканчивается в конце ноября 2019 года. GitLab 12.5 не будет поддерживать openSUSE 15.0. В задаче 4404 отслеживается работа по сборке пакетов для openSUSE Leap 15.1.
Дата удаления: GitLab 12.5
Важные примечания об обновлении до GitLab 12.4
- GitLab 12.4 устанавливает Knative 0.7 в качестве управляемого приложения GitLab. Примечание. GitLab Serverless все еще находится в альфа-версии. Если возникнут проблемы с предыдущими версиями Knative, обратитесь в службу поддержки GitLab.
- Начиная с GitLab 12.4 интеграция с Kubernetes будет устанавливать Cert-Manager v0.9.1. Если вы уже установили Cert-Manager через интеграцию с Kubernetes, у вас будет более старая версия. Let’s Encrypt заблокирует старые версии с 1 ноября 2019 года. Подробности читайте в уведомлении об устаревших версиях Cert-Manager. GitLab 12.3 обновляет Cert-Manager до версии 0.9.1 при установке через интеграцию с Kubernetes. Если вы используете более старую версию Cert-Manager (установленную через интеграцию с Kubernetes), нужно будет удалить старую версию и установить самую новую.
- Для упрощения больших миграций в этом релизе мы представили фоновые миграции. Фоновые миграции — это задачи Sidekiq, которые выполняются асинхронно. На GitLab.com эти миграции занимали примерно 36 часов без побочных эффектов. Чтобы узнать примерное время в часах, нужно выполнить эти миграции в вашем экземпляре. Выполните следующую команду в консоли
Rails: (Project.count.to_f / 300_000).ceil. Проверьте статус фоновых миграций этой командой в консолиRails: Sidekiq::Queue.new('background_migration').size.
