В прошедший День Земли мы думали о росте. Наши клиенты масштабируют свои DevOps-процессы, и с их ростом возрастает потребность в ещё большей эффективности и автоматизации контроля. GitLab Kubernetes Agent теперь доступен на GitLab.com, что позволит вам воспользоваться преимуществами быстрых развёртываний на вашем кластере благодаря затягиванию изменений из GitLab, в то время как GitLab.com будет управлять необходимыми серверными компонентами агента. Вы сможете настраивать для проверки соответствия требованиям специальные конвейеры (в русской локализации GitLab «сборочные линии»), которые будут в обязательном порядке выполняться для любого проекта с назначенным набором правил, даже для пользовательских наборов. Кроме того, у нас есть множество фич для оценки и повышения эффективности работы конвейеров, для планирования расписания дежурных инженеров, а также улучшения в области безопасности. Вас ждёт более 50 крутых улучшений и новых фич в этом релизе!
Средства управления для безопасного и эффективного роста
Подходящие средства управления позволяют поддерживать автоматизацию по мере роста и масштабирования вашей системы, упрощая при этом работу по соблюдению требований. GitLab Kubernetes Agent является основой интеграции GitLab с Kubernetes, и теперь он доступен на GitLab.com. Интеграция на основе агента поддерживает развёртывания на основе затягивания изменений из GitLab, что предпочтительнее с точки зрения безопасности. Благодаря этому, такая интеграция стремительно становится популярным методом в развёртываниях с Kubernetes. Наш агент также поддерживает интеграцию правил сетевой безопасности и оповещения, что позволяет осуществлять тонкую настройку RBAC в ваших кластерах.
Настройка специальных конвейеров для проверки требований позволит вам обеспечить более высокую степень разделения обязанностей и снизить бизнес-риски благодаря созданию конвейеров, обязательных к выполнению для любого проекта, которому назначен соответствующий набор правил. В то же время создание пользовательских наборов правил по соответствию требованиям предоставит вам возможность задавать свои собственные требования, помимо обычных, таких как PCI, HIPPA и другие. Режим администрирования повышает безопасность и уровень контроля в вашем инстансе GitLab, требуя от администраторов подтверждения учётных данных перед выполнением команд администрирования. Отчёты для аудита тоже стали удобнее благодаря появлению в самостоятельных инстансах GitLab экспорта данных по доступу пользователей. Эта фича позволяет собрать в одном месте информацию о том, к каким группам, подгруппам и проектам имеют доступ ваши пользователи.
Более быстрые конвейеры
Быстрые, надёжные конвейеры — одно из основных наших направлений, и в этом месяце мы поддерживаем его, внеся целый ряд усовершенствований для конвейеров.
Редактор конвейеров поможет вам ещё быстрее приступить к работе и поддерживать её продуктивность. Создание пустого файла конфигурации в редакторе конвейеров позволит новым пользователям быстрее начать работу с редактором без необходимости отдельно создавать файл конвейера. Возможность настройки нескольких ключей кэша в одном задании поможет увеличить производительность ваших конвейеров. Оценить эти улучшения вы сможете на панели CI/CD, где вас ждёт новый график метрики из DORA 4, время внесения изменений; на нём вы сможете отследить время, которое уходит на коммит кода и его развёртывание в продакшен. Кроме того, метрики внедрения DevOps стали доступны для групп, что позволит вам проанализировать, как в вашей группе внедряются возможности DevOps от GitLab.
Обеспечение безопасности цепочки поставок ПО
Специалисты по безопасности будут рады появлению гибкого синтаксиса правил Semgrep для расширения и изменения правил выявления уязвимостей, что было частым запросом от пользователей GitLab SAST. Мы также добавили поддержку пользовательских сертификатов и уведомления по электронной почте об истечении срока действия ключей. Кроме того, вы можете повысить уровень безопасности с помощью обязательного использования SAML для Git-активности. Благодаря новой фиче, планированию расписания дежурных сотрудников, оповещения из GitLab перенаправляются дежурному инженеру, указанному в расписании данного проекта. Это будет особенно удобно по мере дальнейшего развития нашего направления оповещений безопасности, поскольку предоставляет возможность управления инцидентами с полной видимостью всего процесса DevOps.
Далее вы узнаете всё о новых фичах, улучшениях производительности и других изменениях этого релиза! Чтобы узнать, что будет в следующем месяце, зайдите на страницу предстоящих релизов и посмотрите видео по релизу 13.12.
MVP этого месяца — Yogi
За последний месяц Yogi внёс в страницу статуса GitLab многочисленные улучшения, которые повысили производительность, отшлифовали пользовательский интерфейс и приблизили нас к нашему конечному видению этой страницы. Yogi добавил системное уведомление в виде баннера, которое помогает пользователям с первого взгляда понять, произошёл ли инцидент, или все системы работают исправно. Он адаптировал эту страницу для мобильных устройств, чтобы у дежурных сотрудников был более удобный интерфейс на их устройствах. Он также перевёл инциденты и комментарии к инцидентам на компоненты vue.js, что поможет нам создавать более консистентный и приятый интерфейс по всему GitLab.
Yogi не в первый раз становится MVP — он также был отмечен в релизе 13.8 за более чем 30 мерж-реквестов, в которых он починил давние баги, улучшил UX и помог обеспечить согласованность нашей платформы. Спасибо, Yogi!
Основные фичи релиза GitLab 13.11
GitLab Kubernetes Agent на GitLab.com
(SaaS: PREMIUM, ULTIMATE; self-managed: PREMIUM, ULTIMATE) Стадия цикла DevOps: Configure
GitLab Kubernetes Agent наконец-то стал доступен на GitLab.com! Используя этот агент, вы по достоинству оцените преимущества быстрых развёртываний на вашем кластере на основе затягивания изменений из GitLab, в то время как GitLab.com будет управлять необходимыми серверными компонентами агента. GitLab Kubernetes Agent — основной строительный блок для интеграции GitLab с Kubernetes. На сегодняшний день интеграция на основе агента поддерживает pull-развёртывания, правила сетевой безопасности и оповещения, а в скором времени получит поддержку и для push-развёртываний.
В отличие от устаревшей интеграции с Kubernetes на основе сертификатов, этот агент не требует от пользователя открывать свой кластер для GitLab и позволяет осуществлять тонкую RBAC-настройку доступа GitLab к вашим кластерам.
→ Документация по GitLab Kubernetes Agent и оригинальный тикет.
Настройка конвейера для проверки требований
(SaaS: ULTIMATE; self-managed: ULTIMATE) Стадия цикла DevOps: Manage
Мы рады сообщить, что теперь стало возможным создавать конвейеры, которые будут в обязательном порядке выполняться для проектов с назначенным набором правил по соответствию требованиям.
Команды, желающие внедрить проверку выполнения требований в рабочий процесс конвейера, теперь могут обеспечить ещё большее разделение обязанностей, настроив единый конвейер для конкретного набора правил по соответствию требованиям. Все проекты, использующие этот набор правил, будут автоматически включать выполнение этого предопределённого конвейера. Пользователи наследуют, но не могут изменять конфигурацию конвейера в нижестоящих проектах, что гарантирует, что заданные шаги по обеспечению соответствия требованиям будут выполняться каждый раз одинаково.
Это будет экономить время командам, отвечающим за безопасность и соответствие нормативным требованиям, поскольку избавит их от необходимости вручную копировать конфигурацию конвейера в каждый проект, которому она необходима, а затем отслеживать её состояние, чтобы не допустить её редактирования или удаления. Это также поможет командам разработчиков следовать необходимым правилам, при этом не требуя от них быть экспертами в области соответствия требованиям.
Настройка конфигурации конвейера для набора правил по соответствию требованиям — это отличный способ обеспечить последовательное выполнение нормативных требований в организации, позволяя при этом сэкономить время и способствуя сотрудничеству между разработчиками и специалистами по безопасности и соответствию требованиям.
Посмотрите нашу пошаговую видеоинструкцию, чтобы узнать больше о настройке и реализации такого конвейера!
→ Документация по настройке конвейеров для проверки требований и оригинальный эпик.
Создавайте собственные метки наборов правил по соответствию требованиям
(SaaS: PREMIUM, ULTIMATE; self-managed: PREMIUM, ULTIMATE) Стадия цикла DevOps: Manage
В настоящее время GitLab предоставляет несколько предопределённых наборов правил соответствия, таких как GDPR, HIPAA, PCI-DSS, SOC 2 и SOX, с соответствующими метками. С этим релизом вы можете добавлять свои собственные наборы правил и настраивать метки для ваших механизмов и процессов. В будущем вы также сможете создавать правила, которые можно будет применять к проектам на основе этих меток.
→ Документация по пользовательским меткам наборов правил и оригинальный тикет.
Управление расписанием дежурных инженеров
(SaaS: PREMIUM, ULTIMATE; self-managed: PREMIUM, ULTIMATE) Стадия цикла DevOps: Monitor
Службы поддержки программного обеспечения не уходят на отдых в конце рабочего дня. Ваши клиенты ожидают круглосуточной поддержки. Когда что-то идёт не так, вам нужна команда (или несколько команд), способная быстро и эффективно реагировать на перебои в работе сервиса.
Быть в роли дежурного может быть весьма напряжённой работой. Чтобы лучше справляться со стрессом и выгоранием, в большинстве команд обязанности дежурных сотрудников чередуются. Новая фича расписание дежурств в GitLab позволяет вам и вашей команде создавать и управлять расписанием дежурных инженеров. Оповещения, полученные в GitLab через конечную точку HTTP, перенаправляются дежурному инженеру в соответствии с расписанием этого конкретного проекта.
→ Документация по расписанию дежурств и оригинальный эпик.
Режим администрирования требует повторной аутентификации для выполнения задач с правами администратора
(self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Manage
В GitLab появился режим администрирования, который поможет администраторам работать безопасно со своего аккаунта. Когда этот режим не активен, у администраторов права такие же, как у обычных пользователей; чтобы запускать команды с правами администратора, потребуется войти в режим администрирования, повторно введя пароль. Режим администрирования повышает безопасность инстанса, защищая конфиденциальные операции и данные.
За эту фичу мы благодарим Diego Louzán из Siemens. Режим администрирования не появился бы без неустанных усилий Diego. Эта фича была в разработке целый год!
→ Документация по режиму администрирования и оригинальный эпик.
Экспорт отчёта по доступу пользователей
(self-managed: PREMIUM, ULTIMATE) Стадия цикла DevOps: Manage
Организации, следящие за соблюдением требований, постоянно нуждаются в аудите доступа своих пользователей к системам и ресурсам компании. Ранее для выполнения этой задачи в GitLab требовалось создавать собственные инструменты для ручного сбора необходимых данных с помощью наших API, связанных с аудитом.
Теперь же вы можете просто нажать кнопку export в разделе администрирования вашего инстанса GitLab, и получить CSV-файл, содержащий список всех пользователей, а также групп, подгрупп и проектов, к которым они имеют доступ. Теперь проводить аудит доступа пользователей стало намного проще и гораздо быстрее.
→ Документация по экспорту отчёта по доступу пользователей и оригинальный тикет.
Используйте несколько кэшей в одном задании
(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Verify
GitLab CI/CD предоставляет механизм кэширования, который экономит ваше время разработки во время выполнения заданий. Однако, ранее было невозможно настроить несколько ключей кэширования в одном задании. Это ограничение могло вынудить вас использовать артефакты для кэширования или же использовать дублирующиеся задания с разными путями для кэша. В этом релизе мы предоставляем возможность настраивать несколько ключей кэширования в одном задании, что поможет вам повысить производительность конвейера.
→ Документация по настройке нескольких ключей кэширования для задания и оригинальный тикет.
Отслеживайте метрику DORA 4: время внесения изменений
(SaaS: ULTIMATE; self-managed: ULTIMATE) Стадия цикла DevOps: Release
Измерение эффективности цикла разработки программного обеспечения — важный шаг для повышения степени внедрения DevOps в любой организации. В прошлом релизе мы добавили в API поддержку учёта времени, необходимого для внесения изменений в проектах. Эти метрики дают вам представление о пропускной способности в вашем проекте — о том, сколько времени требуется для коммита и развёртывания кода в ваше продакшен-окружение.
→ Документация по графикам времени внесения изменений и оригинальный тикет.
GitLab + Semgrep: обновляем SAST и закладываем основу на будущее
(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Secure
Исторически в основе SAST (Static application security testing, Статическое тестирование безопасности приложений) в GitLab лежали более десятка различных статических анализаторов безопасности с открытым исходным кодом. Эти анализаторы каждый месяц выявляли миллионы уязвимостей. Каждый из этих анализаторов специфичен для конкретного языка и имеет собственные подходы к сканированию. Такие различия приводят к излишним затратам на обновление, управление и поддержку дополнительных фич, которые мы разрабатываем поверх этих инструментов, и могут сбить с толку любого, кто попытается заняться отладкой.
Команда статического анализа GitLab постоянно оценивает новые анализаторы безопасности. Нас впечатлил Semgrep, относительно новый инструмент с открытым исходным кодом от команды разработчиков из r2c. Это быстрый инструмент статического анализа для поиска ошибок и обеспечения стандартов разработки кода. Правила Semgrep выглядят как код, который вы хотели бы видеть: вы можете писать свои собственные правила без необходимости понимать абстрактные синтаксические деревья или разбираться с регулярными выражениями.
Гибкий синтаксис правил Semgrep идеально подходит для оптимизации нашей фичи Пользовательские наборы правил для расширения и изменения правил выявления уязвимостей, что было частым запросом от пользователей GitLab SAST. Semgrep также располагает растущим открытым реестром из более чем 1000 правил, добавленных сообществом.
Сейчас мы находимся в процессе перевода многих наших lint-анализаторов SAST на Semgrep. Это поможет повысить стабильность и производительность анализаторов, увеличить их покрытие и предоставить клиентам GitLab доступ к открытым правилам в Semgrep и дополнительным возможностям пользовательских наборов правил, которые мы уже скоро добавим. Мы получили огромное удовольствие от работы с командой r2c и с нетерпением ждём перехода других наших анализаторов на Semgrep. Вы можете узнать все подробности в нашем эпике по переходу на Semgrep или самостоятельно попробовать первые экспериментальные анализаторы Semgrep для JavaScript, TypeScript и Python.
Мы уверены в том, что этот переход много значит для будущего SAST в GitLab и сообщества Semgrep. GitLab будет вносить свой вклад в открытый код проекта Semgrep, в том числе дополнительные правила для обеспечения такого же или даже большего покрытия, чем у наших текущих анализаторов.
→ Документация по поддерживаемым языкам и фреймворкам в GitLab SAST и оригинальный эпик.
Поддержка сертификатов пользовательских CA при использовании release CLI
(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Release
До этого момента, если вы работали с GitLab в собственном инстансе, вы могли использовать release CLI с публичным сертификатом, но не с собственным пользовательским сертификатом. В GitLab 13.11 мы добавили поддержку сертификатов пользовательских центров сертификации (Certificate authority, CA) с помощью переменной окружения ADDITIONAL_CA_CERT_BUNDLE или флага --additional-ca-cert-bundle. Кроме того, были добавлены переменная окружения INSECURE_HTTPS и флаг --insecure-https, чтобы вы могли пропустить проверку сертификатов сервера, которая обычно не проходит с пользовательским SSL-сертификатом, поскольку он не подписан публичным центром сертификации.
→ Документация по использованию сертификатов пользовательских CA и оригинальный тикет.
Шаблоны описания тикетов и мерж-реквестов на уровне инстанса и группы
(SaaS: PREMIUM, ULTIMATE; self-managed: PREMIUM, ULTIMATE) Стадия цикла DevOps: Plan
Вместо того, чтобы вручную обновлять один и тот же шаблон описания в десятках проектов, теперь вы можете централизованно управлять шаблонами из единого репозитория. Мы дополнили шаблоны файлов инстанса и групп, добавив шаблоны описания тикетов и мерж-реквестов (в русской локализации GitLab «запросы на слияние»). После создания каталога .gitlab в репозитории файлов с шаблонами, шаблоны описания будут доступны всем проектам, принадлежащим данному инстансу или группе. Каждая группа или подгруппа также может задать дополнительный репозиторий для шаблонов, что позволит вашим подгруппам и проектам иметь доступ к шаблонам из нескольких репозиториев.
→ Документация по настройке шаблонов описания и оригинальный тикет.
Совместное использование ключевых слов needs и optional для DAG-заданий
(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Verify
Направленные ациклические графы (Directed acyclic graph, DAG) в GitLab CI/CD позволяют вам использовать синтаксис needs для настройки запуска задания раньше его стадии, как только завершатся необходимые задания. Также есть ключевые слова rules, only и except, которые определяют, будет ли вообще задание добавлено на конвейер. К сожалению, если вы используете needs вместе с другими ключевыми словами, ваш конвейер может завершиться с ошибкой, если необходимое задание не было добавлено на конвейер.
В этом релизе мы добавляем ключевое слово optional в синтаксис needs для DAG-заданий. Если необходимое задание отмечено как опциональное, но не присутствует на конвейере, задание с needs проигнорирует его. Если же опциональное задание присутствует на конвейере, задание с needs будет ждать, пока оно завершится. Популярность направленных ациклических графов растёт, и эта фича упрощает безопасное комбинирование ключевых слов rules, only и except.
→ Документация по совместному использованию optional и needs и оригинальный тикет.
Переменные для разных окружений в группе
(SaaS: PREMIUM, ULTIMATE; self-managed: PREMIUM, ULTIMATE) Стадия цикла DevOps: Configure
Многие организации предпочитают задавать секретные ключи и другие переменные окружения на уровне группы, так как это хорошо согласуется с границами и уровнями доверия команд. До сих пор групповые переменные окружения применялись ко всем окружениям, что ограничивало возможности их использования во многих сценариях. В этом релизе мы добавляем возможность создавать специфичные для окружений переменные на уровне группы.
Это изменение дополняет похожую фичу на уровне проекта. С этого момента мейнтейнеры группы (в русской локализации GitLab «сопровождающие») смогут выбирать окружения, в которых будет использоваться определённая переменная.
→ Документация по переменным CI/CD на уровне группы и оригинальный тикет.
Запрос CVE ID уязвимости через интерфейс GitLab
(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Secure
GitLab верит, что команды ответственно подходят к раскрытию уязвимостей программного обеспечения. С начала 2020 года GitLab выполняет функции CVE Numbering Authority (CNA) и может предоставлять специалистам по безопасности и поставщикам IT-продуктов идентификаторы CVE либо из самого GitLab, либо из любого проекта, размещённого на GitLab.com.
В GitLab 13.11 мы упрощаем запрос идентификаторов CVE у GitLab через наш пользовательский интерфейс. В конфиденциальных тикетах в публичных проектах, размещённых на GitLab.com, у мейнтейнеров будет возможность запрашивать идентификатор CVE нажатием кнопки «Запросить идентификатор CVE» на боковой панели справа. После нажатия кнопки вы попадёте на страницу нового тикета для проекта GitLab CVE, где вы сможете заполнить шаблон запроса и запустить его выполнение.
Эту фичу также можно отключить на странице настроек проекта, если владелец проекта не хочет, чтобы его репозитории предлагали эту возможность мейнтейнерам. В настоящее время мы постепенно внедряем эту функцию в проекты, размещённые на GitLab.com. Загляните в специальный тикет по прогрессу развёртывания, чтобы узнать информацию об обновлениях или оставить обратную связь.
→ Документация по запросам ID из CVE и оригинальный тикет.
Развёртывание GitLab в OpenShift и Kubernetes с помощью оператора GitLab (бета-версия)
(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Доступность
GitLab работает над тем, чтобы предоставлять полную поддержку платформы OpenShift. Мы выпускаем MVP GitLab Operator, предназначенного для управления полным жизненным циклом инстансов GitLab на контейнерных платформах Kubernetes и OpenShift. В настоящее время оператор работает как бета-версия и не рекомендуется для использования в продакшене. Следующим шагом мы планируем вывести этот оператор в общий доступ; в будущем он станет рекомендуемым способом установки GitLab для Kubernetes и OpenShift, хотя GitLab Helm chart по-прежнему будет поддерживаться. Мы приглашаем вас попробовать GitLab Operator и оставить отзыв о нём в специальном тикете.
→ Документация по оператору GitLab и оригинальный эпик.
Другие улучшения в GitLab 13.11
События аудита теперь доступны для Developer+
(SaaS: PREMIUM, ULTIMATE; self-managed: PREMIUM, ULTIMATE) Стадия цикла DevOps: Manage
Логи аудита — это один из важнейших элементов системы для организаций, следящих за соблюдением требований, и для их программ по соответствию требованиям. Они позволяют отслеживать активность пользователей и системную активность, что помогает устранять инциденты, находить ответственных за конкретное действие, а также позволяет организациям собирать артефакты со сведениями для аудиторов конкретных процессов. Ранее только мейнтейнеры, владельцы кода и администраторы имели доступ к разделу Аудит событий. Остальные пользователи даже не знали о существовании этих логов и не имели доступа к просмотру своей собственной активности, не говоря уже о том, чтобы поддерживать соблюдение требований в своей организации.
Раздел Безопасность и комплаенс > Аудит событий (Security & Compliance > Audit Events) теперь доступен пользователям с уровнем доступа разработчика и выше. Пользователи с уровнем доступа разработчика смогут видеть только свои собственные действия, но не действия других пользователей. Пользователи с уровнем доступа мейнтейнера и выше, как и раньше, будут видеть и свои собственные действия, и действия других пользователей. Это изменение делает данные аудита доступными для большего числа пользователей и помогает им в соответствии требованиям.
→ Документация по событиям аудита и оригинальный тикет.
Ключи GPG доступны в реестре учётных данных администратора
(SaaS: ULTIMATE; self-managed: ULTIMATE) Стадия цикла DevOps: Manage
В панели администратора стало возможным просматривать информацию по ключам GPG ваших пользователей. Это позволит вам быстро увидеть, какие ключи хранятся в GitLab, а также их идентификаторы и статус верификации, что поможет лучше разобраться в том, как пользователи взаимодействуют с вашим инстансом GitLab.
Это часть наших усилий по созданию реестра учётных данных. Мы запланировали много итераций, чтобы повысить прозрачность, уровень контроля и ценность для вас и ваших организаций. Мы будем рады вашему фидбэку в соответствующих эпиках и тикетах.
→ Документация по просмотру существующих ключей GPG и оригинальный тикет.
Регистрация приложений OAuth на уровне группы
(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Manage
Владельцы групп теперь могут регистрировать приложения OAuth для группы. Ранее приложения OAuth можно было регистрировать только для отдельных пользователей или на уровне всего инстанса. Доступность этой функции на уровне группы снижает нагрузку на администраторов инстанса и устраняет зависимость от отдельных пользователей при настройке приложений OAuth.
Эта фича стала доступна в релизе 13.11 благодаря невероятному вкладу Jonas Wälter из Siemens!
→ Документация по приложениям на уровне группы и оригинальный тикет.
Добавление списков итераций на доски задач
(SaaS: PREMIUM, ULTIMATE; self-managed: PREMIUM, ULTIMATE) Стадия цикла DevOps: Plan
Доски задач (в русской локализации GitLab «доски обсуждений») теперь поддерживают создание списков итераций. Чтобы эффективно упорядочить тикеты эпика (в русской локализации GitLab «цель») на предстоящих итерациях, теперь вы можете просто переместить тикеты из одной итерации в другую на доске или включить группировку эпиков по «плавательным дорожкам».
→ Документация по спискам итераций и оригинальный тикет.
Активные интеграции теперь отображаются отдельно
(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Create
Сегодня в GitLab доступно более 30 интеграций, и на странице настроек становится непросто сразу понять, какие интеграции активны в данный момент.
Теперь активные интеграции отображаются в отдельной таблице вверху страницы, что позволяет увидеть, какие из них вы используете, и упростить поиск наиболее важных для вас интеграций.
→ Документация по интеграциям GitLab и оригинальный тикет.
Выборочное добавление коммитов из форков в родительскую ветку
(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Create
В GitLab 13.11, если вы являетесь участником исходного проекта, вы сможете выборочно добавлять (cherry-pick) коммиты из проектов-форков в свой проект. Мы добавили новый раздел Добавить в проект (Pick into project) в диалоговое окно, которое отображается, когда вы выбираете Настройки > Подобрать (Options > Cherry-pick) на странице коммита.
Сообщество разработчиков сможет вносить свой вклад в ваш проект, и вашей команде больше не нужно будет вручную загружать файл .patch форка, чтобы получить нужные коммиты из устаревших или неподдерживаемых форков.
В будущем можно будет добавлять коммиты из одного форка в другой.
→ Документация по выборочному добавлению коммитов в проекты и оригинальный тикет.
Опция force push для защищённых веток
(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Create
Рекомендуется избегать force push для репозиториев Git, но в исключительных случаях без него не обойтись. Временное снятие защиты ветки для проведения force push может быть не идеальным решением, поскольку для этого требуются права доступа уровня мейнтейнера, и это приводит к сбросу настроек защиты ветки.
GitLab 13.11 представляет новую настройку Разрешить force push для защищённых веток, которая позволяет пользователям из списка «допущенные пушить» (Allowed to push) использовать force push.
→ Документация по разрешению force push для защищённых веток и оригинальный тикет.
Поиск на странице настроек
(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Create
Найти точное местоположение настройки GitLab может быть непросто. Даже если вы в целом знаете, где искать, многие интерфейсы настроек состоят из нескольких разделов и десятков индивидуальных параметров конфигурации.
С этого релиза вы сможете использовать поле поиска в настройках группы, проекта, администратора и пользователя, чтобы быстро найти желаемые настройки. Ваши критерии поиска будут фильтровать текущую страницу, чтобы отображать только релевантные настройки и даже выделять вхождения вашего поискового запроса на странице.
В будущих итерациях мы планируем расширить эту возможность до поиска по всем разделам настроек.
→ Документация по настройкам поиска и оригинальный эпик.
Вид приветствия для GitLab Workflow в VS Code
(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Create
Чтобы начать работу с расширением GitLab Workflow для Visual Studio Code (VS Code), необходимо выполнить несколько ручных шагов для подключения его к GitLab. Если расширение настроено неправильно, или вы настраиваете его впервые, может быть непросто убедиться, что вы настроили его правильно.
На панели GitLab Workflow внутри VS Code теперь отображаются конкретные шаги, которые помогут вам начать работу. Эта панель также сообщит вам, если ваше текущее рабочее пространство не содержит проекта GitLab.
→ Документация по расширению для VS Code и оригинальный тикет.
Создание файла начальной конфигурации из редактора конвейеров
(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Verify
Редактор конвейеров — это универсальный инструмент для создания и тестирования конвейера CI/CD. Раньше редактор работал только в том случае, если файл конфигурации .gitlab-ci.yml уже существовал в корне вашего репозитория. В этом релизе мы добавили возможность создавать начальный пустой файл конвейера на самой странице редактора конвейеров, чтобы вы могли сразу приступить к созданию своего конвейера.
→ Документация по редактору конвейеров и оригинальный тикет.
Предопределённая переменная CI/CD для автора коммита
(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Verify
Раньше, если вам нужно было идентифицировать автора коммита в запущенном задании CI/CD, вам приходилось добавлять к заданию дополнительный вызов API для его получения. Теперь эта информация легко доступна как предопределённая переменная CI/CD CI_COMMIT_AUTHOR.
Спасибо Craig Andrews за эту фичу!
→ Документация по предопределённым переменным CI/CD и оригинальный тикет.
Публикация и установка общих пакетов с SemVer
(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Package
Реестр пакетов GitLab используется для публикации и совместного использования общих файлов пакетов. Вы можете делать это с помощью командной строки, но вполне вероятно, что вы используете GitLab CI/CD для публикации большинства своих файлов.
До GitLab 13.11 проверка имени файла GitLab не позволяла вам загрузить пакет с семантической версией (SemVer). Это не позволяло многим из вас использовать реестр пакетов в своих конвейерах, поскольку SemVer довольно часто используется для маркировки файлов как относящихся к данному релизу или ветке.
В релизе GitLab 13.11 мы ослабляем проверку имён файлов, поэтому теперь вы можете использовать SemVer для именования файлов. Мы надеемся, что это поможет вам внедрить реестр пакетов и упростит именование и проверку ваших общих пакетов.
→ Документация по публикации файла пакетов и оригинальный тикет.
Используйте Composer v2 с реестром пакетов GitLab
(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Package
Composer используется для публикации, совместного использования и загрузки ваших PHP-зависимостей в проект GitLab. Шесть месяцев назад была выпущена новая мажорная версия Composer (v2) с множеством изменений, включая значительные улучшения производительности, обновления архитектуры и runtime-фичи. Подробнее об изменениях вы можете прочесть здесь.
До недавнего времени вы не могли воспользоваться этими улучшениями, потому что реестр GitLab не поддерживал Composer v2. Возможно, из-за этого некоторые из вас могли вовсе не использовать реестр GitLab. В качестве MVC мы сосредоточились на добавлении поддержки обязательного параметра metadata-URL. Мы добавили новую конечную точку GET group/:id/-/packages/composer/p2/:package_name, которая возвращает метаданные для всех пакетов в вашем репозитории. Когда Composer ищет пакет, он заменяет %package_name% на имя этого пакета и загружает данные, используя полученный URL.
У нас есть тикеты, открытые для добавления поддержки необязательных параметров providers-api и list-api. Мы надеемся уделить этому внимание в ближайших релизах.
→ Документация по метаданным пакетов в Composer v2 и оригинальный тикет.
Загрузка зависимостей Composer из системы контроля версий
(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Package
У вас есть два варианта загрузки зависимостей с Composer: source и dist. Для стабильных версий Composer по умолчанию использует dist и загружает зависимость в виде zip-файла. Однако вы также можете загрузить его напрямую из системы контроля версий. Если включён параметр --prefer-source, Composer загружает вашу зависимость клонированием из Git, а не как упакованный файл zip. Это удобно, если вы хотите исправить ошибку в проекте и напрямую получить локальную Git-копию для этой зависимости.
До сих пор при загрузке зависимостей Composer вы не могли использовать команды и конфигурации prefer-source и preferred-install. Из-за этого многие из вас не использовали реестр пакетов GitLab для своих зависимостей Composer.
Мы рады сообщить, что теперь вы сможете загружать свои зависимости Composer в виде исходного кода. Чтобы сделать это, просто добавьте опцию prefer-source к вашей команде установки, например: composer update --prefer-source.
→ Документация по установке пакетов с Composer и оригинальный тикет.
Поддержка OpenShift для SAST и обнаружения секретных ключей
(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Secure
Начиная с 13.3 в GitLab есть поддерживаемые обработчики заданий для Red Hat OpenShift. До сих пор сканирование безопасности GitLab не поддерживало этот вариант развёртывания. Начиная с 13.11 анализатор безопасности GitLab SAST и обнаружение секретных ключей могут работать и в рамках развёртывания OpenShift. Если вы переопределили или предоставили собственный файл .gitlab-ci.yml с фиксированными версиями анализаторов SAST или обнаружения секретов, обновите его до последних доступных версий. Обратите внимание, что экспериментальные анализаторы в настоящее время не поддерживают окружения OpenShift. По мере того, как эти анализаторы будут выводиться из экспериментального статуса, эта поддержка будет добавляться.
→ Документация по фичам анализаторов SAST и оригинальный эпик.
Поддержка общего сканирования Kotlin в SAST
(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Secure
Начиная с 13.5 SAST в GitLab поддерживает сканирование мобильных проектов, включая приложения для Android, написанные на Kotlin. Однако сканирование Kotlin было сосредоточено только на угрозах безопасности мобильных приложений. В GitLab 13.11 благодаря вкладу участника команды GitLab Core Hannes Rosenögger (@haynes), наш существующий Java-анализатор Spotbugs теперь поддерживает сканирование общих проектов и файлов Kotlin. Поскольку Kotlin набирает популярность и постепенно заменяет Java в более современных проектах, GitLab SAST продолжает помогать разработчикам в написании безопасного кода.
→ Документация по поддерживаемым языкам и фреймворкам в GitLab SAST и оригинальный эпик.
Экспериментальные анализаторы Semgrep для Python, JavaScript и TypeScript
(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Secure
В рамках нашего партнёрства с Semgrep в обновлении GitLab SAST мы ищем бета-тестеров, чтобы попробовать наши новые анализаторы Semgrep для Python, JavaScript и TypeScript. Эти экспериментальные анализаторы работают вместе с нашими существующими анализаторами Python, JavaScript и TypeScript, так что вы можете сравнивать уязвимости, обнаруженные разными анализаторами.
- Наш новый анализатор Semgrep для Python в конечном итоге заменит Bandit, наш текущий анализатор для Python. В рамках этого перехода наша команда провела оценку покрытия правилами для обоих инструментов, чтобы гарантировать, что мы сохраним нужный уровень покрытия.
- Наш новый анализатор Semgrep для JavaScript и TypeScript в конечном итоге заменит наш текущий анализатор ESLint. В настоящее время нам известно о пробеле в покрытии ESLint, над исправлением которого мы работаем вместе с командой Semgrep.
Чтобы запустить любой из этих анализаторов, вам необходимо включить переключаемую фичу, использование экспериментальных анализаторов SAST в файле 'gitlab-ci.yml ', что позволит новым анализаторам Semgrep работать вместе с уже существующими анализаторами SAST. Обратите внимание, что мы ещё не завершили работу над повторным сопоставлением результатов обнаружения уязвимостей между анализаторами, поэтому вы можете увидеть дублирующиеся результаты в своём отчёте о безопасности. До перехода к новым анализаторам мы решим эту проблему. Мы будем рады любому фидбэку и предложениям по этим анализаторам в соответствующих тикетах по ссылкам выше.
→ Документация по поддерживаемым языкам и фреймворкам в GitLab SAST и оригинальный эпик.
Обновления анализаторов SAST
(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Secure
SAST (Статическое тестирование безопасности приложений) в GitLab включает в себя множество анализаторов безопасности, которые команда статического анализа GitLab активно поддерживает и обновляет. Ниже представлены обновления анализаторов, выпущенные в релизе 13.11. Эти обновления включают расширенное покрытие, исправления ошибок и другие улучшения.
- ESLint обновлён до версии 7.23.0: мерж-реквест, список изменений.
- MobSF обновлён до версии 3.4.0: мерж-реквест, список изменений.
- njsscan обновлён до версии 0.2.3: мерж-реквест, список изменений. Обратите внимание на эти изменения: максимальный размер файла njsscan уменьшен с 25 МБ до 5 МБ; появились новые правила Sequelize.
- gitleaks обновлён до версии 0.2.3: мерж-реквест, список изменений. Обратите внимание на эти изменения: новые правила поиска секретных ключей PyPI и GitHub.
Если вы используете поставляемый GitLab шаблон SAST (SAST.gitlab-ci.yml), вам не нужно ничего делать, чтобы получить эти обновления. Однако, если вы переопределяете его или используете свой собственный шаблон CI, вам потребуется обновить конфигурации CI.
→ Документация по анализаторам SAST и оригинальный тикет.
Приносите свой собственный Prometheus, чтобы интеграция GitLab — Kubernetes стала лучше
(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Configure
Интегрируя свои кластерные сервисы с GitLab, вы можете воспользоваться различными фичами GitLab, такими как доски окружений, метрики Prometheus и логи приложений. Раньше эти функции требовали от вас использования приложений, управляемых GitLab, что не соответствовало рабочему процессу и требованиям многих наших пользователей.
С этом релизом вы можете интегрироваться с Prometheus и Kubernetes через сервисы GitLab и поддерживать их обслуживание на своей стороне, следуя процессам и правилам вашей компании. Для новичков мы предоставляем обширную документацию и рекомендации по установке этих приложений. Вы по-прежнему можете поддерживать глубокую интеграцию метрик, доступную в GitLab, как это работало с Prometheus, управляемым GitLab.
→ Документация по интеграции с Prometheus и оригинальный тикет.
Geo проверяет реплицированные версионированные сниппеты
(self-managed: PREMIUM, ULTIMATE) Доступность
Geo теперь автоматически проверяет целостность данных реплицированных версионированных сниппетов. Это гарантирует, что сниппеты не будут повреждены при передаче или хранении. Если Geo используется как часть стратегии аварийного восстановления, это защитит клиентов от потери данных.
В следующей итерации мы добавим автоматическое исправление для тех случаев, когда проверка обнаруживает несоответствие.
Возможности верификации Geo реализуются в целом во фреймворке репликации Geo, и мы планируем добавить верификацию файлов для всех остальных типов реплицированных данных.
→ Документация по репликации Geo и оригинальный эпик.
Метрики внедрения DevOps теперь доступны и для групп
(SaaS: ULTIMATE; self-managed: ULTIMATE) Стадия цикла DevOps: Manage
Таблица внедрения DevOps позволяют руководству увидеть, какие этапы и фичи GitLab DevOps были внедрены их командами. До сих пор доступ к ней можно было получить только через панель администратора, что ограничивало доступ к этой информации только администраторами инстанса. Это обновление выводит показатели внедрения DevOps на групповой уровень, позволяя большему количеству пользователей понять, как и где они внедряют фичи DevOps в GitLab.
→ Документация по внедрению DevOps и оригинальный эпик.
Обязательное использование SAML для действий Git в группе
(SaaS: PREMIUM, ULTIMATE) Стадия цикла DevOps: Manage
Мейнтейнеры группы GitLab теперь могут повысить безопасность своей группы, включив принудительное использование SAML для действий Git. Организации, уделяющие много внимания безопасности, хотят, чтобы все действия в GitLab были защищены и управлялись их поставщиком удостоверений SAML. Ранее обязательное использование системы единого входа SAML применялось только к действиям в пользовательском интерфейсе GitLab. Операции Git CLI не требовали активной сессии SSO SAML. Теперь же, когда обязательное использование Git Group SAML SSO включено, пользователи должны будут иметь активную веб-сессию SAML для выполнения операций Git в интерфейсе командной строки.
→ Документация по групповому принудительному применению SAML и оригинальный тикет.
Уведомление по электронной почте об истечении срока действия ключа SSH
(self-managed: ULTIMATE) Стадия цикла DevOps: Manage
Для ключей SSH, которые вы добавляете в Реестр учётных данных, можно указать дату истечения срока действия, чтобы обеспечить правильную ротацию ключей и ограничить текущий доступ к вашему инстансу.
По умолчанию GitLab теперь будет ежедневно проверять, приближаются ли какие-либо даты истечения срока действия. Уведомление по электронной почте будет отправлено за неделю до и за день до истечения срока действия ключа, чтобы вы могли предпринять любые необходимые действия для обновления ключа или любых систем, которые на него полагаются.
→ Документация по добавлению ключей SSH в аккаунт GitLab и оригинальный тикет.
Фильтрация требований по статусу
(SaaS: ULTIMATE; self-managed: ULTIMATE) Стадия цикла DevOps: Plan
Теперь вы можете отфильтровать свой список требований по статусу, чтобы узнать, какие области продукта нуждаются в дополнительном тестировании или являются неполными. Вы и ваша команда легко сможете увидеть, сколько и какой работы осталось!
Поскольку требования могут быть удовлетворены с помощью заданий конвейера CI/CD, статус требования всегда актуален.
→ Документация по фильтрации требований и оригинальный тикет.
Добавление отдельных комментариев при ревью мерж-реквестов
(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Create
Когда вы ревьюите изменения, вы можете захотеть обобщить свой отзыв или прокомментировать что-то, не связанное с конкретными изменениями. Ревью в GitLab ранее разрешали только комментировать изменения или отвечать на существующие комментарии, что означало, что другие виды комментариев можно было добавить только после отправки ревью.
В рамках процесса ревью теперь вы можете отправить общий комментарий вместе с вашими ответами или комментариями по конкретным изменениям. Общие комментарии упрощают предоставление обратной связи автору и использование быстрых действий в мерж-реквесте.
Спасибо Lee Tickett за эту фичу!
→ Документация по добавлению комментариев и оригинальный тикет.
Прямая ссылка на строки кода
(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Create
Совместная работа над длинными файлами упрощается, если вы можете поделиться ссылкой на определённую строку кода. Раньше вы могли ссылаться только на номер строки при просмотре файла в репозитории, но теперь вы также можете ссылаться на определённые строки кода в контексте редактирования файла.
Чтобы получить ссылку на конкретную строку, нажмите на иконку рядом с номером строки слева от кода или добавьте #L и номер строки к URL редактирования. Ссылка откроет редактор, прокрутит до выбранной строки и выделит её. Создание таких ссылок уже работает в редакторе файла, в Web IDE и в редакторе конвейеров!
Вы также можете создать ссылку на несколько строк, добавив к URL целый диапазон, например #L87-98, даже если пользовательский интерфейс (пока) не поддерживает создание таких ссылок.
→ Документация по созданию ссылок на конкретные строки файла и оригинальный тикет.
Улучшения в конфигурации приложения Jira Connect
(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Create
При настройке приложения GitLab.com для Jira теперь вы сможете фильтровать доступные пространства имён при привязке их к вашей учётной записи, что упростит настройку для пользователей, которые имеют доступ к большому количеству пространств имён.
→ Документация по интеграции с Jira Connect и оригинальный тикет.
Задавайте целевой проект по умолчанию для мерж-реквестов в форках
(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Create
После создания форка проекта может быть удобно использовать мерж-реквесты для внесения вклада в исходный проект. Раньше GitLab по умолчанию предполагал, что мерж-реквесты из форк-проекта всегда будут нацелены на исходный проект. Это может привести к ошибкам в случаях, когда этот код не следует добавлять в исходный проект, или когда пользователям необходимо внести изменения перед открытием мерж-реквеста.
Теперь GitLab поддерживает настройку целевого проекта по умолчанию для мерж-реквестов, которые создаются в форк-проектах. Это оптимизирует процесс внесения вклада и помогает избежать ошибок для пользователей и команд, которые чаще вносят свой вклад в форк-проекты, а не в исходный проект.
→ Документация по настройке целевой ветки мерж-реквеста по умолчанию и оригинальный тикет.
Сортировка нарушений качества кода по степени серьёзности
(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Verify
При выполнении сканирования качества кода в ваших проектах может быть обнаружено от десятков до тысяч нарушений. В небольшом виде виджета мерж-реквеста может быть сложно определить наиболее важные проблемы, которые нужно решить в первую очередь, если вам приходится разбираться с большим количеством нарушений качества кода.
И виджет качества кода мерж-реквеста, и полный отчёт о качестве кода теперь сортируют нарушения по степени серьёзности, чтобы вы могли быстро определить наиболее важные нарушения качества кода, которые необходимо устранить как можно скорее.
→ Документация по сканированию качества кода и оригинальный тикет.
Возможность делиться отфильтрованными страницами реестров пакетов и контейнеров
(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Package
Реестры пакетов и контейнеров GitLab используются для публикации и совместного использования зависимостей вашего проекта. Когда вы просматриваете свой реестр в GitLab, вы можете фильтровать и сортировать результаты, чтобы найти и проверить элемент, который вы ищете.
До GitLab 13.11 у вас не было возможности поделиться с коллегами страницей реестра, отфильтрованной по поисковому запросу. В результате каждому члену команды приходилось тратить время на фильтрацию этих страниц. Это было неэффективно и создавало риск того, что кто-нибудь установит неправильную зависимость.
С GitLab 13.11 вы сможете делиться своими отфильтрованными страницами реестров, просто скопировав URL-адрес из браузера и поделившись им со своей командой. Мы надеемся, что это изменение повысит вашу эффективность.
→ Документация по реестру пакетов и оригинальный тикет.
Меняйте период приостановки развёртывания через пользовательский интерфейс
(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Release
В GitLab 13.2 мы добавили возможность приостанавливать развёртывания через настройки CI/CD проекта. Период приостановки развёртывания помогает командам избежать непреднамеренного развёртывания, уменьшить неопределённость и снизить риски при развёртывании. Однако ранее было невозможно изменять этот период; в GitLab 13.11 мы добавляем такую возможность. Таким образом, вы можете редактировать существующий период приостановки развёртывания в соответствии с потребностями вашего бизнеса.
→ Документация по приостановке развёртывания и оригинальный тикет.
Поддержка артефактов конвейера в Geo
(self-managed: PREMIUM, ULTIMATE) Доступность
Geo теперь поддерживает репликацию и проверку артефактов конвейера на вторичные сайты, что позволяет распределённым командам получать к ним доступ с ближайшего сайта Geo, что сокращает задержку и повышает удобство использования. Geo автоматически проверяет целостность данных реплицированных артефактов конвейера. Это гарантирует, что артефакты конвейера не будут повреждены при передаче или хранении. Если Geo используется как часть стратегии аварийного восстановления, это защитит клиентов от потери данных.
→ Документация по репликации в Geo и оригинальный тикет.
Улучшения удобства использования
(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE)
В каждом релизе мы делаем упор на улучшения общей эффективности и полезности нашего продукта.
У нас также есть Галерея UI Polish для отслеживания важных обновлений наших интерфейсов. Эти обновления, хоть часто и небольшие, заметно улучшают удобство использования.
В GitLab 13.11 мы поработали над тикетами, проектами, майлстоунами (в русской локализации GitLab «этапы») и многим другим! Мы особо выделяем следующие изменения в GitLab 13.11:
- Пояснения, что означают «покрытие» и «изменение» для покрытия кода.
- Ссылка из виджета результатов теста на файл, для которого не прошёл тест.
- Всплывающая подсказка должна указывать на активный пункт меню в выпадающем списке.
- Улучшили UX для включения/выключения левого навигационного элемента "CI/CD".
- Всплывающая подсказка на странице сведений о задании не должна перекрывать кликабельную ссылку.
- Улучшили метку для значения времени на странице индекса заданий.
- Удалили кнопку "CI Lint" со страницы заданий.
Список всех улучшений удобства использования в GitLab 13.11.
Полный текст релиза и инструкции по обновлению/установке вы можете найти в оригинальном англоязычном посте: GitLab 13.11 released with Kubernetes Agent and Pipeline Compliance.
Над переводом с английского работали cattidourden, maryartkey, ainoneko и rishavant.
