Вышел GitLab 12.7 с конвейерами Parent-Child и бета-версией общих обработчиков заданий для Windows
Вышел релиз GitLab 12.7 — с улучшениями, которые помогут вашим командам и конвейерам (в русской локализации GitLab «сборочные линии») стать более эффективными и результативными. Настройка автоматизации и конвейеров — основа продуктивной работы команд DevOps, и в 12.7 мы предлагаем множество нововведений, которые сделают вашу работу быстрее и эффективнее. Например, конвейеры Parent-Child, группы ресурсов конвейера и бета-версию общих обработчиков заданий (shared runner) для Windows на GitLab.com.
Команды часто управляют работой через мерж-реквесты (в русской локализации GitLab «запросы на слияние»), поэтому новая аналитика ревью кода и более информативные виджеты мерж-реквеста облегчат оптимизацию качества кода и времени цикла разработки.
Более быстрые и эффективные конвейеры
Сложные конвейеры могут быть как медленными в обработке, так и трудными для восприятия. Конвейеры родитель-ребенок (parent-child) помогут ускорить время обработки благодаря параллельной работе отдельных дочерних конвейеров. Кроме того, за счет разделения и упрощения настройки и визуализации каждого конвейера, а также возможности создания переиспользуемой конфигурации с общим доступом, такие конвейеры будут проще в управлении и сделают ваш CI/CD (а значит, и вашу команду) более эффективными.
Управление общими ресурсами конвейера
Во многих компаниях есть общие окружения и ресурсы, одновременного изменения которых хотелось бы избежать. Группы ресурсов конвейера помогут вам ограничить параллельное выполнение конвейеров для более эффективного и действенного управления заданиями и ресурсами.
Бета-версия общих обработчиков заданий для Windows
Разработчики, работающие под Windows, теперь могут воспользоваться возможностями общих обработчиков заданий на GitLab.com, вместо того, чтобы настраивать свои собственные, или в дополнение к своим. Эта бета-версия позволит выполнять задания CI/CD на виртуальных машинах Windows со всей эффективностью полностью управляемого, автоматически масштабируемого и безопасного окружения, управляемого командой GitLab.com.
Более быстрое управление мерж-реквестами
Своевременное ревью кода поддерживает поставку кода вашей командой. Аналитика ревью кода облегчит поиск мерж-ревестов, которые требуют вмешательства, что поможет командам управлять временем цикла поставки ПО. Обновленные виджеты мерж-реквестов теперь показывают, когда изменения были внесены в определенное окружение, что сэкономит время на поиск последнего развертывания.
И это еще не все
Это — лишь некоторые из 45 новых и улучшенных фич и небольшая выборка из 1593 мерж-реквестов релиза 12.7, также было добавлено 12 улучшений производительности, которые вы можете посмотреть в блоге на сайте. Посмотрите также такие классные обновления, как автоматический staging всех изменений в нашей Web IDE и возможность поделиться групповым доступом с другой группой.
Приглашаем на наши встречи и просим заполнить опрос по релизу (на английском).
MVP этого месяца — Fabio Huser
Фабио внес несколько полезных улучшений в GitLab 12.7, включая кнопку удаления конвейера, возможность отключения автоматического закрытия задачи, настраиваемый шаблон сообщения коммита предложенных изменений в мерж-реквесте, визуализацию зависимостей при просмотре файла Rust Cargo.toml и конечную точку API для внешнего вида приложения.
Спасибо Fabio и всей команде Siemens!
Основные фичи релиза GitLab 12.7
Конвейеры parent-child
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Verify”
Сложные приложения часто требуют сложных конвейеров, которые могут становиться медленными и трудными для восприятия. С ростом сложности конвейеров, их отображение становится все более громоздким, конфигурация — более запутанной, а исполнение — более медленным. Когда это происходит, разделение сложных конвейеров на несколько конвейеров, организованных по принципу «родитель-ребенок» (parent-child), может повысить производительность и сделать конвейеры проще для осмысления: производительность можно улучшить, поскольку дочерние конвейеры могут работать одновременно, в то время как конфигурация и визуализация могут быть разделены на различные файлы или виды.
С релизом GitLab 12.7 вы можете задавать эти отдельные конвейеры с помощью разных YAML-файлов. Файл .gitlab-ci.yml остается основной точкой входа, но оттуда вы можете запустить любой другой YAML-файл из репозитория как собственный дочерний конвейер с обратной ссылкой на родителя. Также поддерживается использование include для облегчения повторного использования кода между различными конвейерами. Это может быть действительно удобно для монорепозиториев, где конфигурация каждого компонента в репозитории может разрабатываться и храниться отдельно, а все дочерние конвейеры могут работать параллельно — и даже встречаться в конце для совместного составления пакета и развертывания.
Документация по конвейерам «родитель-ребенок» и оригинальный тикет.
Бета-версия общих обработчиков заданий для Windows на GitLab.com
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Verify”
Мы рады сообщить о выпуске бета-версии общих обработчиков заданий для Windows от GitLab. Вы можете воспользоваться преимуществами полностью управляемого, автоматически масштабируемого и безопасного окружения для выполнения заданий CI/CD на виртуальных машинах под управлением Windows, размещенных на той же GCP-инфраструктуре, что и GitLab.com. Эти обработчики предварительно настроены для работы с различными программными пакетами, такими как менеджер пакетов Chocolatey для Windows, средства сборки Visual Studio 2019, Microsoft .Net Framework и многими другими.
Как и раньше, вы можете продолжать устанавливать и настраивать обработчики заданий в своей собственной инфраструктуре, чтобы использовать их вместе или вместо новых обработчиков от команды GitLab.
Дополнительную информацию о ценах, ограничениях и настройке, а также пошаговые инструкции по началу работы смотрите в нашем посте о запуске бета-версии обработчиков заданий для Windows.
Документация по использованию общих обработчиков заданий для Windows и оригинальный эпик.
Группы ресурсов конвейера
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Release”
Чаще всего пользователи хотят как можно больше распараллелить работу CI/CD, чтобы ускорить общее время выполнения. Однако, в некоторых случаях вы можете захотеть ограничить параллельный запуск. Например, если вы хотите предотвратить выполнение задания на другом конвейере в то же время на том же окружении. Хорошим примером будет физическое оборудование, такое как смартфон, компьютерный чип или встраиваемое IoT-устройство, которое используется для выполнения тестов перед широким выпуском программного обеспечения. Попытки запуска тестов с нескольких конвейеров, или даже нескольких заданий в одном конвейере в одно и то же время, могут привести к искажению данных, недействительным результатам тестирования или даже к блокировке устройства.
Теперь, с помощью групп ресурсов вы можете ограничить параллельность конвейера и заставить задания выполняться последовательно, зная, что ресурсы используются как предполагалось. Используя ключ resource_group в gitlab-ci.yml вы можете указать окружения, которые являются частью группы ресурсов для каждого задания, которое вы хотите ограничить. Когда задание запрашивает обработчик задач, а у ресурса уже запущено существующее задание, новое задание будет оставаться в очереди до тех пор, пока существующее не будет завершено. Вы даже можете указать несколько групп ресурсов для каждого задания. Например, у вас есть несколько IoT-устройств, которые вы тестируете, и вы хотите, чтобы тестовое задание выполнялось на любом одном устройстве в группе. Еще одним отличным применением будет использование Terraform для управления инфраструктурой как кодом, если вы действительно хотите быть уверены, что вносите только по одному изменению в данное окружение за раз.
Возможность ограничения параллельности конвейеров была очень востребованной фичей, и мы рады представить ее в этом релизе. Мы с нетерпением ждем ваших отзывов, предложений по улучшениям и успешных примеров использования.
Документация по группе ресурсов и оригинальный тикет.
Аналитика ревью кода
(STARTER, PREMIUM, ULTIMATE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Manage”
Ревью кода — настоятельно рекомендуемая часть любого процесса разработки программного обеспечения — проверка предложенных изменений коллегами и автоматизированными процессами перед отправкой в репозиторий. Но также это причина, по которой входящие изменения могут застопориться из-за пропущенной процедуры передачи, ушедшего в отпуск ключевого специалиста или из-за большого количества нерассмотренных изменений. Время цикла зависит от своевременного ревью кода и поддерживает поставку кода вашей командой.
Чтобы в ваших инстансах GitLab поддерживалась эта важная практика, мы с гордостью представляем вам аналитику ревью кода, которая будет выделять мерж-реквесты на рассмотрении.
Аналитика ревью начинает процесс ревью сразу, как только к мерж-реквесту был добавлен комментарий не от его автора, и отслеживает, как долго был открыт мерж-реквест после этого. В таблице такие мерж-реквесты отображаются по времени ревью в порядке убывания, поэтому будет легко найти мерж-реквесты, которые могут потребовать вмешательства или дальнейшего разделения.
Документация по аналитике ревью кода и оригинальный тикет.
Отображение времени развертывания мерж-реквеста
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Release”
Теперь виджет мерж-реквеста показывает имя окружения и время развертывания для каждого мерж-реквеста. Ранее нужно было вручную просматривать список коммитов и конвейеров для того, чтобы получить эту информацию. Отслеживая мерж-реквесты, разработчики смогут легко узнать, когда их изменения попали в определенное окружение.
Документация по мерж-реквестам и оригинальный тикет.
Другие улучшения в GitLab 12.7
Возможность поделиться групповым доступом с другой группой
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Manage”
Группы в GitLab могут использоваться для организации проектов и работы различных команд. Типичная схема использования — создать группы для инженеров, юристов и операторов и разделить доступ к соответствующим проектам для каждой группы.
Для больших инстансов с тысячами проектов довольно трудно вручную раздавать группам доступ к отдельным проектам. Чтобы упростить эту задачу, мы вводим возможность поделиться доступом группы с другой группой, тем самым устраняя необходимость делиться ссылками на отдельные проекты.
Документация по возможности поделиться групповым доступом и оригинальный тикет.
Фильтрация тикетов, мерж-реквестов, эпиков и досок задач с использованием ‘is not’ (!=)
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Plan”
Поиск именно тех тикетов, мерж-реквестов и эпиков (в русской локализации GitLab «цели»), которые вам нужны, может быть сложным — особенно когда вы хотите скрыть часть результатов. Теперь GitLab поддерживает исключение результатов при фильтрации тикетов, мерж-реквестов, эпиков и тикетов на досках задач при помощи оператора not или “is not” (!=).
Документация по фильтрации списков тикетов и мерж-реквестов и оригинальный тикет.
Просмотр предыдущих ревизий файлов в Blame
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Create”
Blame позволяет проследить историю файла построчно и проверить каждый коммит. С GitLab 12.7 вы можете легко отследить историю конкретной строки, используя новую кнопку под названием Просмотр blame до этого изменения (View blame prior to this change).
Спасибо Hiroyuki Sato за этот вклад!
Документация по blame и оригинальный тикет.
Настройка версии pip в сканировании зависимостей
(ULTIMATE, GOLD) Стадия цикла DevOps: “Secure”
Начиная с GitLab 12.7 вы можете установить нужную версию pip в сканировании зависимостей с помощью переменной DS_PIP_VERSION. Когда переменная будет задана, она будет передана в анализаторы сканирования зависимостей.
Документация по переменным в сканировании зависимостей и оригинальный тикет.
Аудит событий в релизах
(STARTER, PREMIUM, ULTIMATE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Release”
В качестве следующего шага в развитии релизов GitLab мы упрощаем работу с аудитом, автоматически включая события по созданию и редактированию релизов, загрузке артефактов, а также ассоциированию или откреплению майлстоуна (в русской локализации GitLab «этап») в лог аудита GitLab.
Документация по аудиту событий проекта и оригинальный тикет.
Обновления репозитория Conan через CI/CD
(PREMIUM, ULTIMATE, SILVER, GOLD) Стадия цикла DevOps: “Package”
Недавно мы запустили репозиторий GitLab Conan, чтобы поддержать разработчиков C/C++ в публикации и скачивании зависимостей. Однако, для того, чтобы использовать GitLab CI/CD, им приходилось использовать свои имя пользователя и пароль. Это неэффективно и представляет потенциальную угрозу безопасности.
В GitLab 12.7 мы с радостью объявляем, что теперь пользователи смогут использовать предопределенную переменную окружения CI_JOB_TOKEN для аутентификации в своем репозитории Conan. Это позволит им с легкостью публиковать и устанавливать свои зависимости.
Документация по использованию GitLab CI с пакетами Conan и оригинальный тикет.
Запрет на изменение имени пользователя в профиле
(PREMIUM, ULTIMATE) Стадия цикла DevOps: “Manage”
Администраторы теперь смогут запрещать пользователям изменять имя в профиле, чтобы иметь возможность отслеживать все действия пользователя. Этот дополнительный контроль даст возможность организациям, нацеленным на безопасность, следить за тем, чтобы работа в GitLab соответствовала их внутренней политике по отслеживаемому входу и верификации пользователей.
Это фича работает на уровне инстанса, и требует доступа администратора. Сейчас она доступна только для самоуправляемых инстансов. Здесь вы можете следить за этим тикетом, сделать свой вклад в разработку и принять участие в обсуждении о том, нужно ли подключить эту фичу на GitLab.com в будущих релизах.
Документация по запрету на изменение имени пользователя в профиле и оригинальный тикет.
API для получения мерж-реквестов из определенного развертывания
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Release”
Мы добавили поддержку API, через который можно получить список мерж-реквестов, связанных с данным развертыванием. Это полезно, если нужно узнать, когда мерж-реквест был добавлен к определенному окружению.
Документация по списку мерж-реквестов, связанных с развертыванием и оригинальный тикет.
Руководство по инкрементным развертываниям через GitLab CI/CD
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Release”
При добавлении новых изменений в приложение у вас есть возможность применять изменения только к части подов Kubernetes в качестве стратегии по управлению рисками. Добавляя изменения постепенно, можно отслеживать уровень ошибок и спад производительности и обновлять все поды, если проблем не возникает. GitLab поддерживает как ручные, так и автоматические инкрементные развертывания в системе продакшена Kubernetes для приложений с непрерывной поставкой и приложений с непрерывным развертыванием. Они уже доступны в проектах Auto DevOps. Мы подготовили новое руководство, в котором можно узнать, как добиться того же результата, используя только GitLab CI/CD.
Документация по инкрементным развертываниям и оригинальный тикет.
Управление переключаемыми фичами напрямую из списка
(PREMIUM, ULTIMATE, SILVER, GOLD) Стадия цикла DevOps: “Release”
Переключаемые фичи — это возможность активировать и деактивировать новые фичи в окружении, чтобы уменьшить риск того, что ваше приложение сломается, пока они полностью не протестированы. Теперь вы сможете удобно включать или выключать фичи напрямую из списка фич. Ранее это можно было делать только через API.
Документация по переключаемым фичам и оригинальный тикет.
Игнорирование ошибок Sentry в GitLab
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Monitor”
Когда ошибок много, и все они требуют внимания, их сортировка может занимать много времени, потому что приходится копаться в куче мусора, чтобы найти те ошибки, которые нужно срочно исправить. Возможность игнорировать ошибки при использовании GitLab позволяет отбросить некритичные ошибки, и сфокусироваться на важных. Это упрощает сортировку и просмотр списка ошибок. Вы найдете кнопку Игнорировать (Ignore) на странице подробного описания ошибки.
Документация по игнорированию ошибок и оригинальный тикет.
Настройка сообщения коммита для применяемых предложений
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Create”
Предложение изменений в мерж-реквестах упрощает добавление улучшений к проекту. Однако, если вы используете правило пуша для определенного формата сообщений коммита, то ранее в большинстве случаев вы не могли применить предлагаемое изменение, потому что сообщение коммита, генерируемое GitLab, не подходило под шаблон.
GitLab 12.7 теперь поддерживает настройку шаблона сообщения коммита для коммитов, создаваемых GitLab при применении предлагаемого изменения, чтобы они соответствовали правилу.
Спасибо Fabio Huser и Siemens за эту фичу!
Документация по настройке сообщения коммита и оригинальный тикет.
Автоматическая ссылка на пакеты Rust
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Create”
При изучении проекта бывает полезно посмотреть на его зависимости, но, как правило, они хранятся в автоматически сгенерированных файлах, которые ссылаются на публичный реестр пакетов.
Теперь при просмотре файла зависимостей Cargo.toml проекта Rust GitLab будет автоматически обнаруживать пакеты и добавлять ссылки на crates.io, чтобы просматривать зависимости было проще. Ранее, в GitLab 9.3 была добавлена поддержка для Go, Ruby, Node.js, Python, PHP и Objective-C.
Спасибо Fabio Huser и Siemens за эту фичу!
Поиск ключей SSH и ключей развертывания по отпечаткам MD5 и SHA-256
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Manage”
С тех пор как OpenSSH в 2015 году перешел на SHA-256 по умолчанию, показывать хэш для ключей SSH в формате MD5 стало никому не нужно. Благодаря вкладу сообщества теперь вы сможете видеть отпечаток SHA-256 как для ключей SSH, так и для ключей развертывания, а также стал доступен запрос пользователя по отпечатку ключа. Все благодаря новому API.
Спасибо Roger Meier (@bufferoverflow) за эту фичу!
Документация по запросу пользователя по отпечатку ключа и оригинальный тикет.
Дублирование панели метрик
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Monitor”
GitLab «из коробки» поставляется с набором полезных панелей метрик для мониторинга состояния вашего приложения. В релизе 12.7 вы сможете легко дублировать одну из этих панелей, созданных по умолчанию, чтобы добавлять какие-либо изменения, например, бизнес-метрику или специфическую систему метрик вашего приложения.
Документация по дублированию панели метрик GitLab и оригинальный тикет.
Обязательный вход в аккаунт для доступа к GitLab Pages
(CORE, STARTER, PREMIUM, ULTIMATE) Стадия цикла DevOps: “Release”
В GitLab Pages теперь есть возможность отключать неавторизованный доступ независимо от настроек приватности проекта. При этом все пользователи должны будут входить в аккаунт для получения доступа к сайту, даже если проект является публичным. Администратор GitLab может включить эту настройку в чекбоксе на странице настроек администратора для GitLab Pages.
Документация по отключению публичного доступа к страницам и оригинальный тикет.
Информация о языке и о срочности на странице ошибки Sentry
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Monitor”
Иногда сортировать ошибки бывает непросто, потому что все они бросаются в глаза и среди них сложно найти нужную информацию. Страница с подробной информацией об ошибке в GitLab показывает наиболее значимые атрибуты ошибки. С версии GitLab 12.7 эти атрибуты также будут включать язык и срочность, что поможет как можно быстрее определять причину возникновения ошибки.
Документация по странице с информацией об ошибке и оригинальный тикет.
Поддержка Elasticsearch 7.x
(STARTER, PREMIUM, ULTIMATE) “Enablement”
В GitLab 12.7 мы обновили зависимости в нашем индексаторе и в GitLab, чтобы добавить поддержку Elasticsearch 7.x к уже существующей поддержке для Elasticsearch 6.x. Это самая запрашиваемая фича для нашей интеграции Elasticsearch, поэтому мы очень рады добавить ее в этом релизе.
Помимо поддержки Elasticsearch 7.x мы также добавляем версию 2.0.0 нашего индексатора, который официально обеспечивает эту поддержку. Как мы упоминали ранее, Elasticsearch 5.6.x больше не поддерживается в GitLab.
Документация по версиям Elasticsearch и оригинальный тикет.
Путь API к списку всех сервисов проекта
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) “Enablement”
Новый путь для API доступен в /projects/:id/services. Он позволяет получить список всех активных сервисов для данного проекта. Ранее в API GitLab были пути, по которым можно было создавать, редактировать и удалять сервисы, но не было пути, по которому можно было найти список этих сервисов.
Возможность получить список активных сервисов облегчит программное добавление и редактирование сервисов проектов через API.
Документация по списку сервисов, оригинальный тикет и оригинальный мерж-реквест.
Улучшения для GitLab chart
(CORE, STARTER, PREMIUM, ULTIMATE)
- Появилась документация по добавлению GitLab ко внешнему инстансу Minio для хранения объектов.
- GitLab chart больше не управляет жизненным циклом оператора GitLab CRD (Kubernetes Custom Resource Definition). Установка CRD теперь может выполняться напрямую через команду
kubectl. Новые инструкции по установке CRD можно посмотреть в документации по установке GitLab Operator. - Флаг для отключения
gitalyбыл перемещен в глобальные настройки, так что теперь для отключения Gitaly вам больше не придется изменять настройки нескольких сервисов. Новые инструкции по отключению Gitaly для использования внешнего сервиса Gitaly можно найти в разделе «Настроить chart через внешний сервис Gitaly».
Парсинг и анализ активности в инстансе через структурированный лог приложений
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Manage”
Система логирования GitLab позволяет администраторам отслеживать и анализировать файлы логов, чтобы лучше понимать состояние инстанса. Логи имеют много сценариев использования, включая отслеживание производительности, аналитику и аудит системы.
Однако, некоторые логи доступны только в неструктурированном формате, из-за чего их сложно парсить. Одним из этих логов был лог приложений application.log, который записывал активность приложений, включая события проекта, группы и пользователей. В версии 12.7 мы добавили более гибкую систему логирования в GitLab, а также версию application.log в формате JSON в виде файла application_json.log.
Создание структурированной версии этого файла открывает несколько интересных сценариев использования, таких как введение инструмента отслеживания для аудита событий, отправка этих событий в инструмент визуализации для построения пользовательских панелей и многое другое.
Документация по логу приложений в формате JSON и оригинальный тикет.
Создание тикетов со страницы эпика
(ULTIMATE, GOLD) Стадия цикла DevOps: “Plan”
Больше не нужно переключаться между несколькими вкладками, чтобы создать тикет и прикрепить его к эпику! Теперь вы сможете создавать тикеты напрямую со страницы эпика.
Документация по созданию тикетов со страницы эпика и оригинальный тикет.
Упрощенное создание таблицы в Markdown
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Plan”
Перенос табличных данных в Markdown может быть долгим и трудоемким процессом. В версии GitLab 12.7 вы сможете копировать данные из таблицы и вставлять их прямо в редактор Markdown в GitLab. Автоматическое преобразование таблицы в рабочий синтаксис Markdown позволяет вам тратить меньше времени на форматирование и больше времени на создание крутых проектов.
Документация по созданию таблицы в Markdown и оригинальный тикет.
Все изменения в Web IDE автоматически подготавливаются к коммиту
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Create”
Web IDE в GitLab — отличный инструмент для внесения изменений в проект. Тем не менее, отсутствие постоянной файловой системы может стать проблемой. Могут возникнуть ситуации, когда пользователи вносили изменения в несколько файлов, но не все изменения были отмечены как подготовленные к коммиту (staged) или были закоммичены до перехода на другую страницу. Такие изменения могут быть потеряны.
Чтобы сделать Web IDE более доступной для пользователей и предотвратить случайные потери, изменения в Web IDE теперь будут автоматически отмечены как подготовленные к коммиту. С этого релиза, когда пользователь нажимает Commit, вместо подготовки изменений к коммиту следующий экран коммита позволит ему добавить свое описание коммита и выбрать нужную ветку.
Документация по коммитам и оригинальный тикет.
Удаление конвейера через пользовательский интерфейс
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Verify”
Раньше удаление конвейера было возможно только через API. Начиная с 12.7 пользователи с правами владельца на проект могут использовать новую кнопку Удалить (Delete), чтобы удалить конкретный конвейер непосредственно на странице сведений о конвейере. Это необратимое действие инвалидирует кэши конвейера и удаляет все связанные объекты (сборки, логи, артефакты и триггеры).
Ключевым преимуществом возможности удаления конвейера через пользовательский интерфейс является возможность незамедлительных действий по защите при утечке секретов, если выяснилось, что задание в конвейере хранит приватные ключи в открытом виде. И еще более общий случай использования удаления конвейеров — это необходимость очистки запутанной истории CI, замусоренной неуспешно завершенными конвейерами, возникшими в результате попыток настроить CI или экспериментов. Дополнительным преимуществом очистки является гарантия того, что нежелательные конвейеры не будут случайно переиспользованы.
Документация по удалению отдельных конвейеров и оригинальный тикет.
Увеличение масштаба для дизайнов при их просмотре
(PREMIUM, ULTIMATE, SILVER, GOLD) Стадия цикла DevOps: “Create”
При загрузке большого изображения, например широкоэкранного макета веб-сайта, на вкладку Дизайны (Designs) в тикете, было трудно увидеть детали изображения, потому что оно отображалось как картинка фиксированной ширины. Теперь мы добавляем возможность увеличения масштаба в дизайне, так что вы можете увидеть все подробности. Вы найдете элементы управления масштабированием в нижней части изображения.
Документация по увеличению масштаба при просмотре дизайнов и оригинальный тикет.
Auto DevOps не запускается, если нет файла Dockerfile или соответствующего пакета сборки
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Configure”
Auto DevOps — отличный способ начать работу с современными методами DevOps для любого проекта. Однако до настоящего времени Auto DevOps требовалось запускать конвейер конфигурации для определения совместимости с проектом, проверяя, существует ли для проекта Dockerfile или соответствующий пакет сборки.
Для повышения эффективности и использования новой функции workflow:rules в GitLab CI, Auto DevOps будет запускаться только в том случае, если проект содержит Dockerfile или если для языка проекта существует соответствующий пакет сборки.
Документация по Auto DevOps и оригинальный тикет.
Установка приложений Kubernetes с использованием шаблонов CI
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Configure”
Установка приложений Kubernetes с помощью GitLab CI предоставляет отличный способ настройки Helm charts и пользовательских ресурсов (CRDs) перед установкой. В рамках этого релиза мы добавили шаблоны для установки менеджера сертификатов и обработчика заданий GitLab с помощью GitLab CI. Установка обработчика заданий GitLab через GitLab CI с помощью helm chart позволяет пользователям настраивать параметры, недоступные для них раньше, например количество одновременных заданий или интервал проверки заданий.
Документация по установке через GitLab CI (альфа-версия) и оригинальный тикет.
Создание шаблонов для ответов по электронной почте из службы поддержки
(PREMIUM, ULTIMATE, SILVER, GOLD) Стадия цикла DevOps: “Plan”
Ответы службы поддержки (Service Desk) по электронной почте теперь можно настроить для вашей организации. Просто добавьте файлы шаблонов в формате Markdown в свой репозиторий. Когда служба поддержки отвечает пользователю, шаблоны используются автоматически. Это позволит настраивать брендинг и обмен сообщениями для улучшения работы с пользователями.
Документация по настройке почтовых шаблонов и оригинальный тикет.
Geo поддерживает репликацию ресурсов управления дизайном
(PREMIUM, ULTIMATE) “Enablement”
Панель управления дизайном позволяет пользователям загружать ресурсы дизайна (например, макеты) в тикеты GitLab и хранить их в одном месте.
GitLab Geo теперь поддерживает репликацию этих ресурсов управления дизайном на вторичные ноды, гарантируя, что распределенные команды могут получить к ним доступ из ближайшей ноды Geo. Поскольку ресурсы управления дизайном реплицируются, их также можно восстановить из вторичной ноды.
Мы пока не поддерживаем проверку этих ресурсов и добавим поддержку в следующем релизе.
Документация по репликации Geo и оригинальный эпик.
Добавили пользовательский шаблон ко входящим тикетам службы поддержки
(PREMIUM, ULTIMATE, SILVER, GOLD) Стадия цикла DevOps: “Plan”
Служба поддержки позволяет создавать новые тикеты, отправив электронное письмо на уникальный адрес. При создании этих новых тикетов было бы полезно, если бы они могли автоматически назначаться конкретному пользователю, получать метку или привязываться к майлстоуну. Теперь это можно сделать, создав шаблон, подключаемый ко всем новым тикетам службы поддержки. Включите любое из быстрых действий в шаблон, и они сработают при создании тикета.
Документация по настройке службы поддержки и оригинальный тикет.
API для внешнего вида
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Manage”
Теперь вы можете настроить с помощью нового API параметры внешнего вида вашего инстанса, включая такие атрибуты, как заголовок, описание, значок favicon, логотип.
Спасибо Fabio Huser и Siemens за эту фичу!
Документация по настройке внешнего вида и оригинальный тикет.
Ссылка на коммит GitLab на странице сведений об ошибке Sentry
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Monitor”
Разбираться в трассировке стека и так достаточно сложно, чтобы еще и искать, какая версия повлияла на исследуемый файл. В GitLab 12.7 коммит, который, скорее всего, вызвал ошибку, автоматически отображается на странице сведений об ошибке. Возможность автоматически связать коммит с ошибкой, которую вы видите, может значительно сократить время исправления ошибки. Это дает возможность немедленно откатить изменение или исправить его с помощью патча.
Обратите внимание, что для того, чтобы воспользоваться этой функцией, вам нужно именовать объекты в релиз Sentry с помощью хэша SHA развертываемого коммита.
Документация по отслеживанию ошибок и оригинальный тикет.
Улучшена подсветка различий в предложениях для мерж-реквестов
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Create”
Предложение улучшений в мерж-реквесте с использованием фичи предложенного изменения (Suggested Change) облегчает совместную работу, так как одним щелчком мыши можно сразу применить изменения и завершить обсуждение.
В GitLab 12.7 улучшенная подсветка предлагаемых изменений ясно показывает, какие слова и символы изменились, так что вы можете уверенно принимать предложение.
Документация по предложенным изменениям и оригинальный тикет.
Возможность отключить автоматическое закрытие тикетов из мерж-реквестов
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Plan”
У каждой команды свои потребности. Часто нужно оставить тикет открытым за пределами жизненного цикла одного мерж-реквеста или сослаться на тикет в коммите, не закрывая его.
До этого релиза у команд не было возможности отключить автоматическое закрытие тикета при его упоминании в мерж-реквесте или коммите. Чтобы предоставить командам более детальный контроль над этой функциональностью, мы добавили возможность отключить автоматическое закрытие тикетов в настройках проекта.
Спасибо Fabio Huser и команде Siemens!
Документация по отключению автоматического закрытия тикетов и оригинальный тикет.
Разрешение ошибок Sentry в GitLab
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Monitor”
Вот вы определили основную причину ошибки, пофиксили и проверили, что все работает (не выходя из GitLab). С GitLab 12.7 можно отметить ошибку как устраненную одним нажатием кнопки, не переключаясь на Sentry. Кнопка Разрешить (Resolve) находится на странице сведений об ошибке.
Документация по отслеживанию и разрешению ошибок и оригинальный тикет.
Улучшено начальное время отклика для конечной точки API /projects
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) “Enablement”
В GitLab 12.7 мы значительно улучшили время отклика первой страницы API /projects. Ранее для некоторых комбинаций параметров мы видели, как время отклика на GitLab.com достигает 30 секунд. С этими изменениями большинство ответов будет в течение одной секунды. Обратите внимание, что эти улучшения применяются независимо от используемой стратегии разбиения на страницы.
Ускорили конечную точку API /projects при разбиении на страницы по наборам ключей
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) “Enablement”
Мы ввели новый механизм разбиения на страницы для конечной точки API /projects. Ранее основанная на смещении нумерация страниц была единственным доступным методом, который хоть и предоставлял гибкие параметры сортировки и фильтрации, но работал все хуже для каждой следующей страницы. Эта низкая производительность приводила к увеличению нагрузки на сервер GitLab, а также к увеличению времени отклика.
В GitLab 12.7 мы вводим разбиение на страницы на основе набора ключей. Хотя этот метод допускает сортировку только на основе идентификатора проекта, он работает значительно лучше, со стабильно быстрым ответом независимо от того, какую страницу вы запрашиваете. Использование такого способа для запросов, извлекающих много страниц, уменьшит нагрузку на сервер GitLab и приведет к более быстрому извлечению данных.
В 12.10 мы реализуем настраиваемый предел глубины страницы для нумерации страниц на основе смещения с максимальной глубиной 10 000 записей. Этот предел будет применен к GitLab.com в релизе 12.10.
Документация по разбиению на страницы на основе набора ключей и оригинальный тикет.
Разрешить пропуск CI при выполнении rebase через API
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Verify”
Раньше было возможно пропустить создание конвейера CI при использовании ci skip (или skip ci) в описании вашего коммита или с помощью настроек пуша, но не было возможности пропустить CI при выполнении rebase. Начиная с 12.7 это можно сделать при использовании API rebase.
Документация по rebase при мерж-реквестах и оригинальный тикет.
Выпущен GitLab Chart 3.0
(CORE, STARTER, PREMIUM, ULTIMATE) “Enablement”
GitLab Chart 3.0, выпущенный вместе с GitLab 12.7, является новой мажорной версией GitLab Helm Chart. Из-за существенных изменений в этой версии для обновления нужно будет сделать несколько дополнительных шагов, которые описаны в документации по обновлению. Версия 3.0 включает в себя функциональные улучшения и обновления ряда компонентов, каждое из которых изложено ниже и связано с эпиком GitLab Chart 3.0.
-
GitLab Chart использует форк nginx-ingress chart. В GitLab Chart 3.0 подтянуты изменения, внесенные в вышестоящий chart nginx-ingress, чтобы обеспечить совместимость GitLab с Helm 2.15.0 и Helm 3.
-
Версии API
extensions/*иapps/beta*перестали поддерживаться в Kubernetes 1.16. Несколько вышестоящих чартов, используемых GitLab, обновились, чтобы не использовать эти версии API. GitLab chart 3.0 включает в себя обновленные вышестоящие чарты: Prometheus chart9.4.x, PostgreSQL chart7.7.0и Redis chart10.3.x(теперь не форк). -
В развертываниях Sidekiq теперь используются уникальные селекторы, чтобы избежать путаницы с тем, какие развертывания владеют подами Sidekiq при создании нескольких развертываний. Для получения важной информации об обновлении развертываний Sidekiq обратитесь к документации по обновлению.
Документация по GitLab Chart и оригинальный эпик.
Подробные release notes и инструкции по обновлению/установке можно прочитать в оригинальном англоязычном посте: GitLab 12.7 released with Parent-Child Pipelines and Windows Shared Runners Beta.
Над переводом с английского работали @cattidourden, @maryartkey, @ainoneko и @rishavant.
