# Вышел релиз GitLab 13.4 с хранилищем HashiCorp для переменных CI и Kubernetes Agent
Вышел релиз 13.4 с хранилищем HashiCorp для переменных CI, Kubernetes Agent и центром безопасности, а также переключаемыми фичами в Starter
В GitLab мы всегда думаем о том, как помочь пользователям снизить риски, повысить эффективность и скорость поставки на вашей любимой платформе. В этом месяце мы добавили немало полезных новшеств, которые расширяют возможности безопасности, снижают количество уязвимостей, повышают эффективность, упрощают работу с GitLab и помогают вашей команде поставлять фичи ещё быстрее. Мы надеемся, что вам пригодятся основные фичи релиза, а также 53 другие новые фичи, добавленные в этом релизе.
Ещё один способ снизить риски — использование нового GitLab Kubernetes Agent. Специалисты по эксплуатации могут развёртывать кластеры Kubernetes из GitLab без необходимости открывать доступ к своему кластеру для всего интернета. Мы также представляем автоматическую поддержку контроля версий для новых файлов состояния Terraform с управляемым GitLab состоянием Terraform для поддержки соответствия требованиям и удобности в отладке. И наконец, панель управления безопасностью в инстансе превратилась в центр безопасности GitLab с отчётами об уязвимостях и настройками безопасности.
Fabio внёс значительный вклад в отображение покрытия кода в диффах мерж-реквестов — фичу, которую очень долго ждали в сообществе GitLab. Это действительно важный вклад с нетривиальными изменениями, которые требовали постоянного сотрудничества с членами команды GitLab и затрагивали множество областей проекта, таких как UX, фронтенд и бэкенд.
В релизе 12.10 GitLab представил возможность получать и передавать ключи в CI-задания с помощью обработчика заданий GitLab (GitLab runner). Теперь мы расширяем аутентификацию с помощью JWT, добавляя новый синтаксис secrets в файл .gitlab-ci.yml. Это облегчит настройку и использование хранилища HashiCorp с GitLab.
Интеграция GitLab с Kubernetes уже давно позволяет развёртывать на кластерах Kubernetes без необходимости ручной настройки. Многим пользователям понравилась простота использования этой связки, в то время как другие столкнулись с некоторыми трудностями. Для текущей интеграции ваш кластер должен быть доступен из интернета, чтобы GitLab мог иметь к нему доступ. Для многих организаций это не представляется возможным, поскольку они ограничивают доступ к кластерам из соображений безопасности, соответствия требованиям или в целях регулирования. Чтобы обойти эти ограничения, пользователям нужно было создавать свои инструменты поверх GitLab, иначе они не смогли бы использовать эту возможность.
Сегодня мы представляем GitLab Kubernetes Agent — новый способ развёртывания на кластерах Kubernetes. Агент работает внутри вашего кластера, так что вам не потребуется открывать его для всего интернета. Агент координирует развёртывание, запрашивая новые изменения у GitLab, вместо того, чтобы GitLab отправлял обновления на кластер. Независимо от того, какой метод GitOps вы используете, GitLab вам подойдёт.
Обратите внимание, что это первый релиз агента. В настоящее время мы сделали для GitLab Kubernetes Agent упор на настройку и управление развёртыванием через код. Некоторые существующие функции интеграции Kubernetes, такие как доски развёртывания и приложения, управляемые GitLab, пока не поддерживаются. Мы предполагаем, что эти возможности будут добавлены в агент в будущих релизах, а также новые интеграции, ориентированные на безопасность и соответствие требованиям.
Ранее система разрешений в GitLab не давала возможности грамотно разделить обязанности в вашей команде между теми, кто отвечает за разработку, и теми, кто отвечает за развёртывание. С релизом GitLab 13.4 вы можете дать разрешение на подтверждение мерж-реквестов для развёртывания, а также на фактическое развёртывание кода людям, не пишущим код, при этом не предоставляя им права доступа мейнтейнера (в русской локализации GitLab «сопровождающий»).
Ранее управление уязвимостями на уровне инстанса было ограничено как по функциональности, так и по гибкости. Интерфейс представлял собой одну страницу, которая объединяет в себе детали уязвимостей, графики метрик и настройки. Не так уж много места для развития этих функций или использования других средств безопасности.
Мы внесли фундаментальные изменения в управление безопасностью и её прозрачностью в GitLab. Панель безопасности инстанса преобразовалась в целый центр безопасности. Самое большое изменение — это введение новой структуры меню: вместо одной страницы теперь вы отдельно видите панель управления безопасностью, отчёт об уязвимостях и раздел настроек. Хотя функциональность не изменилась, разбиение на части позволит улучшать этот раздел, что в противном случае было бы затруднительно. Это также создаёт базу для добавления в будущем других возможностей, связанных с безопасностью.
У специального раздела для отчёта об уязвимостях теперь больше места для отображения важных деталей. Здесь собраны уязвимости, которые в настоящее время находятся в списке уязвимостей проекта. Перенос виджетов с метриками уязвимостей в отдельный раздел создаёт удобную панель управления безопасностью. Теперь это холст для будущих визуализаций — не только для управления уязвимостями, но и для любых метрик, связанных с безопасностью. Наконец, отдельная область настроек создаёт общее пространство для всех настроек безопасности на уровне инстанса, не только для управления уязвимостями.
Ранее в этом году GitLab взял на себя обязательство переместить 18 фич в открытый исходный код. В этом релизе мы завершили перенос переключаемых фич в план Starter и продолжим перенос их в Core с GitLab 13.5. Мы рады предоставить эту возможность большему количеству пользователей и хотим узнать, как вы будете их использовать.
Иногда при навигации по GitLab вы хотите сразу перейти к определённому проекту, а не на страницу с результатами поиска.
С помощью панели глобального поиска вы можете быстро перейти к последним тикетам, группам, проектам, настройкам и разделам справки. Вы даже можете использовать горячую клавишу /, чтобы переместить курсор на панель поиска, чтобы ещё эффективнее перемещаться по GitLab!
При ревью мерж-реквеста может быть трудно определить, покрыт ли изменённый код юнит-тестами. Вместо этого проверяющие могут полагаться на общее покрытие и требовать его увеличить, прежде чем подтверждать мерж-реквест. Это может привести к бессистемному подходу к написанию тестов, что на самом деле не улучшит качество кода или его покрытие тестами.
Теперь при просмотре диффа мерж-реквеста вы увидите наглядное отображение покрытия кода. Новые пометки позволят быстро понять, покрыт ли изменённый код юнит-тестом, что поможет ускорить ревью кода и время мержа и развёртывания нового кода.
С релиза GitLab 12.5 с помощью панели окружений вы могли отслеживать состояние окружений, но не более семи окружений в трёх проектах. Мы улучшили эту панель в релизе 13.4, разбив её на страницы, чтобы помочь вам поддерживать ваши окружения и управлять ими в больших масштабах. Теперь вы можете видеть больше окружений в большем количестве проектов.
Фаззинг-тестирование API — это отличный способ поиска в ваших веб-приложениях и API ошибок и уязвимостей, которые другие сканеры и методы тестирования могут пропустить.
Тестирование API фаззингом в GitLab позволяет предоставить спецификацию OpenAPI v2 или HAR-файл вашего приложения, а затем автоматически генерирует случайные входные данные, предназначенные для проверки краевых случаев и поиска ошибок. Результаты сразу же отображаются в рамках вашего конвейера.
Это наш первый релиз тестирования API фаззингом, и мы будем рады узнать, что вы думаете. Для фаззинг-тестирования у нас в запасе ещё много идей, которые мы будем основывать на релизе этой фичи.
Раньше создание графика на панели метрик в GitLab было непростой задачей. После того, как вы создали метрику в YAML-файле панели, вы вносили изменения в master, не имея возможности проверить, что только что созданный график работает именно так, как вам было нужно. Начиная с этого релиза вы можете предварительно просматривать изменения по мере создания графика, получая представление о результате перед отправкой изменений в YAML-файл панели.
Когда вы управляете большим количеством проектов в GitLab, вам требуется единый источник информации о том, как со временем меняется покрытие кода по всем проектам. Ранее отображение этой информации требовало утомительной и трудоёмкой ручной работы: нужно было скачать данные о покрытии кода тестами из каждого проекта и объединить их в таблице.
В релизе 13.4 появилась возможность легко и быстро собрать в .csv файл все данные о покрытии кода по всем проектам группы или по выборке проектов. Эта фича — MVC, за ней последует возможность построить график среднего покрытия с течением времени.
Этот релиз представляет поддержку нескольких новых языков для фаззинг-тестирования, нацеленного на полное покрытие.
Теперь вы можете оценить все возможности фаззинг-тестирования в ваших приложениях на Java, Rust и Swift и найти ошибки и уязвимости, которые другие сканеры и методы тестирования могут пропустить.
Страница окружений показывает общее состояние ваших окружений. В этом релизе мы улучшили эту страницу, добавив отображение оповещений. Сработавшие оповещения вместе со статусом ваших окружений помогут вам быстрее принимать меры по исправлению возникающих ситуаций.
При использовании вложенных конвейеров стало возможным запускать новые конвейеры внутри дочерних конвейеров. Дополнительный уровень глубины может быть полезен, если вам нужна гибкость для генерации переменного количества конвейеров.
Ранее при использовании вложенных конвейеров каждому дочернему конвейеру требовалось задание-триггер, вручную заданное в родительском конвейере. Теперь же вы можете создавать вложенные конвейеры, которые будут динамически запускать любое количество новых вложенных конвейеров. Например, если у вас монорепозиторий, вы можете динамически генерировать первый вложенный конвейер, который сам будет создавать необходимое количество новых конвейеров, основываясь на изменениях в ветке.
Перемещаться между родительскими и вложенными конвейерами ранее было не очень удобно — нужно было множество кликов, чтобы добраться до нужного конвейера. Также было нелегко понять, какое именно задание запустило этот конвейер. Теперь увидеть связи между родительскими и вложенными конвейерами станет гораздо проще.
Если вы использовали матрицу заданий, вы могли заметить, что было сложно определить, какая матричная переменная использовалась для определённого задания, так как названия задания выглядели как matrix 1/4. В релизе 13.4 вы будете видеть релевантные значения переменных, которые были использованы в этом задании, вместо общего названия задания. Например, если ваша цель — отладка для архитектуры x86, то задание будет называться matrix: debug x86.
Пользователи GitLab теперь смогут подключать свои аккаунты GitLab к аккаунту Atlassian Cloud. Это позволит авторизоваться в GitLab с учётными данными Atlassian, а также заложит основу для будущих улучшений в интеграции Gitlab с Jira и с другими продуктами из линейки Atlassian.
Организациям, нацеленным на соблюдение требований, нужен способ показать аудиторам целостное представление компонентов, связанных с любым конкретным изменением на продакшене. В рамках GitLab это означает, что нужно собрать в одном месте всё: мерж-реквесты, тикеты, конвейеры, сканирования безопасности и другие данные о коммите. До сих пор вам приходилось либо вручную собирать это в GitLab, либо настраивать свои инструменты для сбора информации, что было не очень эффективно.
Теперь вы можете программно собирать и экспортировать эти данные для удовлетворения требований аудита или проведения других анализов. Чтобы экспортировать список всех коммитов мержа для текущей группы, вам нужно перейти к панели соответствия требованиям и кликнуть на кнопку Список всех коммитов мержа. Полученный в результате файл будет содержать все коммиты мерж-реквеста, их автора, ID связанного мерж-реквеста, группу, проект, подтверждающих и другую информацию.
Управление доступом к пространству имён GitLab — это важная часть деятельности по соблюдению требований. От принципов минимальных привилегий до отключения доступа по таймеру — могут быть несколько требований, связанных с личными токенами доступа в GitLab. Чтобы было удобнее поддерживать и управлять всеми этими учётными данными пользователей в рамках вашего пространства имён, мы предоставили возможность выводить список всех личных токенов доступа и опционально запрещать доступ через API.
Эти улучшения в API GitLab позволяют пользователям выводить список и аннулировать свои собственные личные токены доступа, а администраторам — выводить список и аннулировать токены своих пользователей. Теперь администраторам будет легче видеть тех, у кого есть доступ к их пространству имён, принимать решения о предоставлении доступа на основе данных пользователей, а также аннулировать личные токены доступа, которые могли быть скомпрометированы или которые выходят за пределы правил компании по управлению доступом.
При ревью изменений кода, обсуждений и коммитов мерж-реквеста зачастую желательно делать локальный checkout ветки для более глубокого ревью. Однако найти имя ветки становится всё сложнее по мере того, как к описанию мерж-реквеста добавляется больше контента, и приходится всё дальше листать страницу.
Мы добавили имя ветки на боковую панель мерж-реквеста, что делает его доступным в любое время и избавляет от необходимости пролистывать всю страницу. Как и ссылка на мерж-реквест, раздел с исходной веткой содержит удобную кнопку «скопировать».
Спасибо Ethan Reesor за огромный вклад в разработку этой фичи!
Мерж-реквесты, которые добавляют изменения к нескольким файлам, иногда сворачивают диффы больших файлов, чтобы улучшить производительность отображения. Когда это происходит, можно случайно пропустить файл при ревью, особенно в мерж-реквестах с большим числом файлов. Начиная с версии 13.4 мерж-реквесты будут отмечать диффы, содержащие свёрнутые файлы, благодаря чему вы не пропустите эти файлы в процессе ревью кода. Для ещё большей ясности мы планируем добавить подсветку этих файлов в будущем релизе. Следите за обновлениями в тикете gitlab#16047.
В разделе с диффами мерж-реквестов крупные файлы сворачиваются для повышения производительности. Однако при ревью кода некоторые файлы могут быть пропущены, когда ревьюер пролистывает список файлов, так как все крупные файлы свёрнуты.
Мы добавили видимое предупреждение наверху страницы диффа мерж-реквеста, чтобы информировать пользователей о том, что в этом разделе есть свёрнутый файл. Таким образом, вы не пропустите никакие изменения в мерж-реквесте при ревью.
Раньше, когда первичная нода кластера Gitaly отключалась, репозитории на этой ноде помечались как доступные только для чтения. Это предотвращало потерю данных в ситуациях, если на ноде были изменения, которые ещё не реплицировались. Когда нода снова подключалась, GitLab не восстанавливался автоматически, и администраторам приходилось вручную запускать процесс синхронизации или мириться с потерей данных. Также могли приводить к появлению устаревших или доступных только для чтения репозиториев и другие ситуации, такие как неудачное завершение задания по репликации на вторичной ноде. В этом случае репозиторий оставался устаревшим до тех пор, пока не была произведена следующая операция записи, которая бы запустила задание по репликации.
Для решения этой проблемы Praefect теперь планирует задание по репликации, когда он обнаруживает устаревший репозиторий на одной ноде и последнюю версию репозитория на другой. Это задание по репликации делает репозиторий актуальным автоматически, что избавляет от необходимости восстанавливать данные вручную. Автоматическое восстановление также обеспечивает быстрое приведение к актуальному состоянию вторичных нод, если задание по репликации завершается неудачно, вместо того, чтобы ждать следующей операции записи. Так как многие кластеры Gilaly хранят большое число репозиториев, это значительно снижает время, которое администраторы и инженеры по обеспечению надёжности тратят на восстановление данных после ошибки.
Кроме того, автоматическая починка запускает репликацию репозиториев на любой новой ноде Gitaly, добавленной к кластеру, что избавляет от ручной работы при добавлении новых нод.
Эффективная коммуникация в GitLab основана на списках заданий to-do. Если вас упомянули в комментарии, то критически важно иметь возможность перейти к заданию и либо начать что-то делать, либо пометить его как уже выполненное. Также важно иметь возможность назначать задание себе, когда вам нужно поработать над чем-то или вернуться к этому позже.
Ранее вы не могли добавлять задания или помечать их как выполненные при работе с дизайнами. Это серьёзно нарушало эффективность коммуникации между продуктовыми командами, так как задания to-do — это критически важный элемент рабочего процесса в GitLab.
В релизе 13.4 дизайны догоняют комментарии к тикетам в использовании заданий, что делает работу с ними более последовательной и эффективной.
Мы улучшили руководство по устранению неполадок для GitLab CI/CD, добавив дополнительную информацию про распространённые проблемы, с которыми вы можете столкнуться. Мы надеемся, что улучшенная документация будет ценным ресурсом, который поможет вам быстро и просто настраивать и запускать GitLab CI/CD.
Ранее мерж-реквесты могли выпасть из очереди мержа случайно из-за поздних комментариев. Если мерж-реквест уже находился в очереди, и кто-то добавлял к нему комментарий, который создавал новое неразрешённое обсуждение, мерж-реквест считался неподходящим для мержа и выпадал из очереди. Теперь, после того, как мерж-реквест добавляется к очереди мержа, новые комментарии можно добавлять, не боясь нарушить процесс мержа.
У разработчиков должна быть возможность видеть значение покрытия кода после завершения конвейера — даже в сложных сценариях, таких как работа конвейера с несколькими заданиями, которые нужно парсить, чтобы рассчитать значение покрытия. Ранее виджет мерж-реквеста показывал только среднее от этих значений, что означало, что вам приходилось переходить на страницу задания и обратно к мерж-реквесту, чтобы получить промежуточные значения покрытия. Чтобы сэкономить ваше время и избавить вас от этих лишних шагов, мы сделали в виджете отображение среднего значения покрытия, его изменения между целевой и исходной ветками и всплывающую подсказку, которая показывает значение покрытия для каждого задания, на основе которого было рассчитано среднее значение.
Реестр пакетов GitLab — это место для хранения и распространения пакетов в разных форматах. Когда в вашем проекте или группе много пакетов, вам нужно быстро идентифицировать неиспользуемые пакеты и удалять их, чтобы люди их не скачивали. Вы можете удалять пакеты из своего реестра через API пакетов или через пользовательский интерфейс реестра пакетов. Однако до сих пор вы не могли удалять пакеты при просмотре группы через пользовательский интерфейс. В результате вам приходилось удалять лишние пакеты отдельно для каждого проекта, что было неэффективно.
Теперь вы можете удалять пакеты при просмотре реестра пакетов группы. Просто перейдите на страницу реестра пакетов группы, отфильтруйте пакеты по имени и удалите все ненужные.
Вы можете использовать репозиторий Conan в GitLab для публикации и распространения зависимостей C/C++. Однако ранее пакеты можно было масштабировать только до уровня инстанса, так как название пакета Conan могло состоять максимум из 51 символа. Если вы хотели опубликовать пакет из подгруппы, например gitlab-org/ci-cd/package-stage/feature-testing/conan, это было почти невозможно сделать.
Теперь вы можете масштабировать пакеты Conan до уровня проекта, что позволяет легко публиковать и распространять зависимости ваших проектов.
Мы рады добавить сканирования зависимостей для проектов с кодом на C, C++, C# и .Net, которые используют NuGet 4.9+ или менеджеры пакетов Conan, к нашему списку поддерживаемых языков и фреймворков. Теперь вы можете включать сканирование зависимостей как часть стадии Secure, чтобы проверять на известные уязвимости зависимости, добавленные через менеджеры пакетов. Найденные уязвимости будут отображаться в вашем мерж-реквесте вместе с уровнем их опасности, чтобы вы знали до выполнения мержа какие риски несёт в себе новая зависимость. Вы также можете настроить свой проект так, чтобы он требовал подтверждения мерж-реквеста для зависимостей с уязвимостями с критическим (Critical), высоким (High) или неизвестным (Unknown) уровнем опасности.
Ранее при задании настройки мерж-реквеста Мержить, когда завершится конвейер (Merge When Pipeline Succeeds, MWPS) никакого email-уведомления не отправлялось. Вам приходилось вручную проверять статус или ждать уведомления о выполнении мержа. В этом релизе мы рады представить вклад пользователя @ravishankar2kool, который решил эту проблему, добавив автоматическую отправку уведомлений всем, кто подписан на мерж-реквест, когда ревьюер меняет настройку мержа на MWPS.
Не каждая возникающая проблема сразу запускает отправку оповещений: пользователи сообщают о сбоях в работе, а члены команд разбираются в проблемах с производительностью. Теперь инциденты являются разновидностью тикета, так что ваши команды смогут быстро создавать их в рамках привычного рабочего процесса. Кликните Новая задача из любого места в GitLab, и в поле Тип выберите Инцидент.
Мы улучшили оповещения GitLab, добавив новый тип упоминания специально для них на GitLab-версии Markdown, что позволяет проще делиться оповещениями и упоминать их. Используйте ^alert#1234, чтобы упомянуть оповещение в любом поле с разметкой Markdown: в инцидентах, тикетах или мерж-реквестах. Это также поможет вам определять задания, которые создаются из оповещений, а не из тикетов или мерж-реквестов.
Описание оповещения содержит информацию, критически важную для диагностирования сбоев и восстановления, и эта информация должна быть легко доступной, чтобы вам не приходилось переключать инструменты или вкладки при работе над разрешением инцидента. Инциденты, созданные из оповещений, отображают полное описание оповещения во вкладке Alert Details.
У GitLab, как единого приложения, есть уникальная возможность сделать поиск контента по всему рабочему процессу DevOps быстрым. В GitLab 13.4 расширенный поиск выдаёт результаты на 75% быстрее, когда он ограничен до определённых пространств имён и проектов, как на GitLab.com.
Возможность отложить удаление проекта была введена в 12.6. Однако раньше не было возможности увидеть в одном месте все проекты, ожидающие удаления. Теперь администраторы пользовательских инстансов GitLab могут просматривать все проекты, ожидающие удаления, в одном месте — вместе с кнопками для лёгкого восстановления этих проектов.
Эта возможность позволяет администраторам лучше контролировать удаление проектов, собирая всю необходимую информацию в одном месте и предоставляя возможность отменить нежелательные действия по удалению.
Раньше групповые правила пуша можно было настроить только посещая каждую группу индивидуально через пользовательский интерфейс GitLab и применяя эти правила. Теперь вы можете управлять этими правилами через API для поддержки ваших пользовательских инструментов и автоматизации GitLab.
Хранилище учётных данных предоставляет администраторам информацию, необходимую для управления учётными данными пользователей их инстанса GitLab. Поскольку организации, ориентированные на соблюдение требований, различаются по строгости своих правил управления учётными данными, мы добавили кнопку, позволяющую администраторам при желании отозвать токен личного доступа пользователя (PAT). Теперь администраторы могут легко отозвать потенциально скомпрометированные PAT. Эта фича полезна для организаций, которым нужны более гибкие варианты для обеспечения исполнения требований, чтобы свести к минимуму отвлечения своих пользователей.
В GitLab 13.4 мы представляем новый способ настройки редактора статических сайтов. Хотя конфигурационный файл не сохраняет и не получает никаких параметров в этом релизе, мы закладываем основу для будущей настройки поведения редактора. В следующих релизах мы добавим в файл .gitlab/static-site-editor.yml параметры для установки базового адреса сайта, на котором хранятся изображения, загруженные в редакторе, переопределение настроек синтаксиса Markdown и других настроек редактора.
Вступительная часть (front matter) — это гибкий и удобный способ определения переменных страницы в файлах данных, предназначенных для обработки генератором статических сайтов. Обычно она используется для установки заголовка страницы, шаблона макета или автора, но может использоваться для передачи любого типа метаданных в генератор при рендере страницы в HTML. Включаемая в самый верх каждого файла данных, вступительная часть обычно форматируется как YAML или JSON и требует согласованного и точного синтаксиса. Пользователи, незнакомые с конкретными правилами синтаксиса, могут непреднамеренно ввести недопустимую разметку, что, в свою очередь, может вызвать проблемы с форматированием или даже сбои сборки.
Режим редактирования WYSIWYG редактора статических сайтов уже убирает вступительную часть из редактора, чтобы предотвратить эти ошибки форматирования. Однако это не даёт вам изменить значения, хранящиеся в этой части, без возврата к редактированию в режиме исходного кода. В GitLab 13.4 вы можете получить доступ к любому полю и редактировать его значение в знакомом интерфейсе на основе форм. При нажатии кнопки Настройки (Settings) откроется панель, на которой отображается поле формы для каждого ключа, определённого в начале. Поля заполняются текущим значением, и для редактирования любого из них достаточно просто ввести его в веб-форме. Такое редактирование вступительной части позволяет избежать сложностей в синтаксисе и даёт вам полный контроль над содержимым, обеспечивая при этом единообразное форматирование окончательного результата.
Для пользователей Jira в GitLab: приложение GitLab для Jira и DVCS Connector позволяют отображать информацию о коммитах и мерж-реквестах GitLab непосредственно в Jira. В сочетании с нашей встроенной интеграцией с Jira вы можете легко перемещаться между двумя приложениями во время работы.
Эти функции раньше были доступны только в нашем плане Premium, а теперь они доступны всем пользователям!
Кластер Gitaly позволяет реплицировать репозитории Git на несколько «тёплых» нод Gitaly. Это повышает отказоустойчивость за счёт устранения единичных точек отказа. Транзакционные операции, представленные в GitLab 13.3, вызывают широковещательную передачу изменений на все ноды Gitaly в кластере, но только ноды Gitaly, которые голосуют по согласованию с первичной нодой, сохраняют изменения на диск. Если все ноды-реплики не пришли к согласию, только одна копия изменения будет сохранена на диске, создавая единую точку отказа до завершения асинхронной репликации.
Голосование с большинством голосов повышает отказоустойчивость, требуя согласия большинства нод (а не всех) перед сохранением изменений на диске. Если эта переключаемая фича включена, запись должна будет выполниться успешно на нескольких нодах. Несогласные ноды автоматически синхронизируются с помощью асинхронной репликации с тех нод, что образовали кворум.
Проекты, где люди пишут конфигурации в формате JSON или YAML, часто подвержены проблемам, потому что легко сделать опечатку и что-то сломать. Можно написать инструменты проверки, отлавливающие эти проблемы в конвейере CI, но использовать файл схемы JSON может быть полезно, чтобы предоставлять документацию и подсказки.
Участники проекта могут определить в их репозитории путь к пользовательской схеме в файле .gitlab/.gitlab-webide.yml, который указывает схему и путь к файлам для проверки. При загрузке определённого файла в Web IDE будет видна дополнительная обратная связь и проверка, которые помогут создать файл.
Если вы используете конвейеры с направленным ациклическим графом (Directed Acyclic Graph (DAG)), вы могли обнаружить, что ограничение в 10 заданий, которые задание может указать в needs:, слишком сурово. В 13.4 предел по умолчанию был увеличен с 10 до 50, чтобы обеспечить более сложные сети взаимосвязей между заданиями в ваших конвейерах.
Если вы администратор пользовательского инстанса GitLab, то вы можете поднять этот предел ещё выше, настроив переключаемую фичу, хотя мы не предлагаем официальную поддержку для этого.
В некоторых случаях пропущенное задание в конвейере могло ошибочно считаться успешным для зависимостей, указанных в needs, из-за чего запускались последующие задания, чего происходить не должно было. Это поведение исправлено в версии 13.4, и needs теперь корректно обрабатывает случаи пропущенных заданий.
GitLab теперь автоматически блокирует последний артефакт успешного задания и конвейера на любой активной ветке, мерж-реквесте или теге, чтобы предотвратить его удаление после истечения срока действия. Становится проще устанавливать более агрессивные правила срока действия для очистки старых артефактов. Это помогает снизить потребление дискового пространства и гарантирует, что у вас всегда будет копия последнего артефакта из конвейера.
Оптимизация работы конвейера CI/CD может повысить скорость поставки и сэкономить деньги. Мы улучшили нашу документацию, добавив краткое руководство по достижению максимальной отдачи от оптимизации ваших конвейеров.
Отчёт о юнит-тестах — это простой способ увидеть результаты всех тестов в конвейере. Однако при большом количестве тестов поиск неудачных тестов может занять много времени. Другие проблемы, из-за которых может быть сложно использовать отчёт, включают трудности с прокруткой длинных выходных данных трассировки и округление времени до нуля для тестов, выполняемых менее чем за 1 секунду. Теперь по умолчанию отчёт о тестировании при сортировке сначала помещает неудавшиеся тесты в начало отчёта, а потом сортирует тесты по продолжительности. Это упрощает поиск сбоев и длительных тестов. Кроме того, продолжительность тестов теперь отображается в миллисекундах или секундах, поэтому читать их стало намного быстрее, и также были решены предыдущие проблемы с прокруткой.
Теперь есть ограничения на размер файлов пакетов, которые можно загружать в реестр пакетов GitLab. Ограничения были добавлены для оптимизации производительности реестра пакетов и предотвращения злоупотреблений. Ограничения зависят от формата пакета. Для GitLab.com максимальные размеры файлов:
Conan: 250MB
Maven: 3GB
NPM: 300MB
NuGet: 250MB
PyPI: 3GB
Для пользовательских инстансов GitLab значения по умолчанию такие же. Однако администратор может обновить ограничения с помощью консоли Rails.
Вы можете использовать репозиторий GitLab PyPI для создания, публикации и совместного использования пакетов Python вместе с исходным кодом и конвейерами CI/CD. Однако раньше вы не могли пройти аутентификацию в репозитории с помощью предварительно определённой переменной окружения CI_JOB_TOKEN. В результате вам приходилось использовать свои личные учётные данные для обновления репозитория PyPI, или вы, возможно, решали вообще не использовать репозиторий.
Теперь стало проще использовать GitLab CI/CD для публикации и установки пакетов PyPI с помощью предопределённой переменной окружения CI_JOB_TOKEN.
К сканированию DAST по запросу, которое было введено в предыдущем релизе, добавились профили сканера DAST. Они расширяют возможности конфигурации этого сканирования, позволяя быстро создавать несколько профилей для охвата нескольких типов сканирования. В 13.4 профиль сканера изначально включает параметр тайм-аута поискового робота, который устанавливает, как долго должен работать поисковый робот DAST, когда он пытается обнаружить все страницы сканируемого сайта. Профиль также включает параметр тайм-аута целевого сайта, чтобы установить, как долго сканер должен ждать, пока сайт станет доступным, прежде чем прервать сканирование, если сайт не отвечает кодом состояния 200 или 300. По мере того, как мы будем снова и снова улучшать эту фичу в следующих релизах, в профиль сканера будут добавлены дополнительные параметры конфигурации.
Если вы используете GitLab Pages и хотите лучше управлять изменениями URL, то вы могли заметить, что управлять редиректами на своём сайте GitLab Pages было невозможно. GitLab теперь позволяет вам настраивать правила для перенаправления одного URL на другой для вашего сайта Pages, добавив файл конфигурации в репозиторий. Эта функция стала возможной благодаря участию Kevin Barnett (@PopeDrFreud), нашего Eric Eastwood (@MadLittleMods) и команды GitLab. Спасибо всем за ваш вклад.
Доступ к предыдущим версиям состояния Terraform необходим как для соответствия требованиям, так и для отладки при необходимости. Поддержка управления версиями состояния Terraform, управляемого GitLab, предоставляется начиная с GitLab 13.4. Управление версиями включается автоматически для новых файлов состояния Terraform. Существующие файлы состояния Terraform будут автоматически перенесены в хранилище с поддержкой версий в более позднем релизе.
При обработке инцидентов вам нужно легко определять, как долго предупреждение было открыто и сколько раз срабатывало событие. Эти детали часто имеют решающее значение при определении влияния на клиента и того, чем ваша команда должна заняться в первую очередь. На новой панели подробностей инцидентов мы отображаем время начала оповещения, количество событий и ссылку на исходное оповещение. Эта информация доступна по инцидентам, которые создаются из оповещений.
Параметр «серьёзность инцидента» позволяет специалистам по реагированию и заинтересованным сторонам определять последствия перебоя в работе, а также методы и срочность реагирования. По мере того как ваша команда делится результатами во время устранения инцидента и восстанавливает работоспособность, они могут изменять этот параметр. Теперь вы можете редактировать серьёзность инцидента на правой боковой панели страницы «Сведения об инциденте», а степень серьёзности отображается в списке инцидентов.
Это улучшение редактора правил сетевой безопасности контейнеров позволяет пользователям легко создавать, редактировать и удалять свои правила прямо из пользовательского интерфейса GitLab. Возможности редактора включают режим .yaml для опытных пользователей и редактор правил с интуитивно понятным интерфейсом для тех, кто плохо знаком с сетевыми правилами. Вы можете найти новые возможности управления правилами в разделе Безопасность и соответствие > Управление угрозами > Правила (Security & Compliance > Threat Management > Policies).
И GitLab, и GitLab Runner теперь поддерживают хранилище blob-объектов Azure, что упрощает запуск служб GitLab в Azure.
Инстансы GitLab поддерживают Azure для всех типов хранилищ объектов, включая файлы LFS, артефакты CI и резервные копии. Чтобы настроить хранилище blob-объектов Azure, следуйте инструкциям по установке Omnibus или Helm chart.
В ответ на растущий спрос на поддержку запуска GitLab для 64-битной архитектуры ARM, мы рады объявить о доступности официального пакета ARM64 Ubuntu 20.04 Omnibus. Огромное спасибо Zitai Chen и Guillaume Gardet за огромный вклад, который они внесли — их мерж-реквесты сыграли в этом ключевую роль!
Чтобы скачать и установить пакет для Ubuntu 20.04, перейдите на нашу страницу установки и выберите Ubuntu.
Смарт-карты, например карты общего доступа (CAC), теперь можно использовать для аутентификации в инстансе GitLab, развёрнутом через Helm chart. Смарт-карты аутентифицируются в локальной базе данных с помощью сертификатов X.509. Благодаря этому поддержка смарт-карт с Helm chart теперь находится в соответствии с поддержкой смарт-карт, доступной в развёртываниях Omnibus.