Команда GitLab стремится к повышению производительности и степени удовлетворённости разработчиков. Релиз 13.6 содержит все необходимые ингредиенты, которые помогут вам достичь этого и, возможно, чего-то ещё! Мы надеемся, что вам пригодятся основные фичи релиза, а также ещё более 60 новых фич и улучшений, добавленных в этом релизе.
Простота использования и автоматизация для повышения эффективности
Чтобы вам было проще начать работу с CI/CD GitLab на Amazon Web Services (AWS), мы добавили поддержку AWS к нашей фиче Auto DevOps, так что теперь вы можете запускать автоматические развёртывания на EC2, используя Auto DevOps без Kubernetes (который ранее требовался в Auto DevOps).
Docker Hub ввёл ограничения по количеству запросов docker pull для бесплатных планов. Мы постарались смягчить последствия этих ограничений для наших SaaS- и самостоятельных установок, а также мы предлагаем способы отслеживания этих лимитов с помощью с Prometheus в ваших окружениях. Мы хотим, чтобы все наши пользователи могли безопасно использовать CI/CD конвейеры (в русской локализации GitLab «сборочные линии») и кластеры Kubernetes, поэтому мы переводим прокси зависимостей (Dependency Proxy) в план Core, доступный для всех.
Мы прислушались к мнению сообщества о том, что имя ветки по умолчанию должно быть настраиваемым, и теперь владельцы групп могут указать для новых репозиториев исходное имя ветки по умолчанию, отличное от master. Кстати о настройках по умолчанию, теперь вы можете задать шаблон мерж-реквеста (в русской локализации GitLab «запрос на слияние») для редактора статических сайтов, благодаря чему вам больше не придется переходить к свежепредложенному мерж-реквесту только ради добавления описания.
Большая наглядность для более быстрого принятия решений
Нельзя исправить то, что нельзя найти. С релизом 13.6 мы внесли улучшения в несколько панелей и отчётов, чтобы повысить наглядность и помочь вам быстрее принимать решения.
С помощью данных о степени качества кода, включённых в мерж-реквест, и полного отчёта о качестве кода, вы сможете быстро определить, какие проблемы, связанные с качеством кода, необходимо решить до мержа. Спасибо нашему сообществу, а именно Vicken Simonian, за вклад с отчётом по качеству кода!
Мы обновили панель безопасности проекта, добавив результаты последнего сканирования безопасности конвейера, а также динамический график тенденций уязвимостей, чтобы вы были в курсе трендов развития уязвимостей в реальном времени и в прошлом. Мы также добавили результаты фаззинг-тестирования в виджет мерж-реквеста вместе с другими отчётами по безопасности и улучшили читаемость этого отчёта, добавив имя исходного файла и номер строки, чтобы вы могли быстро найти точное место падения приложения и исправить его.
Администраторы инстансов GitLab с самостоятельным управлением теперь могут отслеживать тенденции использования в своей организации разных фич, например, количество пользователей, проекты, группы, тикеты и конвейеры за последние 12 месяцев.
Улучшили работу с другими сервисами
Мы считаем, что GitLab должен хорошо взаимодействовать с другими популярными инструментами, которыми часто пользуются совместно с GitLab, чтобы обеспечить органичное взаимодействие, даже если вы используете не все возможности GitLab. Чтобы обеспечить лёгкий доступ и совместную работу в VS Code, в релизе 13.6 мы улучшили наше расширение для VS Code. Теперь вы сможете вставлять сниппеты, а также просматривать и комментировать мерж-реквесты и тикеты непосредственно из VS Code, вместо того, чтобы переключаться в интерфейс GitLab.
Интеграции теперь могут быть настроены на уровне группы наряду с уровнем инстанса и уровнем проекта, что поможет владельцам групп легко управлять интеграциями.
И это ещё не всё
Для того чтобы вы могли преодолеть ограничение в 10 ГБ на проект, мы недавно ввели возможность приобретать дополнительное место. В дополнение к прокси зависимостей, мы также переместили трассировку в Core в рамках этого релиза.
Это всего лишь несколько новых фич и улучшений производительности из этого релиза, об остальных мы расскажем подробнее далее в статье. Если вы хотите заранее узнать, что вас ждёт в следующем месяце, загляните на страницу будущих релизов, а также посмотрите видео по релизу 13.7, где наши менеджеры рассказывают о ключевых фичах следующего релиза.
Приглашаем на наши встречи.
MVP этого месяца — Sashi
Sashi добавил ключевой набор возможностей для веб-хука GitLab, который добавляет события, когда изменена подключаемая фича или запустилось развёртывание. Sashi также добавил в чат уведомление о начале установки.
Огромное спасибо Sashi за эти вклады!
Основные фичи релиза GitLab 13.6
Автоматическое развёртывание в EC2
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Release
Теперь Auto DevOps поддерживает развёртывание в Amazon Web Services. Вы можете развёртывать в AWS Cloud Compute (EC2) и использовать при этом все преимущества Auto DevOps от GitLab, даже без использования Kubernetes. Для этого необходимо включить Auto DevOps и определить переменные окружения для AWS: AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY и AWS_DEFAULT_REGION. Это позволяет создать собственную инфраструктуру, используя API AWS CloudFormation. После этого вы можете отправить ранее собранный артефакт в корзину AWS S3 и развернуть его содержимое на инстансе AWS EC2. Ваше развёртывание EC2 автоматически соберёт полный автоматический конвейер поставки без каких-либо дополнительных ручных действий.
Документация по настраиваемым сборкам в Auto DevOps и оригинальный тикет.
Поддержка коллекций Postman для фаззинг-тестирования API
(ULTIMATE, GOLD) Стадия цикла DevOps: Secure
Теперь вы можете использовать коллекции Postman для тестирования API фаззингом! Коллекции Postman — это предустановленные описания ваших API, которые вы, вероятно, уже создавали в процессе тестирования. А если вы этого ещё не делали, создать их очень просто.
Это отличный способ использовать фаззинг-тестирование с уже имеющимися у вас ресурсами. Чтобы использовать коллекцию Postman для фаззинг-тестирования, добавьте её в ваш репозиторий и укажите её расположение в файле .gitlab-ci.yml. После чего движок фаззинга будет ссылаться на эту коллекцию для проведения фаззинг-тестирования.
Тестирование API фаззингом с использованием коллекции Postman выполняет все те же проверки, что и тестирование фаззингом с помощью спецификации OpenAPI или HAR-записи. У нас есть пример проекта, к которому вы можете обратиться, чтобы быстрее начать работу.
Документация по использованию коллекций Postman для фаззинг-тестирования и оригинальный тикет.
Отображение данных о степени качества кода
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Verify
Фича «качество кода» (code quality) в GitLab позволяет узнать, какие нарушения качества кода существуют в проекте на данный момент или же вносятся в мерж-реквесте. Однако понимание того, какие из этих нарушений являются наиболее существенными, ранее не было очевидным при работе в интерфейсе GitLab.
Благодаря полному отчёту о качестве кода в виджете мерж-реквеста вы сможете увидеть оценку степени серьёзности нарушений. Теперь вы сможете понять, какие нарушения качества кода наиболее важны и требуют устранения до мержа, и сократить технический долг в вашем проекте.
Документация по виджету качества кода и оригинальный тикет.
Отображение покрытия кода тестами для выбранных проектов
(PREMIUM, ULTIMATE, SILVER, GOLD) Стадия цикла DevOps: Verify
В 13.4 мы выпустили первую итерацию данных о покрытии кода для проектов группы, которая позволяла сравнить покрытие кода тестами среди нескольких проектов и загрузить данные в общем файле с того же экрана. Однако для анализа данных необходимо было открыть файл и самостоятельно просмотреть его, а затем, возможно, импортировать данные в электронную таблицу для дальнейшего анализа. В GitLab 13.6 вы можете выбрать конкретные проекты группы, чтобы просмотреть последние значения их покрытия непосредственно в интерфейсе GitLab, без необходимости загружать файл и тратить время на получение доступа к данным о покрытии кода. Мы будем рады, если вы напишете отзывы о том, как эта фича работает, и что можно было бы улучшить в будущих итерациях в специальном тикете для фидбэка.
Документация по проверке покрытия кода проектов тестами и оригинальный тикет.
Создавайте тест-кейсы в GitLab
(ULTIMATE, GOLD) Стадия цикла DevOps: Plan
Мы сделали первый шаг к управлению качеством на уровне проекта. В этом первом релизе вы можете создавать и просматривать тест-кейсы в GitLab.
Объединение всех ваших инструментов управления качеством в единой системе DevOps необходимо, чтобы создать главный источник информации и общее место для всех участников, где они могут взаимодействовать друг с другом и отслеживать контекст. Возможность создавать тест-кейсы в GitLab — первый шаг в этом направлении. Мы намерены продолжать работу на этой базе, добавив тестовые сессии, панель управления качеством и возможность просматривать историю тестов по нескольким целям развёртывания, например staging и production.
Чтобы узнать больше о том, как мы планируем развивать эту фичу, или внести свой вклад, посетите страницу «Управление качеством».
Документация по тест-кейсам и оригинальный тикет.
Управление интеграциями проектов на уровне групп
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Create
В релизе 13.3 мы добавили возможность подключить интеграцию для всего инстанса. В GitLab 13.6 мы добавили возможность управлять интеграциями и на групповом уровне!
Теперь владельцы группы могут добавить в группу интеграцию, которая будет унаследована всеми проектами, входящими в эту группу. Это может сэкономить огромное количество времени, так как многие организации используют определённые интеграции, которые необходимо внедрить в каждый проект, над которым они работают.
Отличный пример использования этой фичи — подключение нашей интеграции с Jira. Если вы используете Jira, то она почти всегда используется везде в компании. Некоторые из компаний работают с тысячами проектов и ранее были вынуждены настраивать интеграцию для каждого по отдельности.
С помощью управления интеграциями проектов на уровне группы вы сможете добавить интеграцию в родительскую группу, уменьшив количество необходимых настроек на порядок!
Узнайте больше в соответствующем анонсе в блоге GitLab.
Документация по управлению интеграциями проекта и оригинальный эпик.
Графики выполнения работ и точные отчёты
(STARTER, PREMIUM, ULTIMATE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Plan
График выполнения работ (burndown chart) по майлстоуну (в русской локализации GitLab «этап») или итерации помогает отслеживать прогресс в выполнении общего объёма работ, но не даёт представления о том, как менялся объём работ в течение временного блока (timebox). Кроме того, в нём не сохранялась историческая точность в отношении того, какая часть изначально выделенного объёма работ по этапу или итерации была фактически выполнена.
Чтобы решить эти проблемы и предоставить командам лучшее представление о причинах разрастания сроков, майлстоуны и итерации теперь показывают график выполнения работ в виде burnup chart, в котором отображается общее количество и вес тикетов, добавленных и решённых в течение заданного временного блока.
Мы также переработали графики выполнения работ для использования неизменяемых событий состояния ресурса, что гарантирует, что графики выполнения работ в майлстоунах и итерациях останутся исторически точными[1] даже после того, как вы переместили тикеты в другое временное окно.
[1] Это относится только к майлстоунам и итерациям, созданным в GitLab 13.6 или более поздних версиях. Созданные до 13.6 майлстоуны по-прежнему будут иметь доступ к старым графикам выполнения работ.
Документация по графикам выполнения работ и оригинальный тикет.
Меняйте значение canary-weight через API
(PREMIUM, ULTIMATE, SILVER, GOLD) Стадия цикла DevOps: Release
Добавление поддержки аннотации canary-weight — это первая итерация в реализации балансировщика нагрузки в GitLab. Наша цель — предоставить простой способ конфигурации аннотаций NGINX, чтобы вы могли легко настроить их поведение. Проще говоря, это даст вам дополнительную гибкость при настройке сложных развёртываний. Ранее изменение canary-weight поддерживалось только через файл .gitlab-ci.yml. Теперь у вас будет больше контроля над вашими развёртываниями, а также возможность внедрять развёртывания по триггеру.
Документация по canary-развёртываниям и оригинальный тикет.
Запускайте веб-хук при переключении подключаемой фичи
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Release
Как разработчик вы можете использовать веб-хуки GitLab для различных событий, таких как события мерж-реквестов, конвейера, заданий и развёртывания. С этого релиза вы также можете запускать веб-хук, когда была переключена подключаемая фича (feature flag). Это упрощает процесс обновления CI/CD конвейеров, получения в Slack уведомлений о событиях и не только. Огромное спасибо Sashi за этот вклад от сообщества!
Документация по веб-хукам и оригинальный тикет.
Сортировка релизов по имени на странице релизов
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Release
Страница релизов может быть запутанной и трудной для навигации, если у вас сотни тегов релизов с примечаниями к ним. С введением нового механизма сортировки вам больше не придётся вручную просматривать релизы каждый раз перед развёртыванием. Теперь вы можете сортировать релизы по дате и названию, чтобы находить нужную информацию более эффективно.
Документация по релизам и оригинальный тикет.
Другие улучшения в GitLab 13.6
Требование подтверждения новых учётных записей администратором включено по умолчанию
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Manage
В GitLab 13.5 мы ввели возможность требовать подтверждения администратором регистрации новых пользователей. Для повышения безопасности нашей конфигурации по умолчанию, GitLab 13.6 включает эту опцию для всех новых инстансов. Мы также добавили уведомления для администраторов по электронной почте при новых регистрациях и уведомления для пользователей, когда их регистрация одобрена. Уведомления по электронной почте на этих важных этапах помогают сократить время оформления новых пользователей, если требуется одобрение администратора.
Документация по подтверждению регистраций администраторам и оригинальный эпик.
Экспорт мерж-реквестов в CSV
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Manage
Многие организации обязаны документировать изменения (мерж-реквесты) и данные по ним, например, кто является автором мерж-реквеста, кто его одобрил и когда эти изменения были отправлены в продакшен. Хотя этот список и не является исчерпывающим, он подчёркивает необходимость отслеживаемости и удобного экспорта этих данных из GitLab для выполнения требований аудита или других нормативных требований.
Раньше вам нужно было использовать наш API мерж-реквестов, чтобы собрать эти данные с помощью пользовательских инструментов. Теперь же вы можете нажать одну кнопку и получить CSV-файл, содержащий всю необходимую информацию.
Документация по экспорту в CSV и оригинальный тикет.
Улучшили список членов группы
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Manage
Список членов группы был переработан с использованием нашей системы дизайна Pajamas. Обновления включают в себя более понятную терминологию, новую компоновку, заголовки для всех столбцов, подсказки для ключевых элементов и не только! Новое представление поможет администраторам групп быстрее определять ключевые атрибуты участников группы для более эффективного управления группой.
Документация по работе с группой и оригинальный эпик.
Фильтрация по итерациям для досок и списков задач
(STARTER, PREMIUM, ULTIMATE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Plan
В рамках наших непрерывных усилий по улучшению использования временных блоков (timeboxes) для планирования и отслеживания работы в GitLab, мы добавили фильтрацию по итерации для списков задач и досок. Например, команда, использующая итерации для двухнедельного спринта, теперь может использовать ограниченный список заданий или доску как единый источник информации о задачах в конкретном спринте.
Документация по использованию фильтров в списках тикетов и мерж-реквестов и оригинальный тикет.
Отслеживайте состояние тикетов из списка тикетов
(ULTIMATE, GOLD) Стадия цикла DevOps: Plan
Если вам приходится управлять большим количеством тикетов в работе, может быть трудно отследить их состояние здоровья, особенно если вы работаете с несколькими эпиками (в русской локализации GitLab «цели»). Теперь в интерфейсе списка тикетов отображается их состояние, что позволит вам быстро получить краткое представление о текущем состоянии работы. В следующей итерации мы также добавим фильтрацию.
Документация по состоянию здоровья тикетов и оригинальный тикет.
Настраивайте место назначения для изображений, загруженных из редактора статических сайтов
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Create
В GitLab 13.6 появилась возможность загружать графические ресурсы через статический редактор сайтов непосредственно в ваш проект. Изображения, загружаемые с вашего компьютера, включаются в итоговый мерж-реквест, и по умолчанию для загружаемых ресурсов используется каталог source/images. Однако, в зависимости от структуры вашего проекта, вы можете захотеть хранить свои изображения в другом месте. А каталог по умолчанию может даже не существовать.
Файл .gitlab/static-site-editor.yml позволяет настроить поведение редактора. Укажите в image_upload_path абсолютный путь к каталогу ваших ресурсов, чтобы наш редактор статических сайтов знал, где вы хотите хранить изображения в вашем проекте.
Документация по файлу конфигурации и оригинальный тикет.
Фильтр мерж-реквестов по окружению и времени развёртывания
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Create
Теперь вы можете фильтровать мерж-реквесты по окружению и времени развёртывания в дополнение к уже существующим фильтрам по ID развёртывания. Это означает, что теперь вы можете находить мерж-реквесты по имени окружения, ID развёртывания или времени развёртывания (до или после определённого момента). Использование комбинации этих фильтров может помочь вам понять, какие развёртывания были запущены в окружении за определённый период времени.
Документация по фильтрации мерж-реквестов по окружению и дате развёртывания и оригинальный тикет.
Добавление LFS-файлов Git в архив репозитория
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Create
Хранилище крупных файлов LFS — это одно из решений Git для работы с крупными файлами. Оно заменяет крупные файлы на указатели на них. Содержимое файлов хранится на удалённом сервере, например GitLab. Это позволяет разработчикам управлять версиями для очень больших файлов, при этом операции Git между локальным хостом и сервером остаются быстрыми и эффективными.
Ранее при скачивании из GitLab архива с исходниками, который содержит LFS-файлы, экспортировался указатель на файл вместо самого файла. Это уменьшало размер архива, но при этом архив не содержал полный снимок репозитория. Это значит, что пользователям приходилось делать много ручной работы, добавляя каждый LFS-файл в отдельности, чтобы получить полную копию репозитория.
GitLab 13.6 будет экспортировать LFS файлы целиком, а не только указатели на них, что позволит получать полную копию содержимого вашего репозитория.
Документация по LFS-объектам в архивах проекта и оригинальный тикет.
Тикеты и мерж-реквесты в VS Code
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Create
Тикеты являются источником достоверной информации по тому, что необходимо сделать в проекте, и подходящим местом для совместной работы. Чтобы ссылаться на истории пользователей, дизайны и обсуждения к тикетам, приходится переключаться между редактором и браузером. В комментариях к мерж-реквестам вы получаете обратную связь по предлагаемым изменениям. Чтобы ссылаться на эту обратную связь и продолжать вносить изменения, вам также приходится переключать контекст между редактором и браузером.
Уменьшение задержки, связанной с переключением контекста, делает более эффективным внесение изменений в проект. С релизом 3.6.0 GitLab Workflow, вы можете работать с тикетами и мерж-реквестами напрямую в VS Code. Вы можете искать тикеты и мерж-реквесты, назначенные вам или созданные вами, получать доступ к необходимой информации в тикетах и мерж-реквестах и комментировать их.
Это первый шаг к возможности проводить более полные ревью мерж-реквестов в VS Code.
Документация по интеграции с VS Code и оригинальный тикет.
Уникальный идентификатор дизайна
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Create
Изначально все дизайны относились к тикетам и имели URL, который включает ID и имя файла дизайна. Это накладывает много ограничений на архитектуру управления дизайнами, так как вы не можете ссылаться на поле внутреннего идентификатора дизайна.
Хотя эта фича носит чисто технический характер, она создаёт основу для использования дизайнов во многих местах в GitLab. С уникальными внутренними идентификаторами мы сможем добавить привязку дизайнов к мерж-реквестам, эпикам и на уровне проекта.
Документация по управлению дизайнами и оригинальный тикет.
Генерация HTML-отчётов для качества кода
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Verify
Отчёты о качестве кода (Code Quality) дают вам много различной информации о нарушениях в качестве кода, найденных в текущей ветке, однако они генерируются в довольно неудобном для чтения формате.
Теперь этот вид отчёта доступен в формате файла .html, так что вам будет удобнее просматривать нарушения в качестве кода вашего проекта и определять их значимость. Вы даже можете хостить этот файл на GitLab Pages для ещё более удобного ревью.
Спасибо Vicken Simonian за эту фичу!
Документация по генерации HTML-отчётов по качеству кода и оригинальный тикет.
Добавление нескольких файлов конфигурации CI/CD в виде списка
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Verify
Ранее при добавлении нескольких файлов для вашей конфигурации CI/CD с использованием синтаксиса include:file, вы должны были задавать проект и ссылку для каждого файла. Начиная с этого релиза у вас появляется возможность передавать проект, ссылку и список файлов одновременно. Это позволит вам не повторять одни и те же действия несколько раз и сделает конфигурацию вашего конвейера менее запутанной.
Документация по синтаксису include:file и оригинальный тикет.
Отображение данных покрытия при неудачном завершении конвейера
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Verify
Мейнтейнеры проекта (в русской локализации GitLab «сопровождающие») могут выбрать использование бейджей отображения текущего покрытия проекта тестами. К сожалению, если конвейер выполняется долго, в нём есть ручные шаги или он завершается с ошибкой для ветки, связанной с бейджем, значение покрытия будет отображаться как «неизвестно». Это делает бейджи менее полезными для вас.
Теперь ваш конвейер не должен быть полностью успешным, чтобы отображалось значение покрытия, благодаря чему вам будет проще увидеть его статус. Вы можете быть уверены в значении покрытия тестами для вашего проекта (например, перед шагом ручного релиза), без необходимости разбираться в списке заданий.
Документация по бейджам для конвейера и оригинальный тикет.
Улучшенная работа с отчётами по юнит-тестам
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Verify
Отчёты по юнит-тестам — это отличный способ проводить ревью результатов тестов через конвейер. Однако наличие крупных кусков логов может сделать страницу очень длинной и неудобной для навигации. Также вам может быть сложно найти тест, который вы хотели проверить в отчёте по юнит-тестам, так как имя файла теста отсутствовало на странице отчёта.
С релизом GitLab 13.6 имя файла, которое находится в файле отчёта по юнит-тесту, становится доступным на странице, что упрощает поиск. Также содержимое логов удаляется из основного списка и становится доступным в модальном окне, что значительно улучшает работу со списком.
Документация по отчётам по юнит-тестам в GitLab и оригинальный тикет.
Конечная точка npm на уровне проекта работает со всеми командами npm
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Package
Когда вы используете реестр пакетов для публикации и распространения пакетов Node, вы можете выбирать использование конечной точки на уровне инстанса или на уровне проекта. Конечная точка на уровне проекта наиболее полезна, когда у вас есть несколько пакетов в одной группе; конечная точка на уровне инстанса удобна, когда у вас есть несколько пакетов в разных группах.
Проблема заключалась в том, что конечная точка проекта не поддерживала многие распространённые команды npm, включая npm dist-tag, npm add и npm view. В качестве обходного пути вы могли задавать publishConfig в каждом package.json. Хотя этот обходной путь и работал, у него было несколько недостатков:
- Вам приходилось выполнять дополнительные действия при публикации пакетов, так как каждый пакет нужно было настраивать для публикации в реестре проекта.
- Это усложняло автоматизацию. Например, переменные окружения можно было заменять внутри
.npmrc, но не вpackage.json. Из-за этого вам приходилось хардкодить ID проекта GitLab в вашемpackage.json. - Это не соответствовало ожиданиям разработчиков, которые не привыкли к такому рабочему процессу.
Чтобы решить эти проблемы, мы сделали все поддерживаемые конечные точки доступными для использования в инстансах и проектах. Теперь вы можете использовать ваш файл .npmrc, чтобы настроить реестр пакетов. Вы больше не должны добавлять и поддерживать publishConfig в каждом package.json со следующими исключениями:
- Конечная точка загрузки должна быть на уровне проекта. Она не может находиться на уровне инстанса, так как серверная часть получит запрос на загрузку без привязки к группе или проекту и не будет знать, где хранить загружаемый пакет.
- Конечная точка файла архива остаётся на уровне проекта. В ходе выполнения команды
npm installnpm запрашивает URL архива. Реестр пакетов должен в ответ передать локацию, которая может быть где угодно. Чтобы не усложнять этот процесс, мы оставим её там, где она находится сейчас: на уровне проекта.
Документация по конечной точке npm на уровне проекта и оригинальный тикет.
Артефакты фаззинг-тестирования на основе покрытия доступны в виджете мерж-реквеста
(ULTIMATE, GOLD) Стадия цикла DevOps: Secure
Результаты фаззинг-тестирования на основе покрытия теперь отображаются в результатах сканирования безопасности наряду с результатами других сканирований безопасности мерж-реквеста. Это позволит вам быстро понимать, были ли найдены проблемы в ходе тестирования, получать детальную информацию о них и скачивать артефакты, необходимые для воспроизведения проблемы локально до того, как код будет смержен.
Документация по взаимодействию с уязвимостями при фаззинг-тестированиях и оригинальный тикет.
Новый механизм для фаззинг-тестирования проектов на Java
(ULTIMATE, GOLD) Стадия цикла DevOps: Secure
Мы представляем новый механизм фаззинг-тестирования на основе покрытия для кода на Java. Это базовый механизм, который лежит в основе ваших фаззинг-тестирований на конвейере, он называется javafuzz и его можно использовать, задав переменную --engine javafuzz в вашем файле конвейера.
Мы рекомендуем в будущем использовать новый механизм javafuzz вместо существующего механизма JQF. Новый механизм поддерживает фреймворк Java Spring, где, как мы ожидаем, он будет очень полезен.
Кроме того, у нового механизма открытый исходный код, он распространяется под лицензией Apache. Мы будем рады узнать, что вы думаете, и рассмотреть любые улучшения, которые вы предложите.
Документация по поддерживаемым механизмам и языкам для фаззинг-тестирования и оригинальный тикет.
Статус конвейера на панели безопасности проекта
(ULTIMATE, GOLD) Стадия цикла DevOps: Secure
Панель безопасности проекта является центральным местом управления уязвимостями для команд безопасности и разработчиков. Так как отчёты по безопасности основаны на последнем успешном сканировании конвейера текущей ветки, очень важно быть уверенным в том, что результаты сканирования являются актуальными. Ранее не было никакого способа узнать время или статус последнего сканирования конвейера по умолчанию с этих страниц. Для этого вам приходилось возвращаться к списку конвейеров и искать необходимую информацию там.
Теперь вы можете видеть время последнего сканирования конвейера по умолчанию сверху на панели безопасности проекта, а также ссылку на страницу этого конвейера. Вы также увидите число неудачных завершений конвейера, если они были. Кликнув на ссылку с числом неудачных завершений, вы попадёте на вкладку Неудачные задания (Failed jobs) на странице конвейера. После того как вы разберётесь с причинами неудачи, новый запуск конвейера обновит данные об уязвимостях для проекта, а также область статуса конвейера на панели безопасности.
Документация по отчётам об уязвимостях на панели безопасности и оригинальный тикет.
Поддержка пост-обработки слитых секретных ключей
(FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Secure
GitLab.com теперь поддерживает веб-хуки для пост-обработки поиска секретных ключей. Их можно использовать, например, для отправки уведомлений в облачный сервис, который выдал секретный ключ. Провайдер сервиса может подтвердить учётные данные и быстро отозвать ключ или выдать новый, а также уведомить владельца слитого ключа. Рабочие процессы пост-обработки у разных провайдеров отличаются. С этим релизом GitLab начинает поддерживать пост-обработку для секретных ключей от Amazon Web Services (AWS).
Мы планируем расширить эту интеграцию до других сторонних провайдеров облачных сервисов и SaaS. Если вы как провайдер заинтересованы в интеграции с вашим сервисом, вы можете заполнить эту анкету. Также вы можете узнать больше технических подробностей пост-обработки секретных ключей.
Документация по пост-обработке секретных ключей и оригинальный эпик.
Уведомления в чате о начале развёртывания
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Release
В предыдущих релизах GitLab мы добавили поддержку уведомлений для успешных, отменённых и неудачно завершённых развёртываний. В этом релизе вы также сможете получать уведомления в чат при запуске развёртывания. Эта фича стала доступной благодаря потрясающему вкладу от Sashi! С ней вы сможете удобно отслеживать статус развёртываний, не нарушая привычный вам рабочий процесс.
Документация по триггерам для уведомлений в Slack и оригинальный тикет.
Остановка приложений для ревью при развёртывании через ECS
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Release
Недавно мы добавили поддержку сервиса AWS ECS для развёртываний в него через Auto DevOps. Однако приложения для ревью для целей ECS ранее не останавливались автоматически. Чтобы исправить это, мы расширили шаблон Deploy_ECS, добавив автоматическую остановку приложений для ревью как часть рабочего процесса Auto DevOps, чтобы ресурсы не тратились впустую. Таким образом, опыт работы с Auto DevOps для пользователей, развёртывающих в ECS, и пользователей, использующих Kubernetes, будет одинаковым: операции будут выполняться автоматически, без необходимости вручную останавливать процесс и следить за приложениями для ревью.
Документация по развёртыванию приложений через ECS и оригинальный тикет.
Возможность задавать период истечения срока действия окружения при его создании
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Release
В этом релизе у вас появилась возможность задавать время истечения срока действия приложений для ревью при создании окружения. Ранее срок действия был привязан ко времени начала развёртывания, однако в некоторых окружениях развёртывания никогда не происходят. Эта новая фича позволяет автоматически останавливать окружения на основе времени создания, независимо от статуса развёртывания в нем.
Документация по истечению срока действия окружений и оригинальный тикет.
Предупреждение при запуске устаревших заданий
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Release
Если вы повторно запустите неудачно завершённое задание развёртывания, в окружение может быть записан старый исходный код. Чтобы это не происходило случайно, мы добавили сообщение, которое предупреждает о том, что вы запускаете устаревшее задание.
Документация по настройкам конвейера и оригинальный тикет.
Уведомления на пользовательских панелях
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Monitor
Уведомления помогают разработчикам и специалистам по эксплуатации наблюдать за состоянием сервисов и прерываниями в их работе. Ранее вы могли создавать уведомления только для метрик на стандартных панелях GitLab. Начиная с этой версии GitLab вы можете настраивать уведомления для любых метрик на любых панелях, которые создаёт и использует ваша команда.
Документация по уведомлениям для метрик и оригинальный эпик.
Автоматические фоновые миграции для индексации расширенного поиска
(STARTER, PREMIUM, ULTIMATE, BRONZE, SILVER, GOLD) Доступность
Добавление новых фич для расширенного поиска зачастую означает также добавление или изменение способа индексации контента, и это изменение индекса выполняется постепенно в течение нескольких дней. На протяжении последних нескольких релизов мы добавили много новых фич для расширенного поиска, и поэтому администраторам GitLab пришлось бы вручную производить переиндексацию после каждого обновления.
Начиная с GitLab 13.6 при добавлении новых фич для расширенного поиска переиндексация будет автоматически запускаться в фоне. При необходимости переиндексацию также можно будет запускать вручную.
Документация по фоновым миграциям для Elasticsearch и оригинальный тикет.
Повышение скорости веб-интерфейса GitLab с автоматическим изменением размера изображений
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Доступность
GitLab отображает множество изображений, добавленных пользователями, таких как фото профиля или вложения в тикетах и комментариях. До релиза GitLab 13.6 этот контент поставлялся пользователям без изменений независимо от того, как изображение было использовано на странице. Например, мы позволяем добавлять изображения профиля размером до 200 КБ, и на страницах аналогичным списку коммитов мы можем отображать более 20 таких изображений одновременно. Если каждое изображение в среднем занимает 100 КБ, то в сумме получается 20 МБ данных, что значительно замедляет загрузку страницы.
Для улучшения производительности GitLab теперь автоматически изменяет размер аватаров до размера, используемого на странице, что значительно уменьшает размер контента, который необходимо загрузить. На страницах, которые мы использовали для теста, нам удалось уменьшить размер контента в 10 раз. Это не только ускоряет загрузку страницы, но и использует меньше сетевого трафика.
Вы можете узнать больше о нашем подходе и результатах в этом посте из нашего блога.
Документация по настройкам изменения размера изображений и оригинальный эпик.
Фильтрация по дате и улучшенные таблицы данных для аналитики мерж-реквестов
(STARTER, PREMIUM, ULTIMATE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Manage
В GitLab 13.3 мы представили аналитику мерж-реквестов, которая помогает лучше оценивать эффективность и продуктивность пропускной способности мерж-реквестов. GitLab 13.6 представляет новые улучшения в аналитике мерж-реквестов: теперь у вас есть возможность фильтровать по диапазонам дат, а также данные по количеству подтверждений. А ещё мы добавили пагинацию для таблиц данных.
Документация по аналитике мерж-реквестов и оригинальный эпик.
Создание отчёта для коммита по его SHA
(ULTIMATE, GOLD) Стадия цикла DevOps: Manage
В 13.4 мы добавили отчёт “chain of custody” для всех коммитов мержа в группе. С тех пор ваши отзывы вдохновили нас добавить поддержку экспорта этого отчёта на основе SHA начального коммита. Теперь при экспорте отчёта у вас будет возможность ввести SHA коммита, для которого вы хотите сгенерировать отчёт.
Документация по генерированию отчёта по SHA коммита и оригинальный эпик.
Статистика пользователей, проектов, групп, тикетов, мерж-реквестов и активности конвейера
(CORE, STARTER, PREMIUM, ULTIMATE) Стадия цикла DevOps: Manage
Администраторам часто требуется с одного взгляда понять, как используется GitLab. Статистика инстанса поможет администраторам понять тенденции использования ключевых фич во всем инстансе. Администраторы теперь могут видеть графики, отображающие пользователей, проекты, группы, тикеты и конвейеры за последние 12 месяцев.
В своей первой итерации статистика инстансов требует прав доступа администратора, что означает, что она доступна только в инстансах GitLab, размещённых на собственных серверах. В следующей итерации эти данные станут более доступными для других пользователей, включая пользователей GitLab.com, с возможностью ограничения доступа. Обратите внимание, что статистика инстансов будет переименована в «Тренды использования» в 13.7 в рамках дорожной карты, направленной на то, чтобы сделать эту фичу более доступной.
Документация по статистике инстанса и оригинальный эпик.
Новый способ организации досок задач: группировка по эпикам
(PREMIUM, ULTIMATE, SILVER, GOLD) Стадия цикла DevOps: Plan
Часто при просмотре доски задач бывает трудно определить задачи, которые связаны с конкретной работой. Чтобы обеспечить большую ясность и помочь вам организовать работу в ваших командах, мы выпускаем эпик с первым вариантом «плавательной дорожки» для доски задач. Быстро группируйте свои задачи в горизонтальную дорожку по столбцам доски задач, что позволит вам легко увидеть всю работу, связанную с эпиком, а также в каком состоянии она находится!
Пожалуйста, расскажите: как вам «плавательные дорожки»?
Документация по «плавательным дорожкам» в досках задач и оригинальный эпик.
Используйте кнопку, чтобы превратить тикет в эпик
(PREMIUM, ULTIMATE, SILVER, GOLD) Стадия цикла DevOps: Plan
Ранее превращение тикета в эпик совершалось быстрым действием /promote в описании или комментарии тикета, что несколько замедляло это частое и важное действие. Чтобы сделать это действие более заметным, мы представили новое меню дополнительных действий в заголовке тикета и добавили кнопку, с помощью которой можно быстро перевести тикет в эпик одним щелчком мыши.
Документация по управлению тикетами и оригинальный тикет.
Настройте начальное имя ветки для новых проектов в группе
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Create
При создании нового репозитория Git первая созданная ветка по умолчанию называется master. В сотрудничестве с проектом Git, обширным сообществом пользователей и другими поставщиками Git, GitLab прислушивается к отзывам сообщества разработчиков по поводу определения более информативного имени для ветки по умолчанию, и теперь предлагает пользователям возможность изменения имени ветки по умолчанию для своих репозиториев.
Ранее мы предоставляли возможность настраивать начальное имя ветки на уровне инстанса, а теперь, начиная с 13.6, GitLab позволяет администраторам групп настраивать имя ветки по умолчанию и для новых репозиториев, созданных через интерфейс GitLab.
Документация по настройке имени ветки по умолчанию и оригинальный тикет.
Улучшенные уведомления для управления дизайнами
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Create
До сих пор уведомления о дизайне не очень согласованы с другими уведомлениями GitLab, потому что вы не получали электронное письмо, если вы не были напрямую @упомянуты. Из-за этого было очень трудно отслеживать обсуждения в дизайнах.
В 13.6 мы сделали уведомления по дизайнам единообразными со всеми остальными уведомлениями, поэтому, если вы каким-либо образом участвовали в дизайне (оставили комментарий, ответили или были @упомянуты), вы получите электронное письмо для каждого нового комментария.
Документация по настройке уведомлений по электронной почте и оригинальный тикет.
Вставка сниппетов GitLab прямо в VS Code
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Create
Сниппеты проекта — это место для обмена фрагментами кода, которые повторно используются в нескольких местах или помогают настроить аналогичные страницы и компоненты.
Когда вы вносите свой вклад в проект, вам может понадобиться найти эти фрагменты и вставить их содержимое в ваш рабочий файл. Для их поиска требуется переключение контекста из вашего редактора, а затем копирование/вставка правильной информации.
Используя расширение для VS Code GitLab Workflow v3.5.0, вы сможете вставлять фрагменты в свой рабочий файл, причём поддерживаются как одиночные, так и мультифайловые сниппеты.
Документация по вставке сниппетов через расширение для VS Code и оригинальный тикет.
Шаблон описания мерж-реквеста для редактора статических сайтов
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Create
Для веб-сайтов, созданных с помощью генератора статических сайтов, редактор статических сайтов можно использовать для быстрого редактирования содержимого страницы в знакомом и интуитивно понятном интерфейсе. После завершения редактирования вы даже можете создать мерж-реквест прямо из редактора. В GitLab 13.5 мы добавили возможность задать название и описание мерж-реквеста, но шаблоны описания мерж-реквеста были недоступны. Это означало, что у мерж-реквестов, созданных в статическом редакторе сайтов, были противоречивые описания, и в них не было никакой полезной информации из шаблонов, например чеклистов.
В GitLab 13.6 мерж-реквесты, созданные в редакторе статических сайтов, будут использовать шаблон описания мерж-реквеста по умолчанию, если он был настроен. Кроме того, вы можете выбрать и применить любые другие шаблоны описания, определённые в .gitlab/merge_request_templates, обеспечивая согласованную связь для рецензентов и снижая вероятность того, что вам придётся переходить на страницу мерж-реквеста, чтобы обновить описание после отправки.
Документация по редактору статических сайтов и оригинальный тикет.
Загрузка изображений в редактор статических сайтов
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Create
В GitLab 13.1 добавлена поддержка ссылок на изображения и их предварительного просмотра в редакторе статических сайтов, что отлично подходит, если ваши изображения уже размещены где-то в Интернете. Однако для добавления новых изображений на ваш сайт по-прежнему приходилось использовать альтернативные методы для загрузки ресурсов в репозиторий проекта.
В GitLab 13.6 вы можете не только ссылаться на изображение, но и загружать его в свой проект в статическом редакторе сайтов, и сразу же просматривать его вместе с вашими правками. Щелчок по значку Добавить изображение (Add Image) на панели форматирования теперь открывает и новый вариант — выбор файла с вашего компьютера. После загрузки изображение отображается в режиме WYSIWYG редактора, а после сохранения изменений сам файл включается в мерж-реквест.
Документация по вставке изображений в редакторе статических сайтов и оригинальный тикет.
Статус конвейера в списках веток и тегов
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Verify
Если вы используете конвейеры CI/CD с тегами или ветками и хотите узнать последнее состояние конвейера, ранее вам приходилось переходить от списка веток или тегов к странице конвейера. Теперь значки состояния конвейера отображаются для каждой ветки или тега в соответствующих списках, так что вы можете быстро получить эту информацию для многих тегов или веток за меньшее количество щелчков мышью.
Спасибо Lee Tickett за эту фичу!
Документация по просмотру конвейеров и оригинальный тикет.
Поддержка переменных в rules:changes
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Verify
Чем длиннее ваши скрипты gitlab-ci.yml, тем сложнее их поддерживать и масштабировать. Мы добавили поддержку переменных окружения в ключевое слово rules:changes, так что вы теперь можете использовать переменные для путей или имён файлов, не раздувая ваш CI-файл. Переменные помогают уменьшить общую длину файла конфигурации при выполнении одних и тех же заданий CI для проверки изменений в разных наборах файлов.
Документация по использованию переменных в rules:changes и оригинальный тикет.
Прокси зависимостей теперь с открытым исходным кодом
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Package
Docker Hub недавно начал применять ограничения частоты запросов docker pull из Docker Hub. Частота выполнения таких запросов теперь ограничена в зависимости от вашего индивидуального IP-адреса для анонимных пользователей или вашего тарифного плана, если вы прошли аутентификацию и вошли в систему.
Прокси зависимостей может помочь уменьшить количество запросов docker pull, которые вы делаете из Docker Hub, путём кэширования образов, ранее загруженных через прокси. Чтобы помочь нашим пользователям работать в рамках этих новых ограничений, мы переносим прокси зависимостей в Core. Благодаря поддержке проксирования и кэширования в Core теперь вы можете повысить надёжность и производительность своих конвейеров.
Документация по прокси зависимостей и оригинальный тикет.
Результаты фаззинг-тестирования теперь более читаемые
(ULTIMATE, GOLD) Стадия цикла DevOps: Secure
После того как фаззинг-тестирование находит сбой, следующим шагом будет отладка и определение места сбоя. Это может быть сложно сделать, если есть только шестнадцатеричный адрес, поэтому мы рады сообщить, что теперь мы предоставляем удобочитаемые результаты фаззинг-тестирования с учётом покрытия для всех поддерживаемых языков.
Это значит, что когда вы смотрите на логи падения, вы можете увидеть сопутствующее имя файла и номер строки. Это позволяет легко добраться до места, где произошёл сбой, и исправить его.
Документация по фаззинг-тестированию и оригинальный эпик.
Данные в SAST об уровне серьёзности для уязвимостей Rails
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Secure
Статическое тестирование безопасности приложений (SAST) в GitLab предоставляет данные о серьёзности выявленных уязвимостей, когда эту информацию можно получить от наших сканеров безопасности. Недавно мы обновили наш анализатор Brakeman, чтобы добавить поддержку данных о серьёзности уязвимостей. Эти данные помогут повысить удобство использования и точность правил подтверждения, так как меньшее количество уязвимостей будет сообщать о «неизвестной» серьёзности. В будущем мы дополним другие анализаторы недостающими метаданными уязвимостей и добавим механизм, позволяющий настроить метаданные уязвимостей, чтобы организации могли адаптировать результаты в соответствии с их профилями рисков.
Документация по данным об уязвимостях для анализаторов SAST и оригинальный тикет.
Новый график тенденций уязвимостей
(ULTIMATE, GOLD) Стадия цикла DevOps: Secure
Визуализация основных тенденций уязвимостей уже давно доступна на панелях безопасности группы и в центре безопасности инстанса. Однако на панели безопасности проекта их нет, что затрудняет понимание тенденций на уровне проекта в отношении количества и типов уязвимостей с течением времени.
Наш новый график тенденций уязвимостей обеспечивает эту необходимую видимость на уровне проекта. Кроме того, этот новый график за счёт своей интерактивности ещё более функционален, чем существующие визуализации групп и центра безопасности. Включайте или выключайте линии тенденций серьёзности одним щелчком мыши, чтобы отобразить только те данные, которые вам нужны. Вы также можете изменить временные рамки, чтобы просмотреть данные за год. График тенденций является динамическим, поэтому он обновляется в реальном времени, чтобы отражать ваши изменения.
С включением этого графика вы также заметите, что одностраничная панель безопасности проекта теперь разделена на отдельные страницы для графиков и для списков уязвимостей, что соответствует виду страниц центра безопасности группы и инстанса. Страница отчёта об уязвимостях содержит все функции, которые ранее находились на панели безопасности проекта. Страница «Панель управления безопасностью» останется, но теперь будет содержать новый график тенденций уязвимостей. Разделение этих функций даёт нам отдельное пространство для добавления новых метрик и визуализаций для отслеживания безопасности на уровне проекта в будущем.
Документация по панели управления безопасностью на уровне проекта и оригинальный тикет.
Отключение ранее существовавших правил SAST
(ULTIMATE, GOLD) Стадия цикла DevOps: Secure
Статическое тестирование безопасности приложений в GitLab теперь поддерживает отключение предопределённых правил обнаружения. Изменяя параметры обнаружения уязвимостей по умолчанию, организации могут адаптировать результаты сканирования безопасности. Отключение предопределённых правил исключит обнаружение нерелевантных уязвимостей, что поможет уменьшить количество ложных срабатываний и повысить точность таких шлюзов безопасности, как правила подтверждения безопасности мерж-реквеста, а также уменьшить количество уязвимостей, о которых сообщается на панелях безопасности. Чтобы отключить наборы правил по умолчанию, добавьте в папку .gitlab новый файл с именем sast-rulesets.toml, в котором будут настройки в правильной нотации. Вы можете узнать больше об этом формате файла и посмотреть примеры в нашей документации для пользовательских наборов правил SAST. В будущем мы собираемся представить дополнительные улучшения, такие как импорт пользовательских наборов правил в файлы .gitlab-ci.yml.
Документация по настройке наборов правил безопасности и оригинальный тикет.
Используйте список путей URL для управления сканированием DAST
(ULTIMATE, GOLD) Стадия цикла DevOps: Secure
Веб-тестирование DAST в GitLab всегда зависело от успешного сеанса поискового робота для сканирования сайта и поиска страниц, которые должен тестировать сканер DAST. Он хорошо работает во многих случаях, но может вызвать проблемы, когда на сайте есть скрытые страницы, разделы сайта не связаны друг с другом, или если робот-паук достигает лимита по времени и перестаёт искать страницы. Если время отклика сайта велико из-за того, что он находится в инстансе разработки или по любой другой причине, последний сценарий может значительно уменьшить охват теста DAST при сканировании на наличие уязвимостей.
Чтобы уменьшить проблемы, связанные с обходом сайта, и позволить пользователям точно контролировать, какие части сайта проверяются во время сканирования DAST, мы ввели использование списка URL, которые надо сканировать, вместо набора адресов, получаемых в результатов обхода пауком DAST. Используя новую переменную DAST_PATHS, вы можете включить для сканирования список путей на сайте, указанный в переменной DAST_WEBSITE. Этот список, разделённый запятыми, будет действовать как инструкция и позволит охватить страницы, которые, возможно, не были бы обнаружены поисковым роботом. Это также позволит вам использовать существующие карты сайтов, экспортированные в виде списка, чтобы убедиться, что сканирование DAST охватывает каждую страницу, которую вы хотите протестировать.
Документация по переменным для DAST и оригинальный тикет.
Свяжите релиз с групповым майлстоуном
(PREMIUM, ULTIMATE, SILVER, GOLD) Стадия цикла DevOps: Release
В GitLab 13.0 вы могли связать релиз с майлстоуном, выбрав этот вариант в пользовательском интерфейсе Gitlab. Однако пользователи, использующие групповые майлстоуны не могли связать релиз с таким майлстоуном. Теперь у вас есть возможность легко связать свои групповые планы майлстоунов с релизами.
Документация по связи релизов с майлстоунами и оригинальный тикет.
Поиск списка пользователей по имени в стратегии переключаемых фич
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Release
Ранее мы добавили поддержку списков пользователей в качестве стратегии переключаемых фич. Если у вас уже есть множество списков пользователей, может быть очень трудно найти тот, который вы хотите применить к конкретной стратегии. Чтобы упростить поиск и использование списков пользователей, мы добавили поиск по спискам пользователей при выборе списка для стратегии.
Документация по списку пользователей в качестве стратегии переключаемых фич и оригинальный тикет.
Используйте специальный ключ подписи CI_JOB_JWT для интеграции Vault
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Release
Ваша безопасность имеет первостепенное значение для нас в GitLab. Поддержка актуальности функций, на которые вы полагаетесь, обеспечивает не только новейшую и лучшую функциональность, но и безопасность и защиту ваших конфиденциальных данных. Чтобы повысить общую безопасность, теперь вы можете использовать специальный ключ подписи для метода аутентификации HashiCorp Vault JSON Web Token (JWT). Вы можете быть уверены в безопасности, зная, что JWT нельзя использовать для того, чтобы выдавать одного пользователя за другого через OpenID Connect.
Документация по методу аутентификации HashiCorp Vault и оригинальный тикет.
Установка обработчиков заданий с помощью GitLab Kubernetes Agent
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Configure
Для настройки пользовательских обработчиков заданий (runners) GitLab вы можете использовать приложения, управляемые GitLab, или ручную установку. Хотя управляемые GitLab приложения просты в использовании, этот подход недостаточно гибок для сложных случаев, а ручная установка приводит к тому, что пользователи сами выполняют задачи обслуживания, поскольку она не интегрирована с GitLab. GitLab Kubernetes Agent можно использовать для превращения любого проекта GitLab в проект управления Kubernetes, поэтому мы создали пример репозитория и документации, чтобы показать вам, как использовать его для установки обработчика заданий GitLab. Это предоставит вам интегрированный, ориентированный на GitLab рабочий процесс GitOps для управления вашими настраиваемыми обработчиками заданий.
Документация по GitLab Kubernetes Agent и оригинальный тикет.
Трассировка теперь в Core
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Monitor
Поскольку мы хотели сделать три столпа наблюдаемости доступными в плане Core, мы завершили последнюю часть и переместили трассировку в GitLab Core. Чтобы узнать больше о возможностях трассировки, загляните в документацию.
Документация по трассировке и оригинальный тикет.
Полный текст релиза и инструкции по обновлению/установке вы можете найти в оригинальном англоязычном посте: GitLab 13.6 released with Auto Deploy to EC2 and Usage Trends Dashboard.
Над переводом с английского работали cattidourden, maryartkey, ainoneko и rishavant.
