GitLab 13.9 уже доступен — с улучшениями DevSecOps, панелью оповещений безопасности для обработки приоритетных уведомлений, режимом обслуживания для постоянной поддержки распределённых команд, улучшенной видимостью, включая расширенную поддержку метрик DORA, а также продвинутыми возможностями автоматизации, которые помогут вам поставлять более качественные продукты быстрее. Это лишь некоторые из более чем 60 новых фич и улучшений в этом релизе.
Улучшения DevSecOps
Поддержание продакшен-окружения безопасным и доступным — крайне важные задачи, но их может быть непросто совместить. Наша новая панель оповещений безопасности поможет вам найти баланс между безопасностью и надёжностью благодаря обнаружению подозрительной сетевой активности, которая должна быть заблокирована немедленно или же требует дополнительного внимания, что сведёт к минимуму перебои в работе для пользователей. Мы также рады представить поддержку JavaScript и Python для фаззинг-тестирования по покрытию, результаты которого будут загружены в вашу панель управления безопасностью. Это облегчит создание безопасного и надёжного программного обеспечения.
GitLab создан для распределённых команд. Наш новый режим обслуживания делает возможным доступ к вашему инстансу только на чтение во время выполнения задач администрирования, что позволяет сократить время простоев. Масштабирование и дублирование в хранилище данных оптимизированы благодаря переменным коэффициентам репликации Gitaly, так что вы сможете настроить кластер в соответствии с вашими собственными ограничениями по хранению данных и бюджету, а также включить горизонтальное масштабирование.
Другим важным требованием при масштабировании DevOps является прозрачность, и новая аналитика релизов на уровне группы развивает нашу поддержку метрик DORA с данными, собранными по всем проектам в группе. Новые счётчик непрохождения теста в отчёте юнит-теста и метрика мерж-реквестов (в русской локализации GitLab «запросы на слияние»), среднее время для мержа помогут вам понять и улучшить эффективность мерж-реквестов.
Автоматизируйте ваш путь к более быстрой и качественной поставке
Если вы только начинаете работать с DevOps или продолжаете после не самых успешных попыток, то на первый взгляд может показаться, что призыв поставлять «лучший продукт, быстрее» весьма похож на «делать больше с меньшими затратами», что выглядит весьма противоречиво. Но DevOps — это ответ, а автоматизация — ключ к тому, чтобы повышать скорость и качество.
Одним из верных способов ускорить сборку и тестирование является поиск дубликатов в конфигурации. В 13.9 появилась новая фича, которая сэкономит ваше время, позволив повторно использовать CI/CD конфигурацию любого задания в конвейере (в русской локализации GitLab «сборочная линия»), даже если она находится в другом файле.
Автоматизация в крупных масштабах часто требует минимизации сложности. Если вы разбили конфигурацию конвейера на несколько файлов, вам пригодится возможность просмотреть развёрнутую версию конфигурации. Процессы развёртывания с использованием вложенных или межпроектных конвейеров теперь также могут использовать группы ресурсов для управления параллельностью между этапами, заданиями и даже проектами.
Вклады от нашего сообщества
Мы рады представить поддержку GPU и интеллектуального планирования для обработчика заданий GitLab для специализированных вычислительных нагрузок, например, для машинного обучения; эту фичу внёс MVP этого месяца, Andreas Gravgaard Andersen, который упорно работал над ней на протяжении 10-месячного ревью.
Спасибо также Marshall Cottrell @marshall007 из NASA за создание однострочного установщика для GitLab Kubernetes Agent и упрощение его настройки, благодаря чему пользователям будет намного проще приступить к работе с агентом. Мы очень благодарны Marshall за бесценные отзывы, идеи и сотрудничество, не только в рамках принятых от него мерж-реквестов.
Благодаря ещё одному великолепному вкладу теперь вы можете следить за активностью других пользователей GitLab! Вы можете начать с Roger Meier @bufferoverflow из Siemens, который внёс эту фичу, ведь он и сам находится в зале славы GitLab и является знатоком Open Source и InnerSource.
Спасибо Kev @KevSlashNull из SiegeGG за фильтр активности в отчётах об уязвимостях, который поможет вам детально настроить вид списка уязвимостей. Команда GitLab, отвечающая за безопасность, как и другие наши команды, очень благодарна @KevSlashNull за этот и многие другие вклады.
GitLab — это не только DevOps-платформа или компания, не в последнюю очередь GitLab — это сообщество, и только в релизе 13.9 мы добавили 299 невероятных вкладов, внесённых участниками нашего сообщества. Выбрать одного MVP было нелегко; спасибо каждому из вас за ваш профессионализм и упорный труд.
И это ещё не всё!
Некоторые из наших любимых улучшений в 13.9 включают:
- Создание списков изменений через API
- Возможность помечать изменения в мерж-реквестах как просмотренные
- Возможность запросить повторное ревью у ревьюера
- Создание тикета в Jira из уязвимости
- Назначение инцидентов майлстоуну (в русской локализации GitLab «этап»)
- Ссылки в маркдауне для переключаемых фич
- Разрешение на пуш в защищённые ветки через ключи развёртывания
Все подробности — далее в статье, а чтобы узнать, что будет в следующем месяце, посетите страницу предстоящих релизов и посмотрите видео по релизу 13.10.
Обратите внимание, что GitLab переходит на трёхуровневую систему планов, так что начиная с этого релиза в описаниях фич будет использоваться новая система уровней. Для новых пользователей планы Bronze/Starter больше не будут доступны, у текущих пользователей этих планов есть год на принятие решения о переходе.
Посмотрите вебкаст The Total Economic Impact of GitLab (на английском).
MVP этого месяца — Andreas Gravgaard Andersen
В релизе 13.9 Andreas добавил поддержку графического процессора (GPU) в обработчик заданий GitLab. Это обновление позволит тренировать модели машинного обучения, отрисовывать анимацию или выгружать прочие вычисления. За более подробной информацией об этой фиче обратитесь к её описанию далее в статье. Этот мерж-реквест наконец-то был принят в 13.9, благодаря настойчивости автора и его участию во всех циклах ревью, длившихся более 10 месяцев. Спасибо, Andreas!
Основные фичи релиза GitLab 13.9
Панель оповещений безопасности для уведомлений правил сети контейнеров
(SaaS: ULTIMATE; self-managed: ULTIMATE) Стадия цикла DevOps: Protect
Мы рады представить первую версию панели оповещений безопасности! Теперь пользователи могут настраивать правила сети контейнеров для отправки уведомлений на специальную панель оповещений. Это особенно удобно в тех случаях, когда трафик должен тщательно отслеживаться, но не может быть полностью заблокирован без негативного влияния на бизнес. Вы можете настроить предупреждения в Безопасность и соответствие > Управление угрозами > Правила, и просматривать их в Безопасность и соответствие > Управление угрозами > Предупреждения.
Документация по настройке оповещений и оригинальный эпик.
Режим обслуживания
(self-managed: PREMIUM, ULTIMATE) Доступность
Системные администраторы время от времени выполняют операции по обслуживанию своего инстанса GitLab, чтобы поддерживать его оптимальную работу. При выполнении этих операций администраторы хотели бы обеспечить максимально возможный уровень доступа своим пользователям. Представим, что вы хотите выполнить тест аварийного переключения на вспомогательный сайт в рамках плана обеспечения непрерывности бизнес-процессов компании. Перед этим вы хотите приостановить изменения на короткое время, чтобы убедиться, что дублирующий сайт полностью синхронизирован. В GitLab 13.8 и ранее можно было запретить пользователям входить в систему, но это блокировало весь пользовательский интерфейс и делало GitLab недоступным для пользователей.
C GitLab 13.9 вы можете воспользоваться режимом обслуживания, в котором операции записи отключены на уровне приложения. Это означает, что GitLab фактически находится в режиме «только для чтения» для всех пользователей, не являющихся администраторами; администраторы по-прежнему могут редактировать настройки приложения, а также продолжается выполнение фоновых заданий. Обычные пользователи могут заходить в GitLab, просматривать интерфейс и выполнять другие операции в режиме «только для чтения», такие как git clone или git pull. Используя этот режим, системные администраторы могут выполнять операции обслуживания, такие как переход на вспомогательный сайт, с минимальными перебоями для обычных пользователей.
Обратите внимание, что GitLab уже поддерживает обновления с нулевым временем простоя, и для поддержания вашего инстанса в актуальном состоянии не требуется включать режим обслуживания.
Документация по режиму обслуживания и оригинальный эпик.
Аналитика релизов на уровне группы
(SaaS: ULTIMATE; self-managed: ULTIMATE) Стадия цикла DevOps: Release
С релизом 13.9 стала доступна аналитика релизов на уровне группы, с собранными в одном месте метриками релиза по каждому проекту, связанному с этой группой. Вы можете узнать, сколько релизов относится к этой группе и какой процент проектов связан с релизами. Эта фича также служит первым шагом к поддержке метрик DORA 4 на уровне группы.
Документация по метрикам релиза и оригинальный тикет.
Поддержка JavaScript и Python для фаззинг-тестирования по покрытию
(SaaS: ULTIMATE; self-managed: ULTIMATE) Стадия цикла DevOps: Secure
Теперь вы можете запускать фаззинг-тесты по покрытию для ваших приложений на Python и JavaScript! Эти два языка программирования очень популярны, и мы рады предложить поддержку этих языков в фаззинг-тестировании по покрытию.
Чтобы запустить фаззинг-тестирование для приложений, написанных на этих языках, используйте ту же схему, что и для любого другого поддерживаемого языка. Создайте задание для запуска теста; когда GitLab выполнит его, результаты фаззинг-тестирования автоматически отобразятся на панели безопасности и на вкладке конвейера Безопасность.
Документация по поддерживаемым языкам и движкам фаззинга и оригинальный эпик.
Переопределение коэффициента репликации кластера Gitaly для конкретных репозиториев
(self-managed: PREMIUM, ULTIMATE) Стадия цикла DevOps: Create
Ранее коэффициентом репликации кластера Gitaly было количество нод в кластере. Это делало невозможным включение кластера Gitaly для инстансов GitLab с очень высокими требованиями к хранилищу. Например, кластер 500 ТБ с 50 нодами потребовал бы 25 ПБ дискового пространства для хранения. Чтобы использование кластера Gitaly для инстансов с большими требованиями к месту было возможным, требовался способ задавать коэффициент репликации меньше, чем общее число нод в кластере.
В GitLab 13.9 коэффициент репликации для каждого репозитория может быть настроен индивидуально, на любое число, меньшее, чем число нод в кластере. Это позволяет реплицировать только наиболее важные или активные репозитории, оставляя другие, менее критичные репозитории на меньшем количестве нод. Теперь организации смогут настраивать кластеры в соответствии с собственными ограничениями по хранению и бюджету. Мы также добавили метод настройки коэффициента репликации по умолчанию для всех новых репозиториев. Это должно предоставить пользователям необходимые средства для горизонтального масштабирования их кластеров Gitaly.
Документация по коэффициенту репликации и оригинальный тикет.
Счётчик непрохождения теста в отчёте юнит-теста
(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Verify
При просмотре непройденных тестов может быть не так-то просто понять, действительно ли завершившийся неуспешно тест требует исправления, или же это просто ненадёжный тест, который при следующем выполнении будет пройден.
Новая итерация счётчика непрохождения теста добавляет этот счётчик в отчёт по юнит-тесту. Теперь вы сможете увидеть, как часто тест завершался неуспешно на ветке по умолчанию, и при этом вам не потребуется искать мерж-реквест, связанный с выполнением теста.
Документация по счётчику непрохождения теста в отчёте юнит-теста и оригинальный тикет.
Переиспользуйте конфигурацию любого CI/CD задания
(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Verify
Ранее, если вы хотели повторно использовать одну и ту же конфигурацию в нескольких заданиях, у вас было два варианта: добавить якори YAML, которые не работают в разных конфигурационных файлах, или использовать extends для повторного использования целого раздела.
В этом релизе мы добавили новую функцию YAML !reference, которая позволит вам выбрать именно ту конфигурацию, которую вы хотите использовать повторно в рамках вашего CI/CD конвейера, даже если она находится в другом файле.
Документация по reference и оригинальный тикет.
Развёрнутая версия конфигурации CI/CD
(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Verify
При настройке конвейеров часто используются такие ключевые слова, как include и extends. Они помогают разбить один длинный конфигурационный файл конвейера на несколько файлов, что повышает удобочитаемость и сокращает дублирование. К сожалению, эти ключевые слова могут усложнить понимание конфигурации. В некоторых случаях конфигурационный файл конвейера может в основном состоять из перечня других включённых файлов конфигурации.
Начиная с этого релиза вы можете просмотреть развёрнутую версию вашей конфигурации конвейера со всеми конфигурациями из include иextends, сведёнными вместе. Теперь будет намного проще понять сложные файлы конвейеров, что значительно упростит процесс отладки.
Документация по просмотру развёрнутой конфигурации конвейера и оригинальный тикет.
Группы ресурсов для межпроектных и вложенных конвейеров
(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Release
Теперь вы можете воспользоваться преимуществами использования групп ресурсов, даже если ваш процесс развёртывания включает вложенные или межпроектные конвейеры. Такие конвейеры могут состоять из нескольких этапов, заданий и даже охватывать несколько проектов. Группы ресурсов гарантируют, что только один нижестоящий конвейер будет работать в одно время, чтобы вы могли выполнять развёртывание безопасно. Ранее resource_group поддерживала только задания по развёртыванию в одном проекте.
Документация по группам ресурсов для вложенных и межпроектных конвейеров и оригинальный тикет.
Подписывайтесь на активность пользователя
(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Manage
Теперь пользователи GitLab могут отслеживать активность других пользователей. Подписка на действия пользователей помогает вам быть в курсе того, что происходит у товарищей по команде и у ключевых участников проекта. Вы можете подписаться на пользователя или же отписаться от него в его профиле. Чтобы посмотреть активность пользователей, на которых вы подписаны, перейдите на страницу Активность и выберите вкладку Отслеживаемые пользователи (Followed Users).
Эта фича стала доступна в GitLab 13.9 благодаря потрясающей работе Roger Meier из Siemens на протяжении 3 последних месяцев.
Документация по активности пользователя и оригинальный тикет.
Создавайте тикеты в Jira из уязвимостей
(SaaS: ULTIMATE; self-managed: ULTIMATE) Стадия цикла DevOps: Secure
Многие пользователи используют Jira в качестве единого источника информации для отслеживания тикетов и выполнения работ. При использовании GitLab для SCM и CI/CD вы уже можете воспользоваться возможностями нашей интеграции для передачи информации из мерж-реквестов и коммитов в существующие тикеты Jira. Однако до сих пор не было возможности автоматически передавать в Jira информацию об обнаруженных сканерами безопасности уязвимостях. Это не оставляло пользователям, которые используют Jira для отслеживания работы, иного выбора, кроме как вручную копировать информацию об уязвимостях в новые тикеты.
Для решения этой проблемы мы представляем возможность создавать тикеты Jira непосредственно из подробностей уязвимости. Вы найдёте эту новую опцию в существующих настройках интеграции с Jira; просто включите её и выберите нужный тип тикета в Jira. Доступные типы автоматически подтягиваются в зависимости от текущего настроенного целевого проекта Jira. После включения этой опции во всех местах вашего проекта, где вы можете создавать тикеты GitLab из уязвимости, будут создаваться тикеты в Jira с настроенным вами типом.
Документация по созданию тикета из уязвимости и оригинальный эпик.
Ссылки на переключаемые фичи в Markdown
(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Release
В этом релизе появилась возможность добавлять Markdown-ссылки на переключаемые фичи (feature flags). Пользователи смогут делать упоминания переключаемых фич в формате [feature_flag:<IID>] в обсуждениях и комментариях. Для перехода на страницу редактирования этой фичи достаточно будет кликнуть по сгенерированной ссылке. Это сделает совместную работу над переключаемыми фичами намного проще и удобнее.
Документация по Markdown-ссылкам в GitLab и оригинальный тикет.
Разрешение на пуш в защищённые ветки через ключи развёртывания
(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Release
До версии GitLab 12.0 владельцы ключей развёртывания с разрешением на запись могли пушить коммиты в защищённые ветки. Мы убрали эту возможность из-за проблем с безопасностью, однако многим пользователям она была нужна, чтобы разрешать пуши в свои репозитории только тем пользователям, у которых есть ключи развёртывания. Кроме того, такая схема убирает необходимость использовать сервисные учётные записи, которые тоже входят в количество пользователей, ограниченное лицензией, именно поэтому многие хотели использовать ключи развёртывания для пуша в защищённые ветки. Мы рады сообщить вам, что решили эту проблему, и теперь владельцы ключей развёртывания снова смогут пушить в защищённые ветки, в то же время соблюдая строгие правила безопасности. Двигаясь в сторону модели отдельных разрешений для ключей развёртывания, мы добавили на страницу настройки защищённых веток возможность выбирать ключи развёртывания для привязки к конкретным веткам.
Документация по разрешению на пуш в защищённые ветки для ключей развёртывания и оригинальный тикет.
Запросы на повторное ревью
(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Create
Авторы мерж-реквестов получают фидбек от ревьюеров. Зачастую этот фидбек требует повторного ревью после его обработки, чтобы убедиться, что все проблемы по нему были решены. Для этого автору нужна возможность передать ревьюеру запрос на повторное ревью.
Теперь вы можете отправлять запрос на повторное ревью тем ревьюерам, которые уже проводили ревью мерж-реквеста. Этот запрос создаёт пункт в списке To-Do ревьюера и отправляет ему уведомление по email, чтобы уведомить адресата о том, что вам необходимо повторное ревью ваших изменений.
Документация по запросу на повторное ревью и оригинальный тикет.
Улучшения на GitLab.com для приложения Jira Cloud
(SaaS: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Create
Теперь вы можете синхронизировать ваши данные проекта Jira Cloud с GitLab, используя приложение GitLab.com для Jira Cloud, доступное на Atlassian Marketplace. Этот плагин отображает информацию о ваших ветках, коммитах, мерж-реквестах, развёртываниях и переключаемых фичах на панели разработки Jira. Вы можете использовать его, чтобы проверить текущий статус выполнения работ, а затем быстро вернуться назад к страницам в GitLab.
Чтобы упростить использование этих фич, на протяжении нескольких релизов мы значительно улучшили процесс первоначальной настройки, и теперь присоединять ваши пространства имён GitLab стало проще чем когда-либо. Чтобы начать пользоваться этой фичей, найдите наш плагин на Atlassian Marketplace.
Документация по приложению GitLab для Jira и оригинальный эпик.
Другие улучшения в GitLab 13.9
Email-уведомления при прекращении действия ключей PAT / SSH
(self-managed: ULTIMATE) Стадия цикла DevOps: Manage
Управление вашим пространством имён включает строгое отслеживание того, кто имеет какой доступ и к чему. Чтобы повысить безопасность личных токенов доступа (Personal Access Tokens), вы должны иметь возможность при необходимости отозвать токен пользователя. Для поддержки этой возможности мы добавили для администраторов инстансов с самостоятельным управлением кнопку отключения токена, чтобы вы могли прекращать действие учётных данных определённых пользователей. Теперь вы сможете управлять личными токенами доступа и ключами SSH ваших пользователей на одной странице — с панели Credential Inventory.
Ваши пользователи будут получать email-уведомления, когда их персональные токены доступа или ключи SSH были отозваны или удалены администратором. Эти улучшения предоставят администраторам больше контроля над учётными данными пользователей, а также обеспечат прозрачность пользователям, так что те смогут вовремя обновлять свои учётные данные с минимальной задержкой.
Документация по Credentials Inventory и оригинальный тикет.
Улучшенная обработка таймаутов SAML
(SaaS: PREMIUM, ULTIMATE) Стадия цикла DevOps: Manage
Когда сессия SAML для группы на GitLab.com достигает семидневного таймаута, пользователю больше не придётся кликать на страницу подтверждения, чтобы обновить сессию. GitLab автоматически обратится к поставщику учётных записей группы для проверки валидности сессии и, при необходимости, её продления. Это изменение повышает удобство использования SAML для участников группы и закладывает основу для уменьшения частоты таймаутов сессий SAML в будущем.
Документация по SAML и оригинальный тикет.
Управление токенами доступа к проектам через API
(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Manage
В GitLab 13.9 мы представляем API для управления токенами доступа к проекту. Этот API обеспечивает интеграцию для пользователей, которые хотят управлять предоставлением токенов во внешних системах или через настраиваемую автоматизацию.
Документация по API для управления доступом к ресурсам и оригинальный тикет.
Индикатор занятости пользователя в тикете и на боковой панели мерж-реквеста
(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Manage
В GitLab 13.8 мы добавили индикатор занятости пользователя, чтобы показывать, доступны ли коллеги для ревью кода и других задач. В этом релизе мы также отображаем этот индикатор в разделе Assignee тикета и на боковой панели мерж-реквеста.
Документация по индикатору занятости и оригинальный тикет.
Фильтр по конфиденциальности для дорожных карт
(SaaS: PREMIUM, ULTIMATE; self-managed: PREMIUM, ULTIMATE) Стадия цикла DevOps: Plan
При просмотре дорожной карты (в русской локализации GitLab «план развития») ранее не было возможности скрывать конфиденциальные эпики (в русской локализации GitLab «цели») из основного вида. Это могло быть неудобно, если вы хотели поделиться своей дорожной картой с широкой аудиторией.
В этом релизе мы обновили фильтр поисковой строки, чтобы в выдаче учитывался статус конфиденциальности. Теперь у вас есть ещё один инструмент для приведения дорожной карты к желаемому виду!
Документация по сортировке и фильтрации дорожных карт и оригинальный тикет.
Отображение комментариев к эпику в ленте активности пользователя
(SaaS: PREMIUM, ULTIMATE; self-managed: PREMIUM, ULTIMATE) Стадия цикла DevOps: Plan
До сих пор взаимодействие с эпиками никак не отображалось на странице активностей пользователя. Из-за этого пользователи могли думать, что они неправильно создают эпики, управляют или взаимодействует с ними. Также это усложняло поиск недавней активности.
Начиная с этого релиза вы сможете просматривать всю вашу активность по эпику на странице активностей и в профиле пользователя, а также использовать эту информацию для отслеживания вклада в работу над эпиками.
Документация по активности пользователей и оригинальный тикет.
Автодополнение переменных GitLab CI в VS Code
(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Create
GitLab CI — это быстрый и гибко настраиваемый инструмент, однако пользователю может быть сложно запомнить все предопределённые переменные окружения, а небольшая опечатка сделает файл конфигурации .gitlab-ci.yml недействительным. Чтобы настройка конвейера GitLab CI стала проще, начиная с версии 3.11.0, в GitLab Workflow работает автодополнение предопределённых переменных окружения при редактировании файла .gitlab-ci.yml.
Всплывающие подсказки в диалоге автодополнения дают информацию о том, для чего можно использовать конкретную переменную, а также о поддерживаемых версиях GitLab и обработчика заданий. Эта дополнительная информация может очень помочь в правильной настройке CI.
Спасибо @KevSlashNull за эту фичу!
Документация по автодополнению переменных CI и оригинальный тикет.
Возможность отмечать просмотренные изменения в мерж-реквесте
(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Create
При просмотре мерж-реквеста, в котором изменяется сразу большое число файлов, может быть сложно отследить, какие файлы вы уже просмотрели. Ревью будет неэффективным, если вам придётся повторно просматривать файлы или тратить больше времени на погружение в контекст каждого файла мерж-реквеста.
Теперь файлы в мерж-реквесте можно отмечать как просмотренные (Viewed). Так ревьюерам легко будет увидеть, какие файлы они уже отревьюили, а какие ещё осталось просмотреть.
Документация по ревью и управлению мерж-реквестами и оригинальный тикет.
Просмотр комментариев ревью кода в VS Code
(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Create
В предыдущем релизе GitLab Workflow для VS Code стало возможным просматривать изменения мерж-реквеста в VS Code. Однако просмотр предлагаемых в мерж-реквесте изменений — это только часть процесса ревью этого изменения и ответа на фидбек.
С релизом новой версии GitLab Workflow — 3.10.0 — при просмотре изменений мерж-реквеста вы теперь будете видеть и комментарии к ним. Это значительно облегчит возможность оперативного фидбека по мерж-реквесту прямо в редакторе, без необходимости переключать контекст между VS Code и GitLab.
Мы продолжаем расширять возможности ревью кода в VS Code. Далее мы планируем добавить возможность отвечать на комментарии.
Документация по ревью мерж-реквеста и оригинальный тикет.
Поддержка графического процессора и умного планирования для обработчика заданий GitLab
(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Verify
Некоторые виды вычислений, например связанные с задачами машинного обучения, могут проводиться более эффективно на графическом процессоре. Теперь разработчики могут настроить обработчик заданий GitLab, чтобы он использовал графический процессор в исполнителе Docker, с помощью флага --gpu. Также вы можете подключать графический процессор в форке Docker Machine от GitLab, который позволяет ускорять рабочие процессы с помощью графического процессора. Это может снизить затраты на дорогостоящие конфигурации ПК.
Документация по использованию графического процессора в Google Compute Engine и оригинальный тикет.
График покрытия кода тестами для группы
(SaaS: PREMIUM, ULTIMATE; self-managed: PREMIUM, ULTIMATE) Стадия цикла DevOps: Verify
Ранее мы добавили в GitLab данные о покрытии кода тестами для группы. Эти данные позволяют легко посмотреть текущий уровень покрытия для всех проектов в группе и получить данные для визуализации вне GitLab. Теперь для данных покрытия кода группы также автоматически строится график среднего покрытия, чтобы вы могли видеть, как это значение меняется с течением времени.
Документация по покрытию тестами для группы и оригинальный тикет.
Настройка инстанса для управления хранением последних артефактов
(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Verify
В предыдущем релизе мы постарались улучшить управление использованием памяти, добавив настройку проекта для отключения хранения последних артефактов. Пользователи инстансов с самостоятельным управлением, возможно, захотят отключить хранение последних артефактов для всего инстанса, так что мы добавили опцию, которая позволит сделать это для всех проектов сразу одним кликом.
Документация по хранению последних артефактов и оригинальный тикет.
Автоматическая аутентификация при использовании прокси зависимостей
(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Package
Прокси зависимостей помогает вам повысить производительность конвейеров с помощью проксирования и кэширования образов контейнеров из Docker Hub. Хотя прокси предназначен для интенсивного использования с GitLab CI/CD, ранее вам приходилось вручную добавлять свои учётные данные в переменную DOCKER_AUTH_CONFIG либо запускать docker login в вашем конвейере. Эти способы вполне работали, однако, учитывая, сколько файлов конфигурации .gitlab-ci.yml вам приходится обновлять, было бы лучше, если бы обработчик заданий GitLab мог автоматически проводить аутентификацию за вас.
Так как обработчик заданий уже способен проводить автоматическую аутентификацию со встроенным реестром контейнеров GitLab, мы смогли использовать эту функциональность, чтобы помочь вам автоматически аутентифицироваться в прокси зависимостей.
Теперь вам будет проще использовать прокси зависимостей для проксирования и кэширования образов контейнеров из Docker Hub и получать более быстрые и надёжные сборки.
Документация по аутентификации для прокси зависимостей и оригинальный тикет.
Поддержка сканирования зависимостей для sbt 1.3.0
(SaaS: ULTIMATE; self-managed: ULTIMATE) Стадия цикла DevOps: Secure
Пользователи с проектами на Scala, использующие sbt 1.3 и более поздних версий, теперь смогут воспользоваться сканированием зависимостей. Ранее поддерживались только версии 1.2 и ниже.
Документация по поддерживаемым языками и менеджерам пакетов сканирования зависимостей и оригинальный тикет.
Улучшенная поддержка SAST для Android
(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Secure
Начиная с версии GitLab 13.5 мы поддерживаем SAST для мобильных приложений через MobSF. Мы обновили этот анализатор до версии 2.5, которая включает множество улучшений сканирования мобильных приложений под Android. Основные улучшения включают: добавление привязки к OWASP MSTG для более подробной информации об уязвимостях, поддержку API 29 (Android 10), поддержку xapk и аналитику Национального партнёрства по обеспечению информации для Android.
Наше сканирование безопасности SAST для мобильных устройств все ещё считается экспериментальным и требует включения экспериментальных фич через переменную CI SAST_EXPERIMENTAL_FEATURES. Мы планируем избавиться от этого ограничения в следующем релизе GitLab.
Список изменений анализатора MobSF и оригинальный тикет.
Поддержка нескольких проектов для сканирования SAST для .NET
(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Secure
Сканирования безопасности в GitLab автоматически определяют язык кода и запускают подходящие анализаторы. Для монорепозиториев, микросервисов и многопроектных репозиториев может существовать более одного проекта в рамках одного репозитория GitLab. Ранее наш инструмент SAST для .NET мог определять только одиночные проекты в репозиториях; начиная с этого релиза наш анализатор SAST для .NET сможет интеллектуально определять разные файлы решений (.sln) в проектах .NET и составлять отчёты по уязвимостям, найденным в них. Это сделает сканирование SAST проще и понятнее для пользователей с многопроектными репозиториями .NET.
Документация по поддерживаемым языкам и фреймворкам SAST и оригинальный тикет.
Страница настроек безопасности для всех пользователей
(SaaS: FREE, PREMIUM; self-managed: FREE, PREMIUM) Стадия цикла DevOps: Secure
Так как SAST и поиск секретных ключей стали доступны всем пользователям GitLab, мы хотели упростить использование наших сканирований безопасности для разработчиков. У нас уже был гайд-инструкция по настройке для пользователей Ultimate, а теперь мы сделали упрощённую версию для пользователей всех планов. С её помощью разработчикам будет проще определять, какие сканирования безопасности им доступны, находить нужную документацию и использовать простые инструменты подключения. В этом начальном релизе мы добавляем кнопку создания мерж-реквеста для SAST; в будущих релизах мы добавим дополнительные кнопки для включения других видов сканирований.
Документация по настройкам сканирований безопасности и оригинальный эпик.
Специальный URL для вкладок на панели аналитики CI/CD
(SaaS: ULTIMATE; self-managed: ULTIMATE) Стадия цикла DevOps: Release
В релизе 13.8 мы добавили поддержку графиков частоты развёртываний в рамках аналитики CI/CD. В этом релизе мы также добавили URL для вкладок, что позволит напрямую переходить на любой график аналитики и легко добавлять эти страницы в закладки или отправлять коллегам для просмотра.
Документация по графикам частоты развёртываний и оригинальный тикет.
Поддержка PRIVATE-TOKEN для создания релизов через Release-CLI
(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Release
В 13.9 мы добавили возможность использовать release-cli с PRIVATE-TOKEN, как описано в документации по созданию релиза через API. Это позволит переопределять пользователя, создающего релиз, а также использовать автоматизацию через переменную PRIVATE-TOKEN на уровне проекта или PRIVATE-TOKEN аккаунта пользователя-бота.
Документация по созданию релиза через API и оригинальный тикет.
Vault JWT поддерживает окружения GitLab.
(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Configure
Для упрощения интеграции с HashiCorp Vault в GitLab поддерживается токен Vault JWT (веб-токен JSON). С самого начала вы могли ограничить доступ на основе данных в JWT. Этот релиз даёт вам новую возможность для ограничения доступа к учётным данным: окружение, на которое нацелено задание.
Мы расширяем существующую поддержку токена Vault JWT ограничениями по окружению. Поскольку значение для environment может быть предоставлено пользователем, запускающим конвейер, мы рекомендуем вам использовать новые ограничения на основе окружения с уже существующими значениями ref_type для максимальной безопасности.
Документация по аутентификации с использованием HashiCorp Vault и оригинальный тикет.
Развёртывания GitLab на Kubernetes теперь поддерживают управление доступом к GitLab Pages
(self-managed: FREE, PREMIUM, ULTIMATE) Доступность
В GitLab 13.8 была добавлена начальная поддержка GitLab Pages для развёртываний GitLab на Kubernetes, что позволило пользователям быстро и легко развёртывать статические веб-сайты.
С релизом GitLab 13.9 для Kubernetes-развёртываний также стало доступным управление доступом к Pages, что позволяет открывать доступ к страницам сайта только для участников проекта. Таким образом, теперь в GitLab Helm chart поддерживаются все фичи GitLab Pages.
Документация по GitLab Pages и оригинальный тикет.
Уменьшено потребление памяти Puma на небольших инстансах
(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Доступность
По умолчанию Puma, веб-сервер, используемый GitLab, применяет несколько обработчиков для повышения производительности. Это важно для масштабирования GitLab, но также приводит к увеличению потребления памяти.
Маленьким инстансам с небольшим количеством пользователей и ограниченными ресурсами могут не требоваться несколько обработчиков. Для таких случаев GitLab теперь поддерживает запуск Puma в одиночном режиме, что снижает потребление памяти приложения в состоянии покоя примерно на 250 МБ.
Ознакомьтесь со списком текущих ограничений при запуске Puma в одиночном режиме.
Документация по запуску Puma в ограниченных по памяти окружениях и оригинальный эпик.
Групповые веб-хуки для подгрупп
(SaaS: PREMIUM, ULTIMATE; self-managed: PREMIUM, ULTIMATE) Стадия цикла DevOps: Manage
GitLab упростил вам создание автоматизации управления подгруппами с помощью веб-хука подгруппы. Этот веб-хук срабатывает при создании или удалении подгруппы. Теперь автоматизацию можно построить без постоянного использования вызовов API, которое создавало ненужную нагрузку на ваш инстанс GitLab.
Документация по веб-хукам и событиям подгрупп и оригинальный тикет.
Улучшенный пользовательский интерфейс для списка участников проекта
(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Manage
Наш список участников проекта был переработан, чтобы помочь администраторам проекта быстро определять ключевые атрибуты участников для более эффективного управления пользователями. Новый список включает в себя более описательную терминологию, новую разметку, заголовки для всех столбцов, всплывающие подсказки для ключевых элементов данных и многое другое!
Документация по управлению участниками проекта и оригинальный эпик.
Новая метрика мерж-реквеста: среднее время мержа
(SaaS: PREMIUM, ULTIMATE; self-managed: PREMIUM, ULTIMATE) Стадия цикла DevOps: Manage
Новая метрика, среднее время мержа (MTTM), стала доступна в аналитике мерж-реквестов на уровне проекта. MTTM — это среднее время с момента создания мерж-реквеста до момента его мержа. Выбирая разные даты в селекторе диапазона дат, вы можете увидеть, как меняется время мержа ваших реквестов, и понять, становитесь ли вы более эффективными при ревью и мерже кода.
Документация по аналитике мерж-реквестов: среднее время мержа и оригинальный тикет.
Массовое редактирование итераций тикетов в группах и проектах
(SaaS: PREMIUM, ULTIMATE; FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Plan
Вместо того, чтобы вручную обновлять итерации тикетов по одной, теперь вы можете обновлять итерации из списка тикетов группы или проекта, выбрав несколько сразу.
Документация по массовому редактированию тикетов на уровне группы и оригинальный тикет.
Фильтруйте дорожные карты по майлстоунам
(SaaS: PREMIUM, ULTIMATE; self-managed: PREMIUM, ULTIMATE) Стадия цикла DevOps: Plan
Для передачи ваших стратегических планов или отчётов о текущей работе необходимо иметь возможность отсортировать и отфильтровать контент вашей дорожной карты. Настройте представление дорожной карты ещё подробнее, отфильтровав видимые эпики по майлстоунам.
Эта фича была переключаемой начиная с GitLab 13.7, а теперь она доступна для всех.
Документация по сортировке и фильтрации дорожной карты и оригинальный тикет.
Принимайте предложение с настраиваемым описанием коммита
(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Create
Предложение изменений в мерж-реквесте ускоряет и упрощает ревью кода, позволяя быстро предлагать изменения и применять их одним щелчком мыши. Однако до сих пор для принятых предложений у нас было только описание коммита по умолчанию, которое нельзя было настроить, что не позволяло пользователям адекватно описывать изменения и в конечном итоге не давало выполнять гайдлайны проекта по описаниям коммитов.
В результате авторы мерж-реквеста часто были вынуждены сквошить коммиты для всего мерж-реквеста, либо вручную применять предложения локально или возвращаться и переписывать коммиты с новыми сообщениями после применения предложений.
Теперь вы можете написать собственное описание коммита при принятии предложения. Это позволяет авторам и соавторам принимать предложения и следовать рекомендациям по описаниям коммитов для своих проектов. Если описание коммита не было заполнено, предложение закоммитится с описанием по умолчанию.
Документация по предложению изменений и оригинальный тикет.
Создание списков изменений с помощью GitLab API
(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Create
Раньше создание списка изменений с помощью GitLab выполнялось вручную. Релиз-менеджеры должны были собрать все изменения для данного релиза, а затем вручную добавить их в changelog-файл, что отнимало много времени и легко могло спровоцировать ошибки. Чтобы упростить этот процесс, мы добавили API, автоматически генерирующий список изменений для данного релиза на основе истории коммитов. Это позволит командам разработчиков информировать конечных пользователей об изменениях, предоставляя последовательный и полный набор списков изменений для каждого релиза.
Документация по генерации списков изменений и оригинальный эпик.
Дифф изменений в мерж-реквестах с HEAD ветки по умолчанию
(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Create
Диффы в мерж-реквестах до сих пор рассчитывались с помощью команды git diff target...source, которая сравнивает HEAD цели с базой мержа target и source. Это работает хорошо, пока изменения из целевой ветки не смержены с исходной веткой, что создаёт полную неразбериху в диффах.
При просмотре вкладки изменений в мерж-реквесте, мерж-реквесты теперь по умолчанию сравниваются с <default branch> (HEAD). Это обеспечивает более точный и актуальный дифф изменений во время ревью.
Документация по режимам сравнения для мерж-реквестов и оригинальный эпик.
Использование полезной нагрузки веб-хука при запуске конвейера по триггеру
(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Verify
При запуске конвейера с помощью веб-хука полезная нагрузка веб-хука не была доступна ни для каких заданий в результирующем конвейере. В некоторых случаях полезная нагрузка несёт важную информацию, которая может определить, как должен работать запущенный конвейер. В этом релизе мы добавили новую предопределённую переменную для захвата полезной нагрузки веб-хука, чтобы вы могли включить её в свои конвейеры, запускаемые по триггеру.
Документация по использованию полезной нагрузки веб-хука в запускаемом по триггеру конвейере и оригинальный тикет.
Обработчик заданий GitLab 13.9
(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Verify
Сегодня мы также выпускаем версию 13.9 обработчика заданий GitLab 13.9! Обработчик заданий GitLab — это лёгкий, хорошо масштабируемый агент, который запускает ваши задания сборки и отправляет результаты обратно в ваш инстанс GitLab. Он работает вместе с GitLab CI/CD, службой непрерывной интеграции с открытым исходным кодом, входящей в состав GitLab.
Что нового:
- Добавлена поддержка Nvidia docker runtime в исполнитель Kubernetes
- Контроль уровня сжатия ZIP-файлов в кэше
- Отображение прогресса загрузки артефакта/кэша
- Обновление PowerShell Core до версии 7.1.1 во вспомогательном образе под Windows
- Поддержка PowerShell Core в исполнителе Docker под Linux
- Поддержка PowerShell Core в исполнителе Kubernetes
- Автоматическая аутентификация с помощью прокси зависимостей
- Использование настроенного вспомогательного образа для обновления разрешений в исполнителе Kubernetes
- Подключение к инстансу Gitlab с помощью самоподписанного сертификата с обработчиком заданий на OpenShift
Исправленные баги:
- Скрипт Gitlab CI неправильно передавал код завершения предыдущей команды
- Проблема «тайм-аут завершения работы» со службой Windows
- Проблема маскирования переменных с повторяющимися символами
Не использовалось свойство OpenShift Operator-concurrentиз файла config.toml
Список всех изменений находится в CHANGELOG обработчика заданий GitLab.
Документация по обработчику заданий GitLab.
Устанавливайте обработчик заданий GitLab ещё проще с помощью встроенной справки
(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Verify
Если вы не используете общие обработчики заданий на GitLab.com, для начала работы с GitLab CI необходимо установить обработчик заданий GitLab и зарегистрировать его для вашего конвейера. Хотя процесс установки хорошо документирован, одна из наших целей — максимально упростить пользователям начало работы с GitLab CI. Первым шагом на этом пути является релиз нового мастера установки обработчика заданий GitLab. С его помощью вы можете выбрать целевую платформу, скопировать и запустить команды установки, не выходя из пользовательского интерфейса GitLab.
Документация по установке обработчика заданий GitLab и оригинальный тикет.
Разрешение или запрет повторяющихся загрузок в Maven
(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Package
Вы можете использовать реестр пакетов GitLab для публикации зависимостей Java с помощью Maven или Gradle. По умолчанию вы можете публиковать одно и то же имя и версию пакета несколько раз. Такое значение по умолчанию было выбрано на основе поведения наиболее распространённых публичных реестров.
Однако многие пользователи отмечали, что хотели бы предотвратить дублирование загрузок, особенно когда речь идёт о релизах. Мы добавили новую настройку реестра пакетов уровня группы, так что теперь вы можете выбрать, хотите ли вы разрешить или запретить дублирующую загрузку в Maven или Gradle. Как уже упоминалось, для соответствия поведению публичных реестров по умолчанию дубликаты будут разрешены.
Вы можете настроить этот параметр с помощью API GitLab или из приложения, перейдя в Настройки > Пакеты и Реестры (Settings > Packages & Registries). В ближайшее время мы планируем расширить поддержку этого параметра до каждого формата менеджера пакетов и добавить его в пользовательский интерфейс. Следите за соответствующим эпиком и внесите свой вклад!
Документация по настройке пакетов и оригинальный тикет.
Сканирование зависимостей теперь поддерживает вторую версию файлов блокировки npm
(SaaS: ULTIMATE; self-managed: ULTIMATE) Стадия цикла DevOps: Secure
Теперь поддерживаются пользователи с проектами на Node.js, использующими файл блокировки версии 2 для npm 7. Ранее сканирование зависимостей выдавало следующую ошибку: [FATA] [Gemnasium] [2020-10-29T19:02:20Z] Wrong file format version.
Документация по поддерживаемым языкам и пакетам при сканировании зависимостей и оригинальный тикет.
Расширенная поддержка Ruby для SAST-сканирований
(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Secure
Мы хотим помочь разработчикам писать лучший код и меньше беспокоиться о распространённых ошибках безопасности. Статическое тестирование безопасности приложений (SAST) помогает предотвратить уязвимости безопасности, позволяя разработчикам легко выявлять типичные проблемы безопасности по мере добавления кода и проактивно их предотвращать. Мы обновили наш предназначенный для Ruby on Rails анализатор SAST (Brakeman) до новой версии (v5), добавляющей поддержку для большинства файлов Ruby, а не только для проектов Rails. Это изменение расширяет множество поддерживаемых типов проектов Ruby и вводит новые правила обнаружения уязвимостей. Если у вас есть собственный файл SAST.gitlab-ci.yml или вы переопределили задание brakeman в GitLab SAST, то вам может потребоваться обновить файл CI, чтобы включить это дополнительное сканирование.
Документация по поддерживаемым языкам и пакетам при сканировании SAST и оригинальный тикет.
Сканирование лицензий теперь начинается в пределах соответствующего этапа
(SaaS: ULTIMATE; self-managed: ULTIMATE) Стадия цикла DevOps: Secure
Ранее по умолчанию сканирование лицензий запускалось при запуске конвейера. Такое поведение было неожиданным и несовместимым с другими заданиями GitLab Secure. Теперь поведение по умолчанию было изменено, так что сканирование лицензий запускается при запуске этапа, на котором оно находится, а не при запуске конвейера. Если вы настроили свой файл .gitlab-ci.yml и хотите, чтобы задание сканирования лицензий запускалось только при запуске его этапа, удалите оператор needs: []. Если вы используете шаблон по умолчанию и хотите изменить поведение, добавьте оператор needs: [].
Документация по оператору needs: в YAML и оригинальный тикет.
Поддержка SAST для .NET 5
(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Secure
Релиз .NET 5.0 от Microsoft — это следующий крупный релиз .NET Core, поддерживающий больше типов приложений и больше платформ, чем .NET Core или .NET Framework. Мы обновили наш анализатор SAST для .NET, Security Code Scan, чтобы поддерживать эту новую версию, которая также поддерживается [нашим определением языка для SAST](https: //docs.gitlab.com/ee/user/application_security/sast/#supported-languages-and-frameworks), что позволит GitLab SAST автоматически опознавать проекты .NET 5. Это изменение было частью вклада от @shaun.burns из нашего сообщества.
Документация по настройке анализаторов SAST и оригинальный тикет.
Фильтр активности в отчёте об уязвимостях
(SaaS: ULTIMATE; self-managed: ULTIMATE) Стадия цикла DevOps: Secure
Отчёты об уязвимостях часто являются основным способом сортировки уязвимостей и управления ими. Текущие параметры фильтрации и сортировки позволяют быстро сфокусировать представление списка на подмножестве уязвимостей для более эффективных рабочих процессов. Вы также можете увидеть любые уязвимости, с которыми связаны тикеты или которые, как показали последующие проверки, уже устранены. В столбце «Активность» (“Activity”) вы можете просмотреть, какие уязвимости могут быть готовы к закрытию, какие находятся в процессе, а какие могут потребовать некоторого внимания. Однако этот столбец нельзя было фильтровать или сортировать!
Теперь вы получите ещё больший контроль над отчётом об уязвимостях с помощью фильтра активности. Этот новый фильтр, доступный в отчётах об уязвимостях проекта, группы и центра безопасности, позволяет просматривать ещё не закрытые уязвимости с тикетами, закрытые без связанных тикетов, закрытые с тикетами и уязвимости без активности. Доступные параметры фильтра представляют собой взаимоисключающие наборы, позволяющие детализировать представление списка уязвимостей, необходимое для выполнения любой задачи.
Документация по настройке отчёта об уязвимостях и оригинальный тикет.
Горячие клавиши для переключения между GitLab и GitLab Next
(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Release
В этом релизе мы представляем быстрое переключение между GitLab и GitLab Next. Используя клавиши g и x, работающие в любой области GitLab, вы можете легко переключаться между GitLab и GitLab Next. Огромное спасибо Yogi за этот отличный вклад!
Документация по горячим клавишам и оригинальный тикет.
Поддержка nConfigMap для сервера агентов Kubernetes
(SaaS: PREMIUM, ULTIMATE; self-managed: PREMIUM, ULTIMATE) Стадия цикла DevOps: Configure
До сих пор пользователям сервера агентов Kubernetes (Kubernetes Agent Server, KAS) приходилось использовать аргументы командной строки для настройки своих установок. Такая настройка оказывается неподходящей для крупномасштабных установок, где декларативные, повторяемые схемы являются основной частью рабочего процесса, а многие аргументы требуют настраиваемых параметров. С этим релизом GitLab вы можете установить KAS с помощью helm chart с пользовательскими настройками, которые объединяются с настройками по умолчанию, что упростит интеграцию установки сервера агентов с существующими инструментами наблюдения и мониторинга.
Документация по установке с помощью helm chart и оригинальный тикет.
Назначение инцидентов майлстоунам
(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Monitor
Не все инциденты имеют одинаковую серьёзность (severity). Многими инцидентами необходимо заняться немедленно, чтобы восстановить сервисы, от которых зависят клиенты, но некоторые инциденты менее критичны, и им можно назначить более низкий приоритет по сравнению с остальной работой и привязать к конкретному релизу или этапу реализации. Теперь вы можете привязывать инциденты с низкой серьёзностью к майлстоунам на правой боковой панели, чтобы управлять ими с ваших досок задач (в русской локализации GitLab «доски обсуждений»).
Документация по назначению инцидентов майлстоунам и оригинальный тикет.
GitLab exporter использует значительно меньше памяти
(self-managed: FREE, PREMIUM, ULTIMATE) Доступность
GitLab exporter измеряет различные показатели из Redis и базы данных. Мы сократили его потребление памяти примерно на 60% (~67-71 МБ) за счёт оптимизации его конфигурации.
Это особенно важно при запуске GitLab exporter в окружениях с ограниченным объёмом памяти.
Документация по GitLab exporter, оригинальный тикет и эпик.
Сортировка результатов глобального поиска по времени последнего обновления
(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Доступность
Вы можете выбрать способ сортировки результатов поиска на странице результатов; в релизе 13.9 мы добавили сортировку результатов поиска по тикетам и мерж-реквестам по времени их последнего обновления.
Документация по расширенному поиску и оригинальный тикет.
Полный текст релиза и инструкции по обновлению/установке вы можете найти в оригинальном англоязычном посте: GitLab 13.9 released with a Security Alert Dashboard and Maintenance Mode.
Над переводом с английского работали cattidourden, maryartkey, ainoneko и rishavant.
site6893
я просто поражаюсь работоспособности єтих ребят! так деражть GitLab!