Вышел релиз GitLab 12.1 с параллельными цепочками мерж-реквестов и мерж-реквестами для конфиденциальных задач
Мы рады представить новые, уникальные фичи в релизе GitLab 12.1: параллельное выполнение цепочек мерж-реквестов (в русской локализации GitLab «запросы на слияние»), мерж-реквесты для конфиденциальных задач, а также такие долгожданные фичи, как управляемые сертификаты Let’s Encrypt для GitLab Pages. Читайте дальше и вы узнаете все об этих фичах.
Поддерживайте ваши master-ветки «зелеными» даже при частых обновлениях
Поддерживать master-ветку «зеленой» — критически важно для непрерывной поставки (Continuous Delivery). Когда продакшн-билд не собирается, это значит, что ваш новый код пока не отправится дальше, что повлияет и на пользователей, и на ваш доход. Единственный способ быть на 100% уверенным, что код в вашей ветке соберется после нового мерж-реквеста, — это запуск конвейера (в русской локализации GitLab «сборочная линия») с последней версией из ветки master. Но если у вас большое количество мерж-реквестов, это может быть проблематично или даже невозможно. За то время, что требуется на работу конвейера, запущенного из-за одного изменения, может быть внесено еще несколько изменений, что может привести к конфликтам. Единственный способ смягчить этот эффект — добавлять изменения в очередь. Благодаря этому, когда конвейер запустится, другой код не будет смержен раньше, чем это изменение. Именно поэтому мы создали цепочки мерж-реквестов и выпустили первую версию этой фичи в релизе 12.0.
В релизе 11.10 мы ввели конвейеры по результатам мерж-реквеста. Если эта фича подключена, GitLab автоматически создаст отдельную ссылку (ref), в которой будет результат мержа исходной и целевой ветки, и запустит конвейер на основе этой ссылки, а не просто исходной ветки. Таким образом, вы сможете узнать, безопасно ли мержить этот код в master-ветку, без необходимости делать rebase.
Цепочки мерж-реквестов используют эту фичу и ставят мерж-реквесты в очередь в нужном порядке, как только они были отправлены на мерж в целевую ветку. Кнопка merge в мерж-реквесте была заменена на кнопку start/add to merge train (начать/добавить в цепочку мержей), нажатие на нее добавит этот мерж-реквест в очередь. Мерж-реквесты будут обработаны в правильном порядке, даже если добавляются очень быстро.
Изначально цепочки мерж-реквестов выполнялись последовательно. Сначала должен был выполниться конвейер по предыдущему мерж-реквесту, прежде чем мог быть запущен следующий; благодаря этому master-ветка оставалась «зеленой», но выполнение могло занимать много времени. В релизе GitLab 12.1 мы улучшили цепочки мерж-реквестов так, что теперь они работают параллельно. Одновременно может выполняться до четырех конвейеров по ссылке с предыдущего мерж-реквеста в цепочке, если все предыдущие мерж-реквесты собрались успешно. Таким образом, конвейер будет необходимо перезапустить, только если предыдущий мерж-реквест не собрался. Выполнение цепочек мерж-реквестов параллельно значительно ускоряет процесс. Вы можете начать работу с цепочками мерж-реквестов прямо сейчас, подключив запуск конвейеров по результатам мерж-реквеста и ваша master-ветка всегда будет оставаться «зеленой».
Работайте над важными обновлениями приватно
Работать публично в открытом доступе — отличный инструмент для совместной работы; проекты с открытым исходным кодом показывают, как важно иметь возможность вносить изменения, где бы вы ни находились. GitLab считает, что прозрачность дает очень много преимуществ, так что мы делаем публичными не только наши тикеты и код, но и наши бизнес-процессы.
Но кроме вещей, которыми стоит делиться, есть также некоторые вещи, которые лучше оставить приватными. Типичный сценарий для многих публичных проектов — необходимость держать в тайне уязвимости, над которыми еще работают, чтобы снизить риск их эксплуатации. GitLab уже поддерживал конфиденциальные задачи в публичных проектах, но для создания конфиденциального мерж-реквеста ранее требовалось делать это в отдельном приватном репозитории.
Теперь же с мерж-реквестами для конфиденциальных задач все стало намного проще — нажатие на кнопку Create Confidential Merge Request (создать конфиденциальный мерж-реквест) из конфиденциальной задачи позволит пользователю выбрать приватный форк, в котором будет создана новая ветка с этим мерж-реквестом, что позволит вам оставить все в тайне до тех пор, пока не будет пора опубликовать этот код в публичном доступе.
Автоматические сертификаты HTTPS для Pages от Let’s Encrypt
GitLab Pages — это удобный способ создавать контент в сети: от страниц-лендингов и документации до артефактов вашего проекта и отчетов. Конечно, защищать ваш трафик через HTTPS необходимо, но сам процесс поддержки и обновления сертификатов довольно трудоемкий. А при управлении большим количеством доменов это становится еще труднее. Без встроенного, поддерживаемого GitLab управления сертификатами многие организации не могут использовать GitLab Pages на желаемом уровне.
Участники сообщества GitLab не раз говорили нам, насколько полезными будут автоматические сертификаты Let’s Encrypt для GitLab Pages, и сегодня мы рады объявить, что эта фича теперь есть в GitLab. Всего один клик в настройках ваших Pages и вы получите безопасный трафик ко всем доменам и поддоменам ваших страниц.
И даже больше!
В релизе 12.1 так много классных фич, что мы никак бы не смогли рассказать в обзоре обо всех. Вот еще несколько улучшений из этого релиза: дедупликация объектов Git, панели развертывания для кластеров Kubernetes в группе и инстансе и назначение группы владельцами кода. Читайте далее, чтобы узнать все подробности об этих фичах, а также получить ссылки на документацию.
MVP этого месяца — Guillaume Grossetie
Вклады Guillaume в релизы 12.0 и 12.1 добавили важные и часто запрашиваемые улучшения в нашу поддержку AsciiDoc как на странице репозитория, так и на страничках вики.
Огромное спасибо Guillaume за эту работу!
Основные фичи релиза GitLab 12.1
Параллельное выполнение цепочек мерж-реквестов
(PREMIUM, ULTIMATE, SILVER, GOLD) Стадия цикла DevOps: “Release”
Когда вы быстро и в большом объеме отправляете изменения, master-ветка или целевая ветка должна оставаться «зеленой», аккуратной и с возможностью быстрого подтверждения. Для того, чтобы это обеспечить, мы улучшили цепочки мерж-реквестов, добавив параллельную стратегию запуска конвейера. Параллельный запуск ускоряет подтверждение, добавляя мерж-реквесты в очередь по порядку и запуская конвейеры параллельно. Аккуратность достигается за счет того, что мерж-реквесты, у которых конвейеры завершились неуспешно, автоматически удаляются из цепочки, а подтвержденные мерж-реквесты в вашей целевой ветке будут выставлены в новом порядке.
Документация по цепочкам мерж-реквестов и оригинальный тикет.
Мерж-реквесты для конфиденциальных задач
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Create”
Проектам с открытым исходным кодом может быть непросто обсуждать, планировать и решать в публичном репозитории конфиденциальные задачи, такие, как уязвимости в безопасности.
С релизом 12.1 стало возможным решать конфиденциальные задачи даже в публичных проектах — нажатие на кнопку Create confidential merge request (создать конфиденциальный мерж-реквест) из конфиденциальной задачи создаст приватный форк специально для этого мерж-реквеста.
Документация по конфиденциальным задачам и оригинальный тикет.
Автоматические сертификаты HTTPS для Pages от Let’s Encrypt
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Release”
С релизом 12.1 пользователи GitLab Pages при добавлении нового домена могут включить автоматическое управление сертификатами через Let’s Encrypt. Если эта настройка включена, GitLab обеспечит ваш домен сертификатами с помощью Let’s Encrypt, будет следить за их сроком и автоматически их обновлять.
Для каждого домена вы можете настроить это отдельно, в зависимости от ваших требований.
Документация по интеграции с Let’s Encrypt и оригинальный тикет.
Дедупликация объектов Git
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Create”
При помощи разветвления рабочего процесса легко делать вклад в любой проект, создавая копию проекта для работы над ним до того, как открыть мерж-реквест для мержа изменений в основной проект. Для популярных проектов требования к хранилищу на серверной стороне, необходимому для тысяч копий, растут быстро и увеличивают стоимость хостинга.
В GitLab 12.1 при создании форка публичного проекта также будет создан пул объектов (если его не существовало) и будет использован файл objects/info/alternates для уменьшения требований к хранилищу.
Дедупликация объектов требует, чтобы родительский проект и текущий проект использовали хэшированное хранилище. Существующие форки пока не перемещаются в пулы объектов автоматически, за обновлениями можно следить здесь: gitaly#1560.
В следующем релизе мы также добавим быстрое ветвление за счет прямого создания форка уже дедуплицированным. На данный момент ветвление сначала создается, а потом дедуплицируется.
Документация по хэшированным пулам объектов и оригинальный тикет.
Другие улучшения в GitLab 12.1
Алиасы проектов для Git через SSH
(PREMIUM, ULTIMATE) Стадия цикла DevOps: “Create”
При переносе Git-репозиториев в GitLab и другие системы, которым нужен доступ к этим репозиториям, бывает полезно использовать одно и то же имя в разных системах. Во многих случаях это уже возможно, но некоторые инструменты для работы с Git, например, Gitolite, позволяют получить доступ к проекту без задания пространства имен. В GitLab каждый проект существует в пространстве имен, что может усложнить миграцию таких проектов.
С релизом 12.1 администраторы инстанса GitLab могут использовать новый API алиасов проекта для задания проекту алиаса в GitLab, снижая риски при миграции в GitLab.
Документация по работе с алиасами проектов и оригинальный тикет.
Расширяемые обработчики заданий
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Verify”
Вместе с релизом 12.1 мы представляем новый способ расширить функциональность обработчиков заданий (runner) GitLab вашим прописанным поведением, которое может служить для поддержки различных платформ обеспечения, настройки безопасной среды или реализации процессов обеспечения соответствия, задания секретных переменных или даже для запуска любого кода во время выполнения обработчика.
Вы можете использовать эту фичу на gitlab.com, но из-за того, что конфигурация привязывается к обработчику заданий, а не к .gitlab-ci.yml, вам потребуется зарегистрировать ваши обработчики заданий.
Документация по собственным executors и оригинальный тикет.
Принудительная вставка шаблонов конвейера на уровне инстанса
(PREMIUM, ULTIMATE) Стадия цикла DevOps: “Verify”
Администраторы инстанса могут задавать необходимый метод include:, который запускается на каждом конвейере, созданном в инстансе. Это можно использовать для обеспечения соблюдения требований к безопасности или к стандартизированным процессам, которые должны выполняться без исключений, что способствует согласованности в процессе CI/CD вашей компании.
Документация по настройкам репозитория шаблона инстанса и оригинальный тикет.
Множественные обсуждения по диффу
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Create”
Обсуждение и запрос изменений, заявленных в мерж-реквесте, являются ключевыми моментами в рабочем процессе мерж-реквеста, однако иногда изменение единственной строчки может потребовать проведения нескольких независимых обсуждений. Например, обсуждение корректности строчки кода и обсуждение более широких ее применений в данной кодовой базе могут потребовать создания отдельных тредов.
В GitLab 12.1 стало возможным создавать несколько обсуждений для одной строчки диффа мерж-реквеста, что позволяет параллельно проводить несколько обсуждений и уменьшит шум в обсуждениях по диффу.
Документация по разрешаемым комментариям и обсуждениям и оригинальный тикет.
Назначение групп в качестве владельцев кода
(STARTER, PREMIUM, ULTIMATE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Create”
Часто бывает не очевидно, кто должен производить ревью предложенных вами изменений. Назначение владельцев кода для отдельных файлов упрощает это распределение обязанностей. Как только владелец кода назначен, его можно увидеть при просмотре файла и автоматически назначить ответственным за принятие мерж-реквеста.
В GitLab 12.1 помимо назначения владельцев кода по имени пользователя и по email, вы также можете назначать группы в качестве владельцев кода. Это поможет владельцам кода не выпадать из работы при смене команд, особенно при использовании LDAP для управления групповыми учетными записями.
Документация по владельцам кода и оригинальный тикет.
Самостоятельное обновление планов подписки на GitLab.com (SaaS)
(FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Growth”
Теперь вы можете обновлять ваш план подписки GitLab через портал платежей пользователей! Ранее для этого приходилось вручную обращаться к GitLab, чтобы запросить обновление, что было неудобно и занимало много времени.
Добавление возможности обновлять подписку на план без необходимости подключаться вручную — это большой шаг к полностью автоматизированной платформе для оплачивания и лицензирования.
Для большей информации по дорожной карте (в русской локализации GitLab «план развития») команды Fulfillment посмотрите эту страницу!
Документация по планам подписки и оригинальный тикет.
Предстоящие релизы
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Release”
Некоторым пользователям удобно создавать и обсуждать релизы до того, как они будут отправлены. Теперь вы можете создавать предстоящие релизы через API релизов, задавая будущее время переменной released_at. Это делает предстоящие релизы видимыми в хронологическом порядке на странице Releases наряду с другими релизами и показывает метку «Предстоящий релиз» для релизов, датированных будущем временем.
Если вы не изменяете значение переменной released_at (дата релиза), то по умолчанию ей присваивается значение created_date (дата создания).
Документация по релизам и оригинальный тикет.
Подсвечивание синтаксиса блоков кода AsciiDoc
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Create”
Синтаксис блоков кода AsciiDoc теперь подсвечивается при просмотре AsciiDoc через репозитории или вики.
Спасибо Guillaume Grossetie за эту фичу!
Документация по блокам AsciiDoc и оригинальный тикет.
Улучшенное форматирование AsciiDoc
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Create”
AsciiDoc поддерживает несколько меток форматирования помимо предоставляемых Markdown, включая метки подчеркивания, зачеркивания, подсвечивания, уменьшения и уведомлений (окон предупреждений). Эти метки форматирования теперь рендерятся и становятся видимыми при просмотре AsciiDoc в репозиториях и вики.
Спасибо Guillaume Grossetie за эту фичу!
Документация по AsciiDoc и оригинальный тикет.
Автоматическое подключение Rugged для NFS
(CORE, STARTER, PREMIUM, ULTIMATE) Стадия цикла DevOps: “Create”
После того, как мы убрали Rugged и добавили Gitaly для всех операций Git, мы заметили значительное снижение производительности в крупных инстансах GitLab при использовании NFS. Чтобы решить эти проблемы с производительностью, мы добавили и бэкпортировали подключаемые фичи, для возможности заново подключить инструменты Rugged, которые улучшат производительность инстансов GitLab, использующих NFS.
Если GitLab решит, что Rugged можно безопасно активировать, то он сделает это автоматически, чтобы улучшить производительность инстансов GitLab, использующих NFS.
Улучшения в производительности происходят с каждым релизом: улучшаются шаблоны доступа к Git, производительность Git и появляется кэширование. Вы можете прочитать об этом в нашем недавнем посте в блоге «Как мы собираемся исправить ухудшение производительности NFS с Gitaly».
Документация по улучшению производительности NFS с GitLab и оригинальный тикет.
Скачивание процессов cat-файлов с каждой сессией Rails
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Create”
В GitLab есть интерфейсы, в которых показаны детали по произвольным коммитам, например, обсуждения по мерж-реквестам или списки конвейеров CI. Получение информации о коммитах по одному коммиту за раз слишком медленно, так как требуются дополнительные затраты на запуск процесса Git каждый раз.
Теперь GitLab использует один и тот же процесс cat-file для каждой сессии запроса Rails. После добавления этого изменения на GitLab.com, мы заметили значительное снижение средней задержки для удаленных вызовов процедур FindCommit и TreeEntry.
Вы можете узнать об этом больше в нашем недавнем посте в блоге «Как мы собираемся исправить ухудшение производительности NFS с Gitaly».
Документация по кэшу cat-файла и оригинальный тикет.
Ключевое слово default для настроек .gitlab-ci.yml на высшем уровне
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Verify”
Для удобства и организации вариантов настроек на высшем уровне в gitlab-ci.yml, мы переместили следующие параметры настройки под отдельное ключевое слово default: before_script, after_script, image, services, variables и cache. Это изменение полностью обратно-совместимо, и существующие параметры настройки вне контекста default все еще учитываются.
Документация по настройкам CI/CD по умолчанию и оригинальный тикет.
Доступ к кластерам на уровне инстанса через веб-терминал
(CORE, STARTER, PREMIUM, ULTIMATE) Стадия цикла DevOps: “Configure”
С помощью веб-терминалов очень удобно отлаживать проблемы, при этом нет необходимости покидать свой удобный браузер. В GitLab 12.1 мы добавили возможность использовать веб-терминалы для развертываний на основе кластеров Kubernetes на уровне инстанса.
Документация по веб-терминалам в GitLab и оригинальный тикет.
Панели развертывания для кластеров Kubernetes на уровне инстанса
(PREMIUM, ULTIMATE) Стадия цикла DevOps: “Configure”
Панели развертывания дают наиболее полное представление о текущем состоянии и статусе каждого окружения CI, запущенного на Kubernetes, отображая статус подов в развертывании. Начиная с GitLab 12.1 эти панели стали доступны для развертываний на кластерах уровня инстанса.
Документация по панелям развертывания и оригинальный тикет.
Доступ к кластерам на уровне группы через веб-терминал
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Configure”
С помощью веб-терминалов очень удобно отлаживать проблемы, при этом нет необходимости покидать свой удобный браузер. В GitLab 12.1 мы добавили возможность использовать веб-терминалы для развертываний на основе кластеров Kubernetes на уровне группы.
Документация по веб-терминалам в GitLab и оригинальный тикет.
Панели развертывания для кластеров Kubernetes на уровне группы
(PREMIUM, ULTIMATE, SILVER, GOLD) Стадия цикла DevOps: “Configure”
Панели развертывания дают наиболее полное представление о текущем состоянии и статусе каждого окружения CI, запущенного на Kubernetes, отображая статус подов в развертывании. Начиная с GitLab 12.1 эти панели стали доступны для развертываний на кластерах группового уровня.
Документация по панелям развертывания и оригинальный тикет.
Удаление JupyterHub через управление приложениями Kubernetes
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Configure”
Начиная с GitLab 12.1, приложение JupyterHub можно удалять через кластер Kubernetes.
Документация по удалению приложений и оригинальный тикет.
Удаление Ingress через управление приложениями Kubernetes
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Configure”
Начиная с GitLab 12.1, приложение Ingress можно удалять через кластер Kubernetes.
Документация по удалению приложений и оригинальный тикет.
Создание и хранение панелей метрик в репозитории
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Monitor”
Вы можете создавать собственные панели на основе важных метрик, необходимых для наблюдения за состоянием вашего приложения. Начиная с 12.1 вы можете хранить версии этих панелей в Git прямо рядом с кодом вашего приложения. В 12.1 мы начали с поддержки типов диаграмм «area» и «single-stat».
Документация по настройке пользовательских панелей для проекта и оригинальный тикет.
Обновление Knative до версии 0.6
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Configure”
Чарт приложений Knative был обновлен до v0.6, обеспечив ряд улучшений, которые включают в себя более качественное масштабирование и альфа-версию поддержки auto-TLS.
Документация по Knative и оригинальный тикет.
Аннотация инцидентов GitLab атрибутами из оповещения Prometheus
(ULTIMATE, GOLD) Стадия цикла DevOps: “Monitor”
Когда возникает инцидент (а обычно это происходит в самое неподходящее время), бывает трудно выяснить, что вызывает проблему и где начинать исправлять. В 12.1 мы включаем аннотацию инцидентов GitLab с использованием атрибутов оповещения Prometheus. Реализация этой фичи является MVC, и мы рады продолжить улучшение настройки инцидентов в будущем.
Документация по инцидентам и оригинальный тикет.
Geo проверяет целостность файлов для вложений, объектов LFS и артефактов заданий
(PREMIUM, ULTIMATE, SILVER, GOLD) “Enablement”
Целостность данных имеет решающее значение при репликации данных с первичной ноды на вторичную. Команда Geo в настоящее время работает над улучшением проверки реплицированных данных. С 12.1 Geo вычисляет контрольные суммы для вложений, объектов LFS и артефактов задания на вторичных нодах после передачи, сравнивает их с сохраненными контрольными суммами и отклоняет передачи при несовпадении. Обратите внимание, что в настоящее время Geo не поддерживает автоматический способ проверки этих данных если они синхронизировались до 12.1.
Документация по проверке данных в фоновом режиме и оригинальный тикет.
Поддержка подгрупп для реестра NPM
(PREMIUM, ULTIMATE, SILVER, GOLD) Стадия цикла DevOps: “Package”
Реестр NPM GitLab дает возможность разработчикам node.js публиковать пакеты NPM и делиться ими. Однако многие люди не могли использовать эту фичу из-за отсутствия поддержки подгрупп. Мы рады объявить, что в версии 12.1 мы изменили формат имени пакета в реестре NPM на @root_namespace_path/any-name, чтобы обеспечить аутентификацию и получение пакетов на уровне группы или подгруппы.
Документация по наименованию пакетов в реестре NPM и оригинальный тикет.
Предупреждение о несовместимых символах в реестре контейнеров
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Package”
Реестр контейнеров GitLab позволяет создавать, пушить и совместно использовать изображения/теги Docker в GitLab. Однако, если в имени группы, проекта или ветки есть специальные символы (например, начальное подчеркивание, конечный дефис/тире, двойной дефис/тире), то при переходе в реестр контейнеров проектов возникает «ошибка 500» без каких бы то ни было объяснений.
В 12.1 мы обновили страницу для реестра контейнеров, которая отображается, если вы не можете подключиться к реестру Docker. Теперь она содержит объяснение ошибки и ссылку на документацию о том, как устранить проблему.
Документация по реестру контейнеров и ошибках подключения Docker и оригинальный тикет.
Улучшенные обнаружение и навигация для функций GitLab Package
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Package”
Стадия “Package” цикла DevOps включает в себя реестр контейнеров, реестр пакетов и прокси зависимостей (Dependency Proxy). До 12.1 все эти функции были вложены в различные разделы навигации верхнего уровня, из-за чего их было сложно найти и не так удобно использовать. По мере того, как мы запускаем больше функций и интеграций для стадии «Package», мы должны гарантировать, что проблем с поиском больше не будет.
С версии 12.1 мы сгруппировали все эти функции в новой системе навигации верхнего уровня Пакеты (Packages), чтобы их было легче найти, а также чтобы обеспечить место для размещения будущих функций, таких как метрики и политики, связанные со стадией “Package”.
Документация по реестрам контейнеров и оригинальный тикет.
API для извлечения данных из списка зависимостей
(ULTIMATE, GOLD) Стадия цикла DevOps: “Secure”
Теперь вы можете использовать данные из списка зависимостей через API, чтобы создавать автоматизированные процессы или применять другие внешние инструменты. Этот API должен упростить и ускорить генерацию данных зависимостей, необходимых для отчетов о соответствии.
Этот API является общедоступным, поэтому можно получать информацию для этого списка в формате JSON.
Документация по API для списка зависимостей и оригинальный тикет.
Поддержка пользовательских реестров PyPI при сканировании зависимостей
(ULTIMATE, GOLD) Стадия цикла DevOps: “Secure”
Теперь при сканировании зависимостей можно использовать пользовательские реестры PyPI. Для этого добавлена поддержка переменных окружения PIP_INDEX_URL и PIP_EXTRA_INDEX_URL.
Документация по настройке переменных окружения и оригинальный тикет.
Возможность установить панель безопасности в качестве вида по умолчанию для групп
(ULTIMATE, GOLD) Стадия цикла DevOps: “Secure”
Команды по обеспечению безопасности используют эту панель в качестве основного инструмента своей работы. Они должны иметь возможность установить ее в качестве вида по умолчанию для группы, чтобы переход к группе сразу показывал именно ее.
Документация по настройке поведения и оригинальный тикет.
Утверждение безопасности в мерж-реквестах
(ULTIMATE, GOLD) Стадия цикла DevOps: “Secure”
Чтобы позволить командам сосредоточиться на наиболее важных элементах безопасности и избежать потерь из-за большого количества результатов, GitLab теперь позволяет клиентам автоматически утверждать специальным образом отмеченные мерж-реквесты, если в них нет уязвимостей определенного уровня серьезности. Это позволяет создать рабочий процесс, который позволит группам безопасности участвовать в утверждении мерж-реквестов без необходимости подтверждения каждого из них. Эта фича относится к уровню MVC.
Документация по безопасности приложений и оригинальный тикет.
Включение списка всех просканированных URL в DAST
(ULTIMATE, GOLD) Стадия цикла DevOps: “Secure”
До сих пор мы не включали в мерж-реквест все пути/URL, которые были просканированы и протестированы с помощью динамического тестирования безопасности приложений (DAST), поэтому пользователь не знал, что именно было просканировано, и завершено ли полное сканирование.
Документация по безопасности приложений и DAST и оригинальный тикет.
Требование использования смарт-карт при работе с Git
(PREMIUM, ULTIMATE) Стадия цикла DevOps: “Manage”
Инстансы, использующие смарт-карты для аутентификации с помощью аппаратного токена, могут входить в интерфейс GitLab начиная с версии 11.6. В версии 12.1 мы расширяем поддержку смарт-карт в командной строке, позволяя инстансам включить требование входа в систему с помощью смарт-карты, прежде чем разрешить работу с Git.
Благодаря этому изменению организации, применяющие смарт-карты, смогут использовать их в качестве комплексного решения для аутентификации как для пользовательского интерфейса, так и для работы с Git, особенно в сочетании с LDAP.
Документация по аутентификации с помощью смарт-карт и оригинальный тикет.
Разработчик может переписывать/удалять теги Git
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Manage”
Теги Git полезны для ссылки на конкретные места и обычно используются для маркировки определенных версий. Чтобы упростить использование тегов Git группами разработчиков, мы добавляем возможность, позволяющую разработчикам (с ролью “Developer”) переписывать и удалять незащищенные теги. Для защищенных тегов по-прежнему требуются права “Maintainer” или “Owner” (владелец).
Документация по правам доступа и оригинальный тикет.
Сворачивание списков в досках задач
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Plan”
В досках задач (в русской локализации GitLab «доски обсуждений») может быть много списков, что затрудняет их горизонтальную навигацию. В 12.1 мы добавили возможность сворачивать список доски задач. Кроме того, теперь вам будет легче перетащить задачу из списка открытых в список закрытых, когда остальные списки между ними свернуты.
Документация по доскам задач и оригинальный тикет.
Изменение майлстоуна для многих тикетов на уровне группы
(PREMIUM, ULTIMATE, SILVER, GOLD) Стадия цикла DevOps: “Plan”
Пользователь может изменить майлстоун (в русской локализации GitLab «этап») для нескольких тикетов одновременно в конкретном проекте. В GitLab 12.1 мы выпускаем возможность массового редактирования майлстоунов для многих тикетов на уровне группы, что упрощает управление теми и другими.
Документация по массовому редактированию и оригинальный тикет.
Добавили настройки для учета рабочего времени
(CORE, STARTER, PREMIUM, ULTIMATE) Стадия цикла DevOps: “Plan”
Не во всех частях мира рабочая неделя составляет 40 часов. Это приводит к тому, что учет времени в GitLab оказывается неточным для тех мест, где рабочая неделя длится, к примеру, 35 часов. В 12.1 на уровне инстанса введен параметр для настройки количества рабочих часов в неделе, а также возможность всегда отображать абсолютные часы при учете времени.
Документация по учету времени и оригинальный тикет.
Подробные release notes и инструкции по обновлению/установке можно прочитать в оригинальном англоязычном посте: GitLab 12.1 released with Parallel Merge Trains and Merge Requests for Confidential Issues.
Над переводом с английского работали @cattidourden, @maryartkey, @ainoneko и @rishavant.
