Вышел релиз GitLab 12.4 с улучшенными зависимостями мерж-реквестов и API для аудита
Новый релиз GitLab 12.4 содержит много улучшений для управления работой, например API для аудита, подтверждение владельцев кода для защищенных веток и управление доступом к страницам (GitLab Pages). Зависимости мерж-реквестов помогут совместить работу разных команд, а многие другие новые фичи предназначены для повышения продуктивности и ускорения поставки ПО.
Зависимости мерж-реквестов
GitLab нацелен на улучшение совместной работы и повышение прозрачности и продуктивности. Когда разработчики работают вместе для достижения большей цели, их небольшие изменения часто нужно мержить в определенной последовательности, чтобы всё работало, как было задумано. Для упрощения этой задачи служат зависимости мерж-реквестов, которые можно задать в мерж-реквестах и тем самым удостовериться, что изменения будут добавлены в нужном порядке. Для код-ревью тоже будет полезным ясно видеть такие зависимости. Эта фича была представлена в релизе 12.2 как межпроектные зависимости мерж-реквестов. Теперь мы переименовали ее просто в «зависимости мерж-реквестов» и расширили для поддержки разных типов зависимостей. Например, теперь она поддерживает и межпроектные зависимости, и зависимости того же проекта.
Мы понимаем, что возможность управлять процессами очень важна для наших пользователей. Дальше — еще несколько фич 12.4, которые помогут вам в этом.
API для аудита событий
GitLab стремится повысить прозрачность и упорядочить процессы всего жизненного цикла разработки. Именно поэтому GitLab хорошо работает с другими системами. В новом релизе мы представляем API для аудита событий вашего инстанса. Аудит событий — отличный способ контроля соблюдения требований. С новым API администраторы смогут программно получать эти события и настраивать необходимые мониторинг и оповещения.
Управление доступом к страницам на GitLab.com
Управление доступом к страницам GitLab Pages уже было доступно для пользовательских инстансов, а теперь также доступно на GitLab.com. Эта фича позволяет авторизованному администратору ограничить доступ к страницам, или же наоборот, открыть публичный доступ. Эту фичу реализовали пользователи GitLab, и мы рады добавить ее на GitLab.com!
Подтверждение владельцев кода для защищенных веток
Еще одна фича, расширяющая возможности управления — подтверждение владельцев кода для защищенных веток. Использование подтверждения мерж-реквестов помогает ограничить то, какой код отправится в защищенные ветки. Это улучшает качество кода и упрощает процессы обеспечения соответствия. Тем не менее, не все мерж-реквесты направлены в стабильные ветки, и не все стабильные ветки требуют одинакового контроля. С релизом 12.4 стало возможным избежать отправки изменений напрямую или их мержа без разрешения владельцев кода данной ветки.
И даже больше!
В релизе 12.4 так много классных фич, что мы никак бы не смогли рассказать в обзоре обо всех. Наши любимые: оповещения для релизов, просмотр логов пода из любого окружения и поддержка приватных проектов для онлайн-просмотра HTML-артефактов Читайте далее, чтобы узнать все об этих фичах.
Посмотрите видео про нашу первую европейскую пользовательскую конференцию 9-го октября. Следующая конференция пользователей GitLab состоится в январе в Сан-Франциско, регистрация уже открыта.
MVP этого месяца — Tuomo Ala-Vannesluoma
Tuomo добавил в GitLab 12.4 просмотр HTML-артефактов в приватных проектах — фичу, за которую проголосовали около 300 человек. Для Tuomo это уже вторая награда MVP, первая была в релизе 11.5 за управление доступом к страницам GitLab Pages. Спасибо за работу с нами на протяжении всего года, мы очень ценим это!
Основные фичи релиза GitLab 12.4
Зависимости мерж-реквестов
(PREMIUM, ULTIMATE, SILVER, GOLD) Стадия цикла DevOps: “Create”
Разработчики часто работают вместе для достижения общей цели, и делают при этом множество небольших изменений. Эти изменения необходимо мержить в определенной последовательности, чтобы все работало, как было задумано, — и в них легко запутаться.
Зависимости мерж-реквестов предотвращают мерж изменений в неправильном порядке, а также упрощают код-ревью, так как ревьювер сразу видит полную картину предлагаемых изменений. Эта фича была представлена в релизе 12.2, а в 12.4 мы ее расширяем для поддержки зависимостей в одном проекте.
Документация по зависимостям мерж-реквестов и оригинальный тикет.
<h2 id=”audit-events-api”>API для аудита событий</h2> (PREMIUM, ULTIMATE) Стадия цикла DevOps: “Manage”
Аудит событий — отличный способ следить за активностью в GitLab. С его помощью организации могут проверять, соблюдают ли пользователи все требования, что может быть особенно важно для организаций со строгим регламентом.
Для использования аудита событий в автоматизации мы добавили API для событий уровня инстанса. С его помощью администраторы смогут программно получать события и настраивать необходимые оповещения и мониторинг.
Документация по API аудита событий и оригинальный тикет.
Подтверждение владельцев кода для защищенных веток
(PREMIUM, ULTIMATE, SILVER, GOLD) Стадия цикла DevOps: “Create”
Подтверждение мерж-реквестов перед мержем в защищенные ветки помогает улучшать качество кода и обеспечивать соответствие требованиям. Тем не менее, не все мерж-реквесты направлены в стабильные ветки, и не все стабильные ветки требуют одинакового контроля.
С релизом 12.4 стало возможным запрашивать подтверждение от владельцев кода для указанных веток, и тем самым избежать отправления изменений напрямую или мержа без разрешения их владельцев. Если ранее вы настраивали подтверждение владельцами кода через настройки проекта, оно теперь автоматически требуется для существующих защищенных веток.
Документация по настройке подтверждений мерж-реквестов в защищенных ветках и оригинальный тикет.
Управление доступом к страницам на GitLab.com
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Release”
Управление доступом к страницам GitLab Pages позволяет авторизованному администратору ограничить доступ к страницам или же, наоборот, открыть публичный доступ. Теперь вы можете требовать авторизацию для просмотра контента ваших приватных проектов, что упростит публикацию и управление доступом к внутренней документации.
Посмотрите видео, которое вкратце расскажет об управлении доступом к страницам.
Документация по управлению доступом к страницам и оригинальный тикет.
Оповещения для релизов
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Release”
Теперь вы можете подписаться на оповещения о новых релизах в проекте, и узнавать о новых версиях даже для тех проектов, в которых вы не участвуете. Так вы сможете быть в курсе обновлений проектов, от которых зависит ваша работа, больше не понадобится проверять обновления вручную.
Посмотрите видео, которое вкратце расскажет об оповещениях для релизов.
Документация по оповещениям и оригинальный тикет.
Просмотр логов пода из любого окружения
(ULTIMATE, GOLD) Стадия цикла DevOps: “Monitor”
Ранее логи GitLab в основном были доступны со страницы Окружений. Однако, было не очень удобно переключаться между логами с разных окружений, и нельзя было сразу получить доступ к логам без входа в какое-либо окружение.
С релизом 12.4 мы добавили возможность посмотреть любые логи из любого окружения или пода. На странице Окружений вы увидите две кнопки для просмотра логов любых подов ваших кластеров Kubernetes. В будущем мы планируем добавить доступ к логам через прямую ссылку в меню Операций (Operations).
Документация по логам подов Kubernetes и оригинальный тикет.
Другие улучшения в GitLab 12.4
Использование Jaeger через интерфейс GitLab
(ULTIMATE, GOLD) Стадия цикла DevOps: “Monitor”
Трассировка дает представление о состоянии и производительности развернутого приложения благодаря отслеживанию работы функций и микросервисов, обрабатывающих нужный запрос.
Jaeger — распределенная система трассировки с открытым исходным кодом, она используется для мониторинга и устранения неисправностей в распределенных системах, основанных на микросервисах. Начиная с релиза 12.4 пользователи, использующие Jaeger, смогут работать с ним и следить за состоянием и производительностью своих приложений прямо из GitLab.
Документация по трассировке с помощью Jaeger и оригинальный тикет.
Расширение поддержки переменных для межпроектных конвейеров
(PREMIUM, ULTIMATE, SILVER, GOLD) Стадия цикла DevOps: “Verify”
При использовании межпроектных конвейеров один конвейер запускает другой, и часто требуется хранить динамическое значение в переменной первого конвейера, и иметь к ней доступ из запущенного нового конвейера. Например, если конвейер работает в какой-то ветке, и вы хотите, чтобы все нисходящие конвейеры имели доступ к значению $CI_COMMIT_REF_NAME этой ветки.
Ранее эта переменная не передавалась на нисходящие конвейеры, так что вызов переменной через ключевое слово trigger приводил к ошибке no ref name. Чтобы получить нужный результат, требовалось создавать отдельное задание, единственной целью которого было выполнение cURL-команды для передачи переменной следующему конвейеру. Это не только требовало отдельной настройки и ресурсов для запуска, но и делало неочевидными связи между конвейерами при просмотре в интерфейсе.
Теперь же GitLab будет передавать переменные, указанные в branch ключевого слова trigger, дальше всем нисходящим конвейерам, что облегчит вам работу над описаниями конвейеров и добавит гибкости запускам конвейеров, работающих с несколькими проектами.
Документация по указанию ветки для работы конвейеров и оригинальный тикет.
DAST для ветки мастер
(ULTIMATE, GOLD) Стадия цикла DevOps: “Secure”
Мы рады объявить, что сканирования DAST теперь можно запускать для главной ветки проекта внутри специального приложения для ревью. Раньше DAST можно было запускать только для выделенных веток. Это расширение позволит создавать базу по результатам сканирования DAST, на основе которой будут оцениваться остальные мерж-реквесты. Так вы сможете определить ветку, на которой появились новые проблемы с безопасностью.
Документация по DAST и оригинальный тикет.
Проверка наличия файлов в конвейерах
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Configure”
Новое добавление к синтаксису rules:, изначально представленному в GitLab 12.3. Правило rules:exists принимает на вход массив путей и выдаст совпадение, если какие-то из этих файлов существуют в репозитории. Это полезно в случаях, когда вы хотите, чтобы задание CI запускалось только при наличии определенных файлов, — например, чтобы конвейер tests запускался только если существует файл tests.yml. Использование этого правила может способствовать ускорению работы конвейеров благодаря пропуску шагов, на которых нужные файлы не были найдены.
Документация по правилу rules:exists и оригинальный тикет.
Нативная поддержка Geo для репликации хранилища объектов
(PREMIUM, ULTIMATE) “Enablement”
В GitLab 12.4 Geo нативно поддерживает репликацию данных в хранилище объектов, таких как объекты LFS, артефакты заданий и загрузки. Ранее Geo можно было настраивать для работы с хранилищем объектов, однако за репликацию его содержимого всегда должен был отвечать провайдер. Из-за этого возникали ограничения при использовании пользователями локального хранилища, которое не поддерживало репликацию.
Нативная поддержка Geo позволяет производить репликацию данных между различными поставщиками хранилищ объектов, находящимися в разных регионах (например, Amazon в Европе и Microsoft в США). Пользователи Geo могут использовать локальное хранилище (например, через MinIO) и использовать Geo для репликации данных на вторичные ноды.
Нативная поддержка Geo для хранилища объекта выпущена в качестве бета-версии и пока не готова для использования в продакшене.
Документация по репликации данных хранилища объектов и оригинальный тикет.
Улучшенная работа с большими файлами через частичное клонирование git (альфа-версия)
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Create”
Хранение больших бинарных файлов в git, как правило, не одобряется, так как это приводит к чрезмерному расширению репозитория, из-за чего сильно замедляется скачивание и клонирование. Такие решения, как Git LFS позволяют обходить эту проблему, путем хранения больших файлов вне репозитория git и скачивания их по требованию.
В GitLab 12.4 мы добавили экспериментальную поддержку частичного клонирования, что позволит исключать большие файлы при клонировании репозитория и скачивании обновлений. Это избавит пользователей от необходимости выбирать, какие файлы нужно хранить в git, а какие — вне репозитория при помощи Git LFS. Поддержка частичного клонирования по умолчанию отключена, но ее можно включить для конкретного проекта при наличии Git версии 2.22.0 и выше.
По сравнению с Git LFS, вместо предъявления специальных требований к управлению большими файлами при создании коммита, частичное клонирование позволяет разработчикам, CI-менеджерам и другим пользователям Git явно указывать, какие файлы они хотят скачать. Это избавляет от необходимости объяснять людям, какие файлы нужно отправлять в Git LFS, а какие - нет, от необходимости отправляться назад во времени, чтобы перенести большие файлы в Git LFS, а также от проблем, связанных с тем, что кто-то случайно отправил большой файл в репозиторий, хотя нужно было отправить в Git LFS. Проще говоря, большие файлы просто будут работать как полагается.
Документация по частичному клонированию и оригинальный тикет.
Выбор даты в аналитике продуктивности
(PREMIUM, ULTIMATE, SILVER, GOLD) Стадия цикла DevOps: “Manage”
До сих пор у пользователей не было возможности выбирать определенный диапазон дат для метрик в циклической аналитике и аналитике продуктивности. По сути, они не могли просматривать метрики продуктивности на протяжении определенного спринта или диапазона дат, так как мы предоставляли только фиксированные периоды в 7, 30, 60 и 90 дней. С выпуском этой фичи пользователи смогут визуализировать данные за любой промежуток времени и для тех периодов, которые имеют для них значение.
Документация по аналитике продуктивности и оригинальный тикет.
Нативный VPC по умолчанию при создании кластера GKE в GitLab
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Configure”
Google Kubernetes Engine дает возможность создавать VPC-нативные кластеры, которые размещаются на IP-адресах Alias и предоставляют встроенную поддержку VPC для связи между контейнерами. Это приводит к появлению более масштабируемых, безопасных и простых систем, которые подходят для развертываний и сценариев использования с высокими требованиями.
Начиная с GitLab 12.4, интеграция GitLab с GKE при создании кластера GKE будет включать эту настройку по умолчанию.
Документация по добавлению нового кластера GKE и оригинальный тикет.
Ограничение разрешений для заданий CI с ручным запуском
(PREMIUM, ULTIMATE, SILVER, GOLD) Стадия цикла DevOps: “Verify”
Зачастую для работы с развертываниями, нестрогими подтверждениями и другими входами командам необходимо создавать задания с ручным управлением, но при работе с Gitlab сложно разобраться, как ограничивать разрешения, чтобы не давать любому пользователю право выполнять какое-либо действие.
На самом деле, в текущей версии Gitlab уже было возможно задавать ограничения разрешений, но для этого не было четкой документации. В этом релизе мы значительно улучшили документацию по защите заданий с ручным запуском, чтобы пользователям было проще понять, как это делается.
Документация по защите заданий с ручным запуском и оригинальный тикет.
Удаление дизайнов через панель управления дизайнами
(PREMIUM, ULTIMATE, SILVER, GOLD) Стадия цикла DevOps: “Create”
Иногда при работе с дизайнами происходят ошибки или меняются цели по дизайнам, и может быть важно иметь возможность удалять дизайн из ревью. При помощи удаления через панель управления дизайнами пользователи смогут выбирать один или несколько дизайнов и удалять их из последней версии. Таким образом, последняя версия дизайна будет представлять текущее состояние работы.
Документация по удалению дизайнов и оригинальный тикет.
Расширенный API для окружения и развертывания
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Release”
Мы добавили функциональность API, которая будет возвращать атрибуты окружений state и last deployment. Пример использования этой информации — написание скрипта для удаления неиспользуемых окружений.
Документация по окружениям и оригинальный тикет.
Улучшенная документация по обновлению Geo
(PREMIUM, ULTIMATE) “Enablement”
В рамках упрощения процесса обновления Geo мы переработали крупные части нашей документации по обновлению Geo. GitLab Geo можно развертывать в различных конфигурациях, что, в зависимости от конфигурации, потребует выполнения различных шагов. Чтобы начать работу над упрощением обновления Geo, мы в первую очередь сфокусировались на улучшении документации по этому процессу. Теперь мы можем гарантировать, что документация актуальна и описывает все сценарии использования.
Мы переписали общие шаги по обновлению, заархивировали старые шаги, обновили инструкции по обновлению «на лету» для простых развертываний и поработали над многими другими частями документации.
Мы также работаем над инструкциями для обновления «на лету» высокодоступных, многонодовых кластеров Geo, однако, перед релизом эти инструкции необходимо протестировать.
Далее мы планируем работать над улучшенной автоматизацией, улучшенным тестированием и повышением надежности определенных процедур по обновлению.
Документация по обновлению нод Geo и оригинальный тикет.
Ссылки на мерж-реквесты напрямую из конвейера
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Verify”
При просмотре конвейера может быть полезно иметь возможность перемещаться к мерж-реквесту, связанному с ним. Мы добавили прямые ссылки на связанные мерж-реквесты, чтобы упростить доступ к ним и повысить эффективность вашей работы.
Документация по визуализации конвейеров и оригинальный тикет.
Вставка заданий в начало или в конец конвейера через include
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Verify”
Один из распространенных сценариев использования ключевого слова include — добавлять задания в начало или в конец конвейера. Однако, как автор общего include, вы можете не всегда знать, как будут называться начальная или конечная стадия. Из-за этого попытки написать задание, которое запускается в начале или в конце конвейера усложняются, и повышается вероятность возникновения ошибок.
Для упрощения вставки заданий через include в GitLab 12.4 доступны стадии конвейера .pre и .post, которые гарантированно запускаются в начале и в конце конвейера соответственно.
Документация по .pre и .post и оригинальный тикет.
Обновление приложения Kubernetes NGINX Ingress при установке через интеграцию с Kubernetes
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Configure”
Используя последнюю версию Kubernetes для развертывания ваших приложений, вы можете быть уверены, что в вашем распоряжении имеются все новые фичи и современная защита. GitLab 12.4 позволяет вам использовать последнюю версию приложения NGINX Ingress при установке через GitLab Managed Apps. Для обновления уже установленной версии удалите и установите заново приложение Ingress через GitLab.
Документация по Ingress и оригинальный тикет.
Конечная точка API для ‘Static Status Check Names’ в интеграции с GitHub
(PREMIUM, ULTIMATE, SILVER, GOLD) Стадия цикла DevOps: “Verify”
Теперь становится возможным настраивать имена статических проверок статуса в интеграции с GitHub через API, что значительно упрощает изменение этих настроек для большого числа проектов.
Документация по API для сервисов GitHub Premium и оригинальный тикет.
Настройка размера артефактов для проекта/группы
(CORE, STARTER, PREMIUM, ULTIMATE) Стадия цикла DevOps: “Verify”
На текущий момент размер артефактов по умолчанию задан равным 100MB, однако, некоторые проекты требуют возможности обойти это ограничение. Чтобы сделать это возможным, в настройках группы и проекта мы добавили опцию для переопределения максимального размера глобальных артефактов, аналогично настройке максимального размера репозитория.
Документация по настройкам размера артефактов и оригинальный тикет.
<h3 id=”private-project-support-for-online-view-of-html-artifacts”>Поддержка приватных проектов для просмотра HTML-артефактов онлайн</h2> (CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Verify”
Просмотр HTML-артефактов в окне браузера является ключевым фактором эффективности. Так как это частая задача, очень важно иметь возможность быстро перейти от пролистывания артефактов к их открытию и просмотру. Без онлайн-просмотра вам нужно загрузить артефакт и запустить локальный веб-сервер, чтобы просмотреть отчет. Выполнение этого для каждого HTML-артефакта из всех ваших сборок напрасно тратит время и прерывает «состояние потока» из-за постоянного переключения контекста.
Ранее можно было просматривать артефакты HTML в окне браузера с помощью GitLab Pages, а не загружать их локально, но эта возможность была ограничена публичными проектами. Это становилось проблемой для многих предприятий и организаций, которые используют GitLab преимущественно с приватными проектами: онлайн-просмотр был для них недоступен. Теперь, благодаря замечательному вкладу Tuomo Ala-Vannesluoma, мы добавили поддержку онлайн-просмотра артефактов HTML и для приватных проектов. Обратите внимание, что для правильной работы этой фичи надо включить контроль доступа для страниц GitLab.
Документация по просмотру артефактов заданий и оригинальный тикет.
«Cloud Run on GKE» при создании кластера через интеграцию GKE
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Configure”
При создании кластера Kubernetes с помощью интеграции GitLab GKE пользователи теперь могут по желанию включить «Cloud Run on GKE» одним кликом. GKE автоматически обеспечит кластер обслуживанием Knative, Istio и балансировкой нагрузки HTTP. После установки пользователи смогут по-прежнему использовать возможности, предоставляемые GitLab Serverless для развертывания служб Knative с минимальной конфигурацией.
Обратите внимание, что «Cloud Run on GKE» недавно был переименован в «Cloud Run для Anthos». Мы планируем обновить название этой фичи в релизе следующего месяца.
Документация по Cloud Run для GKE и оригинальный тикет.
Общая конечная точка оповещения (MVC)
(ULTIMATE, GOLD) Стадия цикла DevOps: “Monitor”
Пользователи применяют различные инструменты для мониторинга окружений своих приложений. Эти инструменты отправляют критические, чувствительные ко времени оповещения, когда возникает инцидент и необходимо быстро принять меры. Теперь возможности GitLab по управлению инцидентами включают в себя общую конечную точку REST, куда вы можете отправлять оповещения независимо от инструмента, который их создал. Когда GitLab получает запрос POST к этой конечной точке, он автоматически создает тикет по инциденту. Полезная нагрузка включена в описание тикета, и часто используемые поля автоматически распознаются и заполняются. Это позволяет использовать тикеты GitLab как главное место реагирования на инциденты, используя данные от других ваших инструментов.
Посмотрите короткое видео, в котором рассказывается об общей конечной точке оповещения (MVC).
Докусментация по оповещениям и оригинальный тикет.
Geo поддерживает использование единого адреса Git с учетом местоположения
(PREMIUM, ULTIMATE) “Enablement”
Теперь Geo поддерживает предоставление пользователям одного удаленного адреса (URL), который автоматически использует ближайшую к ним ноду Geo. Это означает, что пользователям не нужно обновлять свою конфигурацию Git, чтобы использовать преимущества более близких нод Geo по мере перемещения. Фактически, конечным пользователям даже не нужно знать, что они используют локальную ноду Geo при первоначальном клонировании проекта. Для системных администраторов это устраняет необходимость поддерживать разные конфигурации Git для пользователей в разных местах. Это возможно, потому что push-запросы Git могут быть автоматически перенаправлены (HTTP) или проксированы (SSH) от вторичных нод к первичной ноде.
Geo можно настроить для использования различных сервисов, таких как AWS Route53 или Cloudflare.
Документация по адресу Git с учетом местоположения и оригинальный тикет.
Активность Git добавлена в ограничение IP-адреса группы
(ULTIMATE, GOLD) Стадия цикла DevOps: “Manage”
В GitLab 12.0 появилось ограничение активности группы по IP-адресу. В GitLab 12.3 мы включили активность через API в ограничение доступа. В GitLab 12.4 мы расширяем возможности ограничения, чтобы включить и действия Git через SSH.
Полученная в результате фича теперь обеспечивает широкий охват, отклоняя действия через пользовательский интерфейс, API и Git, если они не соответствуют ограничениям IP-адресов группы. Для организаций, ориентированных на соблюдение требований, особенно на GitLab.com, это обеспечивает важный и всеобъемлющий уровень безопасности.
Документация по ограничению доступа по IP-адресу для ULTIMATE и оригинальный тикет.
Точечные диаграммы для аналитики продуктивности
(PREMIUM, ULTIMATE, SILVER, GOLD) Стадия цикла DevOps: “Manage”
Ранее пользователи не могли легко визуализировать и измерять скорость с течением времени. Чтобы позволить им сделать это, мы добавляем в аналитику продуктивности точечные диаграммы, где пользователи могут выбрать «время до мержа» или любую другую метрику, связанную с мерж-реквестом, чтобы определить соответствующие тренды и отклонения. Пользователи также могут сосредоточиться на конкретном диапазоне дат, чтобы исследовать и анализировать определенные наборы данных.
Документация по аналитике продуктивности и оригинальный тикет.
API для ручного создания развертываний
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Release”
Мы добавили в API фичу, позволяющую создавать развертывания. Также она влияет на сами развертывания: связанная сборка CI теперь является необязательной. Это необходимо для того, чтобы заложить основу для поддержки внешних окружений и развертываний в GitLab.
Документация по созданию развертываний и оригинальный тикет.
Установка групповых обработчиков заданий одним кликом в Kubernetes
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Verify”
Создать общий обработчик заданий (runner) на уровне группы при использовании GitLab с Kubernetes стало проще, чем когда-либо. Возможность одним кликом установить обработчик заданий на уровне проекта уже была некоторое время доступна, но на уровне группы их по-прежнему надо было устанавливать вручную. Теперь можно просто нажать кнопку, и GitLab установит для вас общий групповой обработчик заданий.
Документация по настройке групп кластеров и оригинальный тикет.
Системные заметки управления дизайном
(PREMIUM, ULTIMATE, SILVER, GOLD) Стадия цикла DevOps: “Create”
В GitLab 12.2 мы выпустили первую версию управления дизайном, которая позволяла загружать дизайны непосредственно в тикеты. Они загружались в отдельную вкладку внутри тикетов, и их активность никак не логировалась. Это затрудняло определение того, добавлял ли кто-то дизайн в тикет. Начиная с GitLab 12.4, при загрузке дизайнов новые системные заметки выводятся в ленту сообщений тикета для информирования участников. В будущем релизе мы сделаем отображение статуса и количества обсуждений для дизайнов, чтобы дополнительно информировать пользователей о том, что происходит с дизайном.
Документация по управлению дизайном и оригинальный тикет.
Интеграция GitHub по умолчанию для статических имен проверки статуса
(PREMIUM, ULTIMATE, SILVER, GOLD) Стадия цикла DevOps: “Verify”
Мы изменили настройку по умолчанию для нашей интеграции с GitHub, чтобы использовать статические имена проверки статуса по умолчанию для новых проектов. Если на странице интеграции включена эта фича, к имени проверки статуса добавится имя хоста вашего инстанса GitLab, иначе (в случае динамических имен) добавится имя ветви. Это более осмысленная начальная настройка, которая гарантирует, что необходимые проверки статуса «из коробки» работают для пользователей, использующих GitLab CI/CD с репозиторием GitHub.
Документация по статическим и динамическим именам при проверке статуса и оригинальный тикет.
Выбор и перемещение нескольких карточек задач
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Plan”
Иногда важны мелочи. Независимо от того, начинаете ли вы свой следующий спринт или просто хотите провести время, перетаскивая задачи на досках задач, вы будете рады узнать, что теперь можно выбрать несколько карточек задач с помощью Cmd +click на Mac или Ctrl +click в Windows, чтобы переместить в другой список сразу несколько.
Документация по выбору нескольких карточек задач и оригинальный тикет.
Сортировка пакетов в интерфейсе реестра
(PREMIUM, ULTIMATE, SILVER, GOLD) Стадия цикла DevOps: “Package”
Реестр пакетов GitLab позволяет пользователям создавать, публиковать и делиться пакетами npm, Maven и (скоро) Conan. GitLab предоставляет пользовательский интерфейс, который отображает метаданные пакета и помогает пользователям находить пакеты своего проекта или группы. Однако до недавнего времени пользователям приходилось вручную прокручивать свой список пакетов, чтобы найти пакет, который они искали.
В GitLab 12.4 мы рады представить сортировку пакетов в пользовательском интерфейсе реестра для улучшения навигации и обнаружения! Теперь вы можете сортировать пакеты на уровне проекта и группы по дате создания, имени, версии и типу. В ближайших майлстоунах мы также добавим последний коммит и ветку и переделаем пользовательский интерфейс, чтобы включить все нужные метаданные.
Документация по реестру пакетов и оригинальный тикет.
Глобальный вид для развертываний и окружений кластера на уровне инстанса
(PREMIUM, ULTIMATE, SILVER, GOLD) Стадия цикла DevOps: “Configure”
Раздел Окружения (Environments) был представлен в GitLab 12.3 для кластеров на уровне группы. Этот раздел на странице кластера содержит обзор всех проектов, в которых используется данный кластер Kubernetes, включая окружения и развертывания, а также количество подов, используемых каждым окружением. Теперь в 12.4 вид «Окружения» доступен и для кластеров на уровне инстанса. Перейдите на страницу своего инстанса Kubernetes и выберите вкладку «Окружения». Для кластеров на уровне группы этот вид кластера был расширен до кластеров уровня инстанса.
Документация по окружениям и оригинальный тикет.
S/MIME теперь настраивается в GitLab Helm chart
(CORE, STARTER, PREMIUM, ULTIMATE)
Отправка сообщений по электронной почте с подписью S/MIME повышает безопасность за счет уменьшения возможности для фишинга, атаки «человек посередине» и других атак. В то время как возможность подписывать уведомления по электронной почте с помощью S/MIME была добавлена в Omnibus в 12.3, настроить S/MIME при установке GitLab на Kubernetes было нельзя. Теперь, в 12.4, параметры S/MIME для уведомлений от GitLab по электронной почте можно сконфигурировать как глобальную настройку для GitLab helm chart.
Документация по сертификатам S/MIME и оригинальный тикет.
Обновлено приложение менеджера сертификатов для Kubernetes при установке через интеграцию с Kubernetes
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Configure”
Обновление сертификатов безопасности для приложений, развернутых в Kubernetes, гарантирует безопасное и бесперебойное обслуживание ваших приложений. Начиная с GitLab 12.4, вы можете обновить приложение менеджера сертификатов, используя интеграцию GitLab с Kubernetes. Для обновления до последней версии, поддерживаемой GitLab, перейдите на страницу кластера в разделе Операции > Kubernetes, затем удалите и переустановите менеджер сертификатов.
Документация по менеджеру сертификатов и оригинальный тикет.
Подробные release notes и инструкции по обновлению/установке можно прочитать в оригинальном англоязычном посте: GitLab 12.4 released with improved Merge Request Dependencies and Audit API.
Над переводом с английского работали @cattidourden, @maryartkey, @ainoneko и @rishavant.
