Вышел релиз GitLab 12.6 с оценками безопасности проектов и материалами релиза
Руководителям разработки необходим четкий и понятный обзор состояния безопасности приложения и соответствия требованиям для их проектов. Декабрьский релиз GitLab поможет вам эффективнее отслеживать эти важные параметры.
Статус безопасности проекта
В релизе 12.6 мы добавили новую фичу на <a href=”#bystraya-ocenka-riskov-proekta-s-ocenkami-bezopasnosti”>панель безопасности проекта</a>, которая показывает оценку состояния безопасности ваших проектов. Так руководители разработки смогут быстрее понять, какие проекты могут быть в зоне риска, и обеспечить необходимое внимание конкретным проблемам.
Улучшенный аудит с материалами релиза
Почти каждая enterprise-команда должна документировать свою работу и предоставлять свидетельства того, что каждый релиз соответствует всем требованиям и процедурам организации. Часто это означает, что в компании существуют ручные процессы сохранения текущей документации, чтобы она была доступна для будущих проверок на соответствие требованиям. GitLab 12.6 упрощает проведение аудита благодаря <a href=”avtomaticheskaya-sborka-materialov-reliza-dlya-audita”>файлу с материалами релиза</a> — JSON-объекту, который содержит ссылки на майлостоуны и тикеты, относящиеся к релизу, что поможет в будущих аудитах.
Эффективное управление и распределение ресурсов C/C++
Многие команды активно разрабатывают высокопроизводительные приложения на C и C++, и им требуется инструмент для удобного управления и распространения скомпилированных файлов и бинарных файлов проекта. С релизом 12.6 стало проще работать с этими файлами как публично, так и приватно, благодаря интеграции с популярным репозиторием Conan. Теперь разработчики смогут использовать все преимущества размещения кода, автоматизированных конвейеров (в русской локализации GitLab «сборочные линии») CI и результирующих пакетов в одном приложении, что улучшит общую эффективность и скорость разработки.
И даже больше!
Это были только несколько новых фич релиза 12.6. Обратите внимание также на сканирование зависимостей Gradle-проектов на Java и поддержку squash-and-merge в цепочках мерж-реквестов (в русской локализации GitLab «запросы на слияние»).
Открыта регистрация на следующую пользовательскую конференцию GitLab Commit, которая состоится 14-го января в Сан-Франциско.
Приглашаем на наши встречи, на GitLab Commit и просим заполнить опрос по релизу (на английском).
MVP этого месяца — Fabio Huser
Fabio внес несколько важных мерж-реквестов в 12.6: возможность отключить оповещение об упоминании группы, отображение разницы покрытия тестами на странице мерж-реквеста, добавление разбивки по страницам в релизах и поддержку Unify Circuit.
Спасибо Fabio и всей команде Siemens!
Основные фичи релиза GitLab 12.6
Быстрая оценка рисков проекта с оценками безопасности
(ULTIMATE, GOLD) Стадия цикла DevOps: “Secure”
Мы рады представить новую фичу на панели безопасности группы — оценка состояния безопасности. Помимо уже существующих списка уязвимостей и истории, эта новая часть панели безопасности показывает, какие проекты сейчас в зоне риска, чтобы вы могли сразу перейти к проектам, требующим немедленного внимания.
Опасность обнаруженных уязвимостей повлияет на полученную оценку — от A до F. Проекты будут сгруппированы по этим оценкам, позволяя легко увидеть распределение проектов без текущих проблем с безопасностью (оценка A) до имеющих как минимум 1 критическую уязвимость (оценка F).
Документация по панели безопасности группы и оригинальный тикет.
Управление пакетами C/C++ через Conan с помощью реестра пакетов GitLab
(PREMIUM, ULTIMATE, SILVER, GOLD) Стадия цикла DevOps: “Package”
Для компаний, занимающихся разработкой ПО, очень важно иметь простой и безопасный способ управлять зависимостями. Инструменты для управления пакетами, такие как Conan для разработчиков на C/C++, предоставляют стандартизованный способ распространять библиотеки и управлять их версиями среди проектов. В релизе 12.6 мы рады предоставить поддержку репозиториев Conan, встроенную напрямую в GitLab. Просто укажите адрес удаленного сервера Conan реестру пакетов GitLab — и вы сразу сможете загружать, устанавливать и удалять пакеты, а также публиковать свои библиотеки.
Документация по использованию Conan и оригинальный тикет.
Фильтрация тикетов и мерж-реквестов по релизу
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Release”
Планирование релизов и управление ими — задачи не из легких. Именно поэтому так важна возможность быстро находить относящиеся к релизу тикеты и мерж-реквесты. В 12.6 мы добавили фильтрацию тикетов и мерж-реквестов по имени релиза, что поможет вам быстрее находить связанные тикеты и мерж-реквесты.
Документация по поиску и оригинальный тикет.
Автоматическая сборка материалов релиза для аудита
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Release”
Во многих компаниях при выпуске новых изменений необходимо документировать соблюдение всех необходимых процессов и регулировок в жизненном цикле разработки ПО. Зачастую этот процесс неэффективен — и отнимает много времени. Начиная с 12.6 в Релизах GitLab появились Собранные материалы (Evidence collection), где вы найдете снимок всех метаданных релиза в формате JSON. Этот снимок может быть использован для процессов ревью и подтверждения соответствия требованиям, например, для аудита.
Документация по материалам релиза и оригинальный тикет.
Объединенная история коммитов при squash-and-merge в цепочке мерж-реквестов
(PREMIUM, ULTIMATE, SILVER, GOLD) Стадия цикла DevOps: “Release”
Squash-and-Merge позволяет собрать все коммиты вашего мерж-реквеста в один, чтобы у вас была аккуратная история в ветке по умолчанию, и сделать это без потери всей истории коммитов. В этом релизе мы добавили поддержку squash в цепочки мерж-реквестов, которые запускают билд по результату мерж-реквеста до его выполнения, позволяя убедиться, что master-ветка останется зеленой. Комбинация этих двух фич обеспечит master-ветку в рабочем состоянии и объединенную историю коммитов.
Документация по конвейерам по результату мерж-реквеста и оригинальный тикет.
Просмотр настроек безопасности и соответствия требованиям в одном месте
(ULTIMATE, GOLD) Стадия цикла DevOps: “Secure”
Мы рады представить новый способ просмотра сканирований безопасности из левой панели навигации. В разделе Безопасность и соответствие требованиям (Security and Compliance) появилась опция Конфигурация (Configuration), где вы увидите все доступные сканирования безопасности, какие сканирования были настроены, и ссылки на соответствующую документацию.
Обратите внимание, что это только первая итерация (MVC) этой фичи, так что более сложная настройка пока недоступна, например вы не можете включать или выключать сканирования с этого экрана.
Документация по проверке безопасности приложений и оригинальный тикет.
Эффективнее работайте вместе благодаря Circuit
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) “Enablement”
Circuit от Unify — система для общения и совместной работы, используемая многими организациями. Как и в случае с другими интеграциями оповещений GitLab, теперь вы можете настроить веб-хуки для отправки определенных оповещений в беседу Circuit. Ссылки в оповещениях будут вести в ваш проект в GitLab, избавляя вас от необходимости переключаться в почтовый клиент ради обновлений об активности в GitLab.
Спасибо Fabio Huser за этот вклад.
Документация по работе с Circuit и оригинальный тикет
Другие улучшения в GitLab 12.6
Требования к новым паролям пользователей
(CORE, STARTER, PREMIUM, ULTIMATE) Стадия цикла DevOps: “Manage”
Организациям необходим способ обеспечения безопасности своих инстансов GitLab в соответствии с внутренними процедурами и регулировками. Частью этой работы является обеспечение безопасности паролей. Недавно GitLab обновил свои гайдлайны в отношении паролей, основываясь на NIST SP 800-63B. В этой публикации NIST рекомендует задавать требования по длине и сложности пароля, но не рекомендует ротацию паролей или специфичные требования к сложности (например, определенное количество специальных символов).
Основываясь на этом, GitLab представляет новую настройку в панели администратора — минимальная длина пароля (minimum password length), которая будет применяться к новым паролям, то есть будет действовать на новые аккаунты или при смене пароля. Благодаря этому GitLab станет более безопасным, и организации смогут управлять политикой паролей в своих инстансах, обеспечивая соответствие внутренним требованиям.
Документация по ограничению длины паролей и оригинальный тикет.
Требование обновления персональных токенов
(ULTIMATE) Стадия цикла DevOps: “Manage”
Организации, уделяющие много внимания безопасности, всегда использовали регулярные смены идентификационных данных, чтобы ограничить время доступа к системе в случае компрометации данных. Хотя гайдлайны от организаций вроде NIST более не рекомендуют периодические смены, мы все равно добавляем возможность настроить требование регулярного обновления личных токенов. Это может потребоваться из-за изначального отсутствия двухфакторной защиты, требований пользователей или важности смены для некоторых фреймворков, обеспечивающих соответствие стандартам, например PCI.
Благодаря этой фиче администратор инстанса может настроить срок жизни сгенерированных токенов личного доступа. Применение лимита автоматически просрочит все текущие токены, их придется сгенерировать заново, и уже к новым токенам будет применен заданный срок жизни. Когда он истечет, токен нужно будет сгенерировать снова.
Документация по ограничению срока жизни токенов и оригинальный тикет.
Защита данных проекта благодаря обратимому удалению
(PREMIUM, ULTIMATE, SILVER, GOLD) Стадия цикла DevOps: “Manage”
До этого момента удаление проекта через UI или API было немедленным и необратимым, без возможности восстановить данные. Это могло привести к непреднамеренной потере данных, что было бы худшим сценарием для разработчиков.
Для снижения рисков с релизом 12.6 мы представляем обратимое удаление проектов. Вместо немедленного удаления проекта или группы, они будут помечены к удалению и удалены после настроенного количества дней обратимого удаления. По умолчанию это произойдет через 7 дней. Если же вы хотите оставить немедленное удаление, измените значение этого параметра на 0.
Документация по периоду обратимого удаления и оригинальный тикет.
Предпросмотр спецификаций OpenAPI
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Create”
Спецификация OpenAPI (ранее Swagger) — популярный стандарт для создания RESTful интерфейсов. Тем не менее, читать исходный код на YAML не так-то просто. В релизе GitLab 12.6 при просмотре файла openapi.yml или другого поддерживаемого файла будет отрисовано превью спецификации, в том же виде, что и в Swagger.
Спасибо Roger Meier и Siemens за этот вклад!
Документация по предпросмотру для спецификаций OpenAPI и оригинальный тикет.
Упрощенная навигация между табами в мерж-реквестах
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Create”
Интерфейс мерж-реквестов — то место, где код ревьювят, тестируют и обсуждают, но этот интерфейс легко может оказаться перегружен. Описания мерж-реквестов, конвейеры, результаты сканирования безопасности могут сместить табы далеко вниз страницы, делая их труднодоступными.
В новом релизе GitLab навигация по мерж-реквесту теперь находится выше описания, и вы легко сможете перейти сразу к изменениям. Также мы сгруппировали описание и виджеты на табе Обзор (Overview), что облегчит навигацию по мерж-реквесту. Пожалуйста, присылайте вашу обратную связь об этом обновлении сюда.
Документация по мерж-реквестам и оригинальный тикет.
Удаление ветвления при ограничении видимости проекта
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Create”
Ветвления упрощают работу над любым проектом. Вы делаете копию основного проекта, над которой можно поработать, а потом создаете мерж-реквест, чтобы внести свои изменения в проект.
Ранее, когда видимость корневого проекта в сети ветвлений изменялась на ограниченную, видимость всех веток тоже становилась ограниченной. Это могло привести к тому, что все форки публичного проекта внезапно становились закрытыми, если вы ограничивали видимость корневого проекта.
В GitLab 12.6 вместо изменения видимости всех проектов, корневой проект просто удаляется из сети ветвлений, оставляя все остальные проекты без изменений, что эквивалентно удалению корневого проекта.
Документация по ограничению видимости и оригинальный тикет.
Настройка CI за пределами репозитория
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Verify”
Мы добавили возможность задавать путь к .gitlab-ci.yml как произвольный URL, что позволит вам хранить настройки CI вне того репозитория, который вы сейчас собираете. Теперь для одинаковой настройки нескольких репозиториев вы можете просто указать ссылку на один и тот же внешний файл .gitlab-ci.yml. Эффективность повышается за счет того, что вместо поддержки множества отдельных настроек, достаточно обновлять только один настроечный файл. Пользователи, которые пользуются сервисами, динамически генерирующими настроечный файл, тоже получат преимущество от этой фичи.
Это также позволяет защищать настройки от несанкционированных изменений, так как настроечный файл можно хранить в проекте с более строгим ограничением доступа. Мы обновили нашу документацию, добавив информацию о том, как это сделать.
Документация по заданию пути к файлу настроек CI и оригинальный тикет.
Реестр NPM теперь поддерживает установку зависимостей
(PREMIUM, ULTIMATE, SILVER, GOLD) Стадия цикла DevOps: “Package”
Мы рады сообщить вам, что, начиная с GitLab 12.6, реестр NPM поддерживает установку зависимостей пакета. Ранее команда npm install не работала, если версия пакета не была включена в команду. Кроме того, эта команда не поддерживала установку зависимостей пакетов потому, что мы не поддерживали требуемые метаданные NPM, такие как зависимости и теги.
С этим релизом GitLab npm install будет работать как полагается. Далее мы планируем поработать над добавлением зависимостей и тегов к пользовательскому интерфейсу реестра пакетов.
Документация по метаданным реестра NPM и оригинальный тикет.
Официальный контейнер GitLab с предустановленным клиентом AWS
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Release”
Взаимодействие с одним из крупных провайдеров облачных сервисов, таким как AWS, Azure или GCP, – это ключевой компонент многих конвейеров. Однако, прежде чем вы сможете автоматизировать облачные операции, вам необходимо настраивать окружение со всеми нужными инструментами. Ранее вам приходилось делать это самостоятельно, но, начиная с версии 12.6, GitLab будет предоставлять официальный образ AWS Docker, который позволить вам запускать aws-команды из ваших конвейеров CI/CD. Вы сможете получить доступ ко множеству сервисов AWS, используя образ Docker, который поддерживается и обновляется командой GitLab.
Поставка официального образа – это также первый шаг к поддержке развертываний AWS в EC2. Один из наших глобальных планов – добавить нативную поддержку для развертываний на облаках от различных провайдеров. Мы надеемся увидеть вклад сообщества в разработку поддержки дополнительных облачных провайдеров. Для этого вы можете использовать эту модель предсобранных образов со включенными скриптами, которая хранится в официальном реестре GitLab Cloud Deploy.
Документация по облачным развертываниям и оригинальный тикет.
Предупреждение при мерже вне очереди
(PREMIUM, ULTIMATE, SILVER, GOLD) Стадия цикла DevOps: “Release”
Когда пользователи выбирают для своих мерж-реквестов опцию «Merge Immediately», происходит задержка всех мерж-реквестов в очереди. Пользователи могли не знать, что это происходит, и могли ненамеренно мешать друг другу. Теперь, хотя мы все еще позволяем срочным мерж-реквестам проходить без очереди, в качестве дополнительной линии защиты мы добавили предупреждение, в котором объясняется, что это действие повлияет на остальные мерж-реквесты.
Документация по цепочкам мержей и оригинальный тикет.
Настройка пространства имен Kubernetes для каждого окружения
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Configure”
Когда вы пользуетесь интеграцией GitLab с Kubernetes, вы получаете автоматически созданное пространство имен, которое служит целью развертывания для GitLab CI/CD. Это упрощает начало работы с Kubernetes. Однако, если у вас уже есть кластер с существующим набором пространств имен, то скорее всего вы захотите задать одно из этих пространств имен как цель развертывания GitLab.
С GitLab 12.6 вы сможете задавать пользовательское пространство имен для каждого окружения CI в файле .gitlab-ci.yml, что позволит вам производить развертывания в пространства, которые существовали еще до того, как вы подключили свой кластер Kubernetes к GitLab. По умолчанию эта фича доступна только для кластеров без самостоятельного управления, но она поддерживает динамические окружения (например, для использования в приложениях для ревью).
Документация по настройке развертываний Kubernetes и оригинальный тикет.
Очистка кэша кластеров для поддержки синхронизации
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Configure”
Нам часто приходится выполнять действия над кластерами Kubernetes напрямую, например, для устранения неисправностей или точной настройки. Изменение ресурсов Kubernetes прямо в кластере может привести к прекращению синхронизации GitLab с кластером, и он перестанет создавать ресурсы повторно, так как будет считать, что они уже существуют.
Начиная с GitLab 12.6 в интеграции с Kubernetes появится опция очищения локального кэша пространства имен и служебных аккаунтов, что позволит следующему заданию CI при необходимости создать их заново.
Документация по очистке кэша кластера и оригинальный тикет.
Установка приложений Kubernetes при помощи шаблона CI
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Configure”
Установка приложений Kubernetes с использованием GitLab CI предоставляет отличный способ настраивать чарты Helm перед установкой. Для упрощения начала работы мы добавили шаблон CI со всеми поддерживаемыми на текущий момент приложениями. Кроме того, мы создали пример проекта по управлению кластерами, который содержит все необходимое для начала работы. Просто импортируйте и скопируйте этот проект, чтобы получить все последние версии поддерживаемых приложений.
Документация по установке через GitLab CI и оригинальный тикет.
Улучшенная интеграция между отслеживанием ошибок и управлением тикетами
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Monitor”
Сортировка ошибок может быть трудоемкой работой, которой зачастую приходится заниматься нескольким участникам вашей команды. Один участник может определить ошибку как критическую и создать тикет для ее исправления. Начиная с GitLab 12.6 со страницы с детальной информацией по ошибке можно перейти к открытому для нее тикету. Таким образом, сразу будет очевидно, нужно ли создавать тикет для этой ошибки.
Если тикета еще нет, вы можете быстро создать его из сгенерированной ошибки со страницы этой ошибки.
Документация по странице с информацией по ошибке и оригинальный тикет. цикла DevOps: “Monitor”](https://about.gitlab.com/stages-devops-lifecycle/monitor/)
Управление Sentry через GitLab
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Monitor”
Если вы пользуетесь отслеживанием ошибок GitLab, то для вас наверняка важно иметь интеграцию с Sentry, самым популярным инструментом для отслеживания ошибок. Начиная с GitLab 12.6, если вы не можете использовать проект Sentry на Sentry.io, вы можете развертывать Sentry напрямую в кластере Kubernetes, прикрепленном к вашему проекту или группе. Это значительно упрощает начало работы с отслеживанием ошибок в GitLab.
Документация по установке Sentry через GitLab CI и оригинальный тикет.
Доступ к логам подов на вкладке операций
(ULTIMATE, GOLD) Стадия цикла DevOps: “Monitor”
Ранее не было простого способа переходить напрямую к просмотру лога ваших подов. Для этого вам нужно было перейти во вкладку Окружения (Environments) в пункте Операции (Operations), выбрать нужное окружение и кликнуть на нужный под. Теперь, в GitLab 12.6, просматривать логи подов стало просто как никогда. Нажмите на вкладку Логи пода (Pod Logs) в пункте Операции.
Документация по логам подов Kubernetes, оригинальный тикет и оригинальный эпик.
Улучшение сканирования зависимостей для проектов на Python
(ULTIMATE, GOLD) Стадия цикла DevOps: “Secure”
Если ваши зависимости Python хранятся не в requirements.txt, а в каком-то другом файле, то, начиная с GitLab 12.6, вы сможете задавать файл зависимостей через переменную PIP_REQUIREMENTS_FILE.
Документация по доступным переменным и оригинальный тикет.
Поддержка SAST для фреймворка React (JavaScript)
(ULTIMATE, GOLD) Стадия цикла DevOps: “Secure”
Если у вас есть проекты, написанные с использованием фреймворка JavaScript React, то теперь вы сможете пользоваться нашими сканированиями SAST для поиска проблем с безопасностью.
Документация по поддерживаемым языкам и фреймворкам и оригинальный тикет.
Сканирование зависимостей для проектов Scala при помощи менеджера пакетов sbt
(ULTIMATE, GOLD) Стадия цикла DevOps: “Secure”
В GitLab 12.6 мы добавили поддержку для Scala с менеджером пакетов sbt в сканировании зависимостей. Теперь вы сможете сканировать проекты на Scala для поиска потенциальных уязвимостей.
Документация по поддерживаемым языкам и менеджерам пакетов и оригинальный тикет.
Возможность редактировать групповые веб-хуки
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) “Enablement”
Групповые веб-хуки теперь можно редактировать. Ранее их можно было только создавать и удалять, так что для их изменения приходилось удалять уже существующий веб-хук и создавать новый. В этом релизе мы добавили возможность редактировать веб-хуки через пользовательский интерфейс, что позволит вам сэкономить время и силы при работе с ними.
Документация по расширенным настройкам группы, оригинальный тикет и мерж-реквест.
Отключаемые комментарии в тикетах Jira
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) “Enablement”
Когда у пользователя подключена интеграция GitLab с Jira, в Jira публикуются комментарии, когда происходит активность в GitLab. Это обновление позволит пользователям отключать эти комментарии для конкретной интеграции на странице настроек.
Это будет удобно для пользователей, которые не хотят видеть комментарии, но хотят автоматически добавлять тикеты Jira к проектам GitLab. Кроме того, возможны сценарии использования, при которых есть пользователи Jira, которые не должны иметь доступ к активности в репозитории по причине их конфиденциальности. В обоих случаях вам пригодится более точная настройка содержимого этих сообщений.
Документация по отключению комментариев к тикетам Jira, оригинальный тикет и мерж-реквест.
Сортировка участников групп по пользователям, добавленным напрямую
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Manage”
Есть два способа получить доступ к закрытому проекту или группе: а) вас могут добавить к конкретному проекту или в группу напрямую б) вы можете унаследовать доступ из вышестоящей группы.
В GitLab 12.6 стало проще понимать, как пользователь получил доступ к проекту или группе, благодаря фильтру для сортировки таблицы участников по пользователям, добавленным напрямую или по пользователям с унаследованными правами.
Это особенно полезно для групп с внешними пользователями или инстансов, использующих группы для уведомления команд.
Документация по пользователям с унаследованными правами доступа и оригинальный тикет.
Упрощение управления пользователями с помощью токена личного доступа и хранилища ключей SSH
(ULTIMATE) Стадия цикла DevOps: “Manage”
По мере роста вашего автономного инстанса GitLab растет и ваша потребность в средствах контроля соответствия. По мере добавления новых пользователей, групп, подгрупп и проектов ваш инстанс становится все сложнее. Вам надо ясно видеть, кто имеет доступ к вашему инстансу, чтобы управлять рисками и соответствием требованиям в вашем инстансе.
Чтобы помочь вам в этом деле, мы представляем MVC для хранения учетных данных PAT и SSH. Теперь администраторы могут легко просмотреть важные подробности, например владельца, тип и область действия каждой учетной записи. Также отображается, когда истек срок действия учетных данных, и момент их последнего использования.
Документация по хранилищу учетных данных и оригинальный тикет.
Запрет оповещений об упоминании группы
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Plan”
Упоминание группы с большим количеством участников быстро приводит к накоплению большого количества ненужных уведомлений. Чтобы избежать этого, теперь вы можете включить настройку на уровне группы, отключающую уведомления при упоминании группы в тикете или мерж-реквесте.
Спасибо @fh1ch и Siemens!
Документация по отключению оповещений об упоминании группы, оригинальный тикет и мерж-реквест.
Дедупликация форков внутренних проектов
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Create”
Ветвления позволяют легко внести свой вклад в любой проект: вы создаете копию вышестоящего проекта для работы над ней, а уже потом открываете мерж-реквест для применения ваших изменений к вышестоящему проекту. Для популярных проектов хранилище на стороне сервера содержит тысячи копий. Это приводит к постоянному повышению требований к хранилищу, и увеличивает стоимость хостинга.
В GitLab 12.1 мы представили дедупликацию для публичных проектов, но многие организации ничего от этого не выиграли, потому что они в основном используют внутренние проекты. В GitLab 12.6 создание форка публичных или внутренних проектов создает пул объектов (если он еще не существует) и использует objects/info/alternates, чтобы уменьшить требования к хранилищу форков.
Спасибо Brian Kabiro за этот вклад!
Документация по типам хранилища и пулам объектов и оригинальный тикет.
Обновление виджета мерж-реквеста в реальном времени
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Create”
Раньше, прежде чем нажать кнопку «Merge», вы должны были обновить страницу, если вы сделали хотя бы небольшое исправление (пуш или принятие предложения). Это замедляет последние этапы ревью при применении окончательных исправлений. В GitLab 12.6 виджет мерж-реквеста теперь обновляется в режиме реального времени, так что вы можете выполнять мерж сразу или после успешного выполнения конвейера.
Документация по мерж-реквестам и оригинальный тикет.
Теперь не нужна авторизация клиента для инструментов визуального ревью
(STARTER, PREMIUM, ULTIMATE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Verify”
В GitLab 12.0 мы представили инструменты визуального ревью, чтобы пользователи могли оставлять отзывы к мерж-реквестам сразу из приложения для ревью.
В GitLab 12.6 мы упростили использование этого инструмента, избавив от необходимости создавать личный токен доступа для обратной связи.
Документация по инструментам визуального ревью и оригинальный тикет.
Унаследованные переменные теперь видны при просмотре проекта
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Verify”
При одновременном использовании переменных проекта и группы может быть трудно понять, какие переменные группы существуют и как они могут быть связаны или конфликтовать с переменными уровня проекта. Теперь мы показываем групповые (унаследованные от группы) переменные на странице переменных проекта, что позволяет легко видеть, где определяются переменные.
Документация по переменным уровня группы и оригинальный тикет.
Конечная точка API для списка пакетов группы
(PREMIUM, ULTIMATE, SILVER, GOLD) Стадия цикла DevOps: “Package”
В рамках реестра пакетов GitLab мы предоставляем API, чтобы пользователи могли просматривать, загружать и удалять пакеты. Однако до недавнего времени API был ограничен конкретным проектом, который не давал пользователям понять, какие пакеты существуют на уровне группы.
В GitLab 12.6 мы рады объявить о новой конечной точке API, которая позволит пользователям получать список всех пакетов на уровне группы.
Документация по API для пакетов и оригинальный тикет.
Редактирование релиза через страницу релизов
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Release”
В GitLab 12.6 мы добавляем возможность редактировать заголовки и заметки релиза прямо в пользовательском интерфейсе вместо использования API GitLab. Это ускоряет и облегчает редактирование релизов.
Документация по редактированию релизов и оригинальный тикет.
Управление подключением переключаемых фич на основе идентификатора пользователя
(PREMIUM, ULTIMATE, SILVER, GOLD) Стадия цикла DevOps: “Release”
Теперь вы можете определить различные целевые userID для ваших переключаемых фич для каждого окружения. С помощью этой комбинации вы можете нацеливать разных пользователей на продакшн и на staging (или другой этап), что позволит вам полностью контролировать, как, где и кому будет подключена ваша фича.
Документация по переключаемым фичам и оригинальный тикет.
Удаление связанных ресурсов при удалении кластеров Kubernetes
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Configure”
Повторное использование кластеров между инстансами, группами или проектами может отнимать много времени, поскольку операторы сначала должны убедиться, что все связанные ресурсы кластера (такие как пространства имен, роли, привязки и т. д.) удалены из кластера до его привязки к новой сущности. Часто операторы решают уничтожить кластер и создать новый, чтобы избежать ручного удаления ресурсов.
GitLab теперь позволяет легко удалить все связанные ресурсы кластера при удалении интеграции, что ускоряет и облегчает повторное использование кластеров в других местах.
Документация по удалению интеграции и оригинальный тикет.
Автоматическое использование настроенного файла значений для развертывания в Auto DevOps
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Configure”
Автоматическое развертывание Auto DevOps теперь позволяет выполнять массовую настройку значений в Helm chart. Если просто добавить в проект файл .gitlab/auto-deploy-values.yaml, Auto DevOps обнаружит его и будет использовать его значения для развертывания. Это исключает необходимость создания нескольких переменных окружения HELM_UPGRADE_EXTRA_ARGS для вашего проекта и также дает преимущество контроля версий.
Документация по Auto DevOps и оригинальный тикет.
Cloud Run для поддержки Anthos в кластерах Kubernetes для GKE
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Configure”
При создании кластера Kubernetes с помощью интеграции GitLab с GKE пользователи теперь могут при желании включить «Cloud Run on Anthos» одним щелчком мыши. GKE автоматически обеспечит кластер обслуживанием Knative, Istio и балансировкой нагрузки HTTP, а Cloud Run проследит за обновлением кластера. После установки пользователи могут по-прежнему использовать возможности, предоставляемые GitLab Serverless для развертывания служб Knative с минимальной конфигурацией.
Обратите внимание. Мы объявили о поддержке Cloud Run для Anthos в GitLab 12.4, однако потом нам пришлось отключить ее из-за проблем совместимости. Мы прилагаем все усилия, чтобы обеспечить надежную интеграцию в будущем.
Документация по управлению кластерами и оригинальный тикет.
Поддержка Knative 0.9
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Configure”
Начиная с GitLab 12.6 при установке Knative в качестве управляемого приложения GitLab будет установлена версия 0.9. Это серьезное обновление в жизни Knative. Knative Serving получил свои окончательные конечные точки API v1 и считается готовым к продакшну, но конечные точки beta и alpha по-прежнему доступны. Учитывая стабильный API, это обновление также обеспечивает некоторый уровень прямой совместимости.
Документация по кластерам и оригинальный тикет.
Отображение последних поисков при фильтрации ошибок
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Monitor”
Вы уже сталкивались с этим. Вы устраняете ошибку, обнаруженную в вашем приложении, и вам приходится часто переключаться между поисками в вашем списке ошибок. Начиная с GitLab 12.6 вы сможете быстро выбирать недавние поиски при фильтрации ошибок.
Документация по списку ошибок и оригинальный тикет.
Сортировка списка ошибок по обнаруженным в первый/последний раз и по частоте
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Monitor”
Ошибок часто так много, что бывает сложно найти важные — те, что влияют на ваших пользователей. Начиная с GitLab 12.6, когда вы просматриваете список ошибок Sentry в GitLab, вы сможете отсортировать ошибки по частоте и по времени, когда ошибка возникла впервые или в последний раз.
Документация по списку ошибок и оригинальный тикет.
Добавлена поддержка PHP для проверки соответствия лицензии
(ULTIMATE, GOLD) Стадия цикла DevOps: “Secure”
Если вы используете PHP в своем проекте, то теперь вы можете использовать нашу фичу соответствие лицензии (License Compliance). Обратите внимание, что эта фича пока экспериментальная. Мы добавили поддержку PHP, уделяя особое внимание проектам на основе composer (с использованием composer.lock).
Документация по соответствию лицензии и оригинальный тикет.
Сканирование зависимостей для Gradle-проектов на Java
(ULTIMATE, GOLD) Стадия цикла DevOps: “Secure”
Пользователи с проектами Gradle на Java теперь могут использовать нашу фичу сканирование зависимостей.
Документация по сканированию зависимостей и оригинальный тикет.
SAST для манифестов Kubernetes
(ULTIMATE, GOLD) Стадия цикла DevOps: “Secure”
Манифесты Kubernetes теперь можно проверять на наличие конфиденциальных данных, таких как секретные ключи и привилегии, используя kubesec.
Документация по поддерживаемым SAST языкам и фреймворкам и оригинальный тикет.
SAST теперь работает с частными зависимостями
(ULTIMATE, GOLD) Стадия цикла DevOps: “Secure”
Проекты с зависимостями, размещенными в частном репозитории, теперь могут передавать учетные данные аутентификации для частного репозитория в контейнер SAST, чтобы команда анализа могла их использовать.
Документация по безопасности SAST и использованию переменных окружения для передачи учетных данных и оригинальный тикет.
Логи веб-хуков теперь доступны для интеграции CI
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) “Enablement”
Чтобы помочь пользователям в устранении неполадок интеграции CI, мы добавили лог последних событий на страницы настройки интеграции. Он доступен на страницах настроек интеграции для Jenkins, Packagist, Team City, DroneCI, Buildkite и Bamboo. В этом новом разделе перечислены события, которые использовали эту интеграцию за последние два дня.
Это особенно ценно, когда вы пытаетесь устранить неполадки, возникающие при сбое интеграции, поскольку ранее в интерфейсе пользователя не было места, где бы прямо отображались эти ошибки. Теперь вы сможете легко понять, что и почему сломалось (а что сейчас работает!).
Документация по интеграции CI, оригинальный тикет и мерж-реквест.
Сокращение использования памяти GitLab с помощью Puma (экспериментальная фича)
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) “Enablement”
Чтобы уменьшить требования GitLab к использованию памяти, мы переходим с Unicorn на Puma. Puma поддерживает многопоточность, что поможет уменьшить объем используемой GitLab памяти примерно на 30%.
Поддержка Puma в настоящее время является экспериментальной, но мы работаем над тем, чтобы включить Puma по умолчанию в 13.0. Вы можете попробовать эту фичу на тестовой системе уже сегодня и сообщить о любых проблемах.
Документация по Puma и оригинальный тикет.
Подробные release notes и инструкции по обновлению/установке можно прочитать в оригинальном англоязычном посте: GitLab 12.6 released with Security Scorecard and Release Evidence.
Над переводом с английского работали @cattidourden, @maryartkey, @ainoneko и @rishavant.
