nAbdullin 30 авг 2019 в 17:51

GitLab 12.2: направленные ациклические графы для пайплайнов и управление дизайном

17 мин

6.8K

Блог компании СлёрмDevOps*Серверное администрирование*Системное администрирование*

Перевод

Потрясающий выпуск GitLab 12.2 поможет командам оптимизировать пайплайны, расширить возможности совместной работы и управлять взаимозависимостями между проектами. Подробности ниже.

Более быстрые и гибкие пайплайны

Пайплайны CI нужны для автоматизации задач сборки и тестирования, чтобы ускорить поставку ПО и избежать ошибок, присущих обработке вручную. Но в некоторых случаях эффективность пайплайнов GitLab CI/CD далека от идеала. GitLab 12.2 теперь поддерживает направленные ациклические графы (DAG), чтобы создавать зависимости детализированных заданий и управлять ими, а не полагаться на последовательные этапы. Это суперэффективный инструмент, с которым ваши пайплайны CI станут работать быстрее и продуктивнее.

Управление дизайном

Разработка ПО — это командный спорт, и мы хотим сделать его доступным для всех. В выпуске 12.2 мы предлагаем новые возможности, чтобы включить дизайнеров и управление дизайном в GitLab. Управление дизайном упростит отправку, контроль версий и совместную работу над артефактами дизайна, чтобы работа команд стала еще эффективнее благодаря единому источнику истины.

Мы только начинаем работать над дизайнерскими рабочими процессами на GitLab и будем рады, если вы внесете свой вклад в нашу стратегию управления дизайном.

Зависимости мердж-реквестов между проектами

В сложных системах часто бывает несколько проектов со взаимозависимостями между изменениями кода, где важно, в каком порядке применяются изменения. Теперь GitLab поддерживает зависимости мердж-реквестов между проектами, чтобы определять отношения зависимостей и предотвращать ошибки, связанные с применением изменений в неправильном порядке. Чем меньше ошибок, тем меньше приходится переделывать и тем быстрее можно развертывать изменения.

И это еще не все!

В GitLab 12.2 столько классных фич, что обо всех рассказать просто невозможно. Ограничение членства в группах по доменам, cтратегия развертывания по процентам и идентификаторам пользователя для переключателей функции, одобрение безопасности в мердж-реквестах и теперь переменные среды с областью действия включаются в версию Core. Читайте дальше и узнаете больше о каждой фиче.

Самый ценный сотрудник этого месяца (MVP) — Фабио Папа (Fabio Papa)

Благодаря Фабио в GitLab 12.2 появился новый параметр, с которым не только владельцы, но и мейнтейнеры могут создавать подгруппы. А еще Фабио внес ценный вклад в выпуски GitLab 12.0 и GitLab 11.10.

Спасибо, Фабио!

Главные фичи GitLab 12.2

Направленные ациклические графы для пайплайнов GitLab

CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD

В простом пайплайне все задания на одном этапе должны выполняться до перехода на следующий этап. Во многих пайплайнах нужно пройти все тесты до деплоя. Но в более сложных пайплайнах иногда хочется, чтобы задания на одном этапе начинались до завершения предыдущего этапа. Например, проект создает приложения для Android и iOS в многоэтапном пайплайне. Скорее всего, вы захотите, чтобы развертывание приложений iOS началось сразу после прохождения тестов для iOS, чтобы не ждать, пока будут пройдены все тесты для Android. Общее время вычисления будет таким же, а физическое время будет отличаться. Чтобы упростить работу в таких случаях и дать вам эффективный и гибкий инструмент для определения сложных пайплайнов, мы добавили ключевое слово needs:, которое определяет отношения между заданиями в .gitlab-ci.yml. С ключевым словом needs можно указать, что одно задание должно обязательно выполняться после другого. Когда первое задание будет выполнено, зависящее от него задание на следующем этапе сразу начнет выполняться, не дожидаясь остальных заданий на предыдущем этапе. Внутри GitLab мы реализовали эту функцию с помощью направленного ациклического графа. По сути, когда GitLab создает пайплайн из вашей конфигурации, он использует сложный набор правил, чтобы определить последовательность заданий, а не просто приступать к выполнению заданий на одном этапе только после завершения предыдущего. Во-первых, пайплайн выполняется эффективнее, а во-вторых на базе этого можно внедрить и другие расширенные возможности. Используйте ключевое слово needs уже сегодня, чтобы создавать пайплайны, как в примере выше, или применяйте его в интересных новых сценариях монорепозиториев, когда несколько несвязанных между собой служб хранятся в одном репозитории и не должны ждать друг друга.

Аннотации к дизайнам

PREMIUM, ULTIMATE, SILVER, GOLD

С помощью аннотаций к дизайнам дизайнеры и разработчики могут вместе работать над дизайнами, оставляя комментарии по разным аспектам. Разрешая дизайны в задачах в поддержку этого сотрудничества, мы продолжаем совершенствовать задачи как единый источник истины на GitLab. В то же время мы предоставляем структуру для фидбэков и обсуждения дизайнов.

Мы только начинаем работать над дизайнерскими рабочими процессами на GitLab и будем рады, если вы внесете свой вклад в нашу стратегию.

Сейчас управление дизайном на стадии альфа и может меняться в любое время без предварительного уведомления. Для управления дизайном нужно включить Large File Storage (LFS).

Зависимости мердж-реквестов между проектами

PREMIUM, ULTIMATE, SILVER, GOLD

Компании, которые выпускают несколько связанных продуктов, часто используют общие сервисы и библиотеки, чтобы не решать одну проблему дважды. Обычно они хранятся в отдельных проектах, но в этом случае сложно координировать изменения между сервисами и их потребителями, если нужно изменить функцию в нескольких компонентах.

В GitLab 12.2 зависимости мердж-реквестов между проектами позволяют определять отношения зависимостей, чтобы изменения не применялись в неправильном порядке. А еще эти отношения удобно просматривать в ревью кода, чтобы ревьюерам было проще разобраться во всех изменениях.

Ограничение членства в группах по доменам

PREMIUM, ULTIMATE, SILVER, GOLD

Для организаций, заботящихся о безопасности, очень важно контролировать доступ к проектам и группам для управления рисками. В выпуске 12.2 мы добавляем для администраторов и владельцев групп дополнительный инструмент контроля прав доступа. Теперь вы можете предоставлять членство в группах только пользователям с адресом электронной почты в указанном домене.

Это означает, что в компании YourCompany в группу можно включить только пользователей с адресами yourcompany.com, и владельцы не смогут случайно добавить посторонних пользователей.

Стратегия развертывания по процентам для переключателей функций

PREMIUM, ULTIMATE, SILVER, GOLD

Теперь можно выбрать стратегию развертывания по процентам для переключателей функций. При развертывании по процентам можно индивидуально задавать процент для каждой среды и каждого переключателя. Когда развертывание по процентам настроено и переключатель включен, функция будет показана настроенному проценту залогиненных пользователей. Это позволяет выполнять контролируемые развертывания и отслеживать поведение целевой среды, чтобы получить ожидаемые результаты.

Стратегия развертывания по идентификаторам пользователей для переключателей функций

PREMIUM, ULTIMATE, SILVER, GOLD

Теперь можно выбрать стратегию развертывания по идентификаторам пользователей для переключателей функций. Такая стратегия позволяет указывать список идентификаторов пользователей через запятую, а затем включать функцию только для некоторых пользователей. А еще можно тестировать функции только на некоторых группах или сегментах базы пользователей.

Утверждение безопасности в мердж-реквестах

ULTIMATE, GOLD

Теперь можно гарантировать, что мердж-реквесты, которые вводят новые уязвимости, не будут применяться, пока ответственные лица не просмотрят и не утвердят изменение.

Так вам и вашим командам будет проще соблюдать требования и политики, и новые уязвимости не смогут случайно просочиться в базу кода.

Указание переменных при запуске задания вручную

CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD

Теперь при запуске задания вручную можно переопределять или предоставлять новые переменные, которые задание будет использовать. Так будет гораздо проще настраивать пользовательские или многоразовые задания в пайплайнах, а еще устранять неисправности при исполнении заданий.

Переменные среды с областью действия теперь доступны в Core

CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD*

Возможность ограничивать переменные среды определенной областью появилась в GitLab Premium 9.4, а теперь доступна и для GitLab Core. Эта фича предоставляет гибкость при настройке различных переменных (например, разные закрытые ключи для доступа к разным инфраструктурам в средах) и использовании нескольких сред в жизненном цикле разработки.
Мы открываем исходный код этой фичи в соответствии с нашим разделением на уровни по типу покупателя, чтобы все могли пользоваться ей и участвовать в ее развитии.

Другие улучшения в GitLab 12.2

Реестр NPM теперь поддерживает аутентификацию с персональным токеном доступа GitLab

PREMIUM, ULTIMATE, SILVER, GOLD

Реестр GitLab NPM позволяет разработчикам Javascript собирать, публиковать и версионировать пакеты NPM с помощью своего экземпляра GitLab. NPM требует аутентификацию с OAuth, и до выпуска 12.2 персональный токен доступа GitLab не поддерживал OAuth. Пользователям приходилось создавать собственный токен (за пределами GitLab), чтобы использовать реестр NPM, и невозможно было использовать двухфакторную аутентификацию. Это решение не масштабировалось для корпоративных клиентов.

Рады сообщить, что в выпуске 12.2 мы поддерживаем аутентификацию с персональным токеном доступа GitLab. Персональный токен доступа GitLab работает с двухфакторной проверкой подлинности и позволяет пользователям выбирать область и политику срока годности. Просто добавьте в файл .nprmrc свой персональный токен доступа и войдите в реестр GitLab NPM, чтобы публиковать и загружать пакеты.

Список пользователей, отметивших проект звездой

CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD

Чтобы следить за достойными внимания проектами, можно отметить их звездой. Благодаря вкладу сообщества теперь можно просматривать список пользователей, которые отметили определенный проект. Для этого нужно нажать на количество таких пользователей на странице проекта. Список также доступен в Projects API.

Отмеченные проекты можно просмотреть в профиле пользователя.

Спасибо за вклад, Камил Стэпс (Camil Staps)!

Мейнтейнеры могут создавать подгруппы

CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD

В крупных организациях, которым нужна гибкость, подгруппы помогают поддерживать порядок в разрастающемся экземпляре. Теперь владельцы могут разрешать мейнтейнерам создавать подгруппы. С этой опцией мейнтейнеры в группе смогут действовать быстро и независимо, не обращаясь за помощью к владельцам группы.

Спасибо за вклад, Фабио Папа (Fabio Papa)!

Новые опции push для мердж-реквестов

CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD

GitLab уже поддерживает открытие мердж-реквестов и настройку их применения после успешного завершения пайплайна — и все в команде Git push. Теперь применять небольшие изменения можно быстро и просто.

В выпуске GitLab 12.2 появились новые параметры push:

Настройка удаления ветки после слияния.
Изменение заголовка мердж-реквеста.
Изменение описания мердж-реквеста.

Улучшенное развертывание дифф-файла

CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD

При просмотре дифф-файла большинство строк без изменений скрыто, чтобы изменения были сразу видны. Но иногда нужно больше контекста.

В GitLab 12.2 скрытые диапазоны строк можно открывать полностью или постепенно. Раньше скрытые диапазоны строк можно было открывать только постепенно, снизу диапазона.

Пакетное редактирование ярлыков задач на групповом уровне

PREMIUM, ULTIMATE, SILVER, GOLD

Пользователи могут менять ярлыки многих задач одновременно в одном проекте. В GitLab 12.2 появилась возможность пакетного редактирования ярлыков для многих задач на уровне группы, чтобы ярлыками было проще управлять.

Назначение групп в качестве владельцев кода

STARTER, PREMIUM, ULTIMATE, BRONZE, SILVERGOLD

Часто неочевидно, кто должен проверять изменения. Будет проще, если назначать владельцев кода файлам. После назначения вы видите владельцев при просмотре файла и автоматически добавляете их как утверждающих для мердж-реквестов.
В GitLab 12.2 теперь можно назначать владельцами кода целые группы, а не только пользователей по имени на GitLab и электронной почте. Если назначить группу, владельцы кода не отстанут в случае изменений команды, особенно при использовании LDAP для управления членством в группах.

Git Blame API

CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD

Полезно знать, кто последним изменил строку кода и почему, чтобы вносить последующие изменения и понимать, с кого спрашивать фидбэк. С командой Git blame эту информацию легко найти.

В GitLab 12.2 новый Blame API извлекает эту информацию напрямую с GitLab, а не через репозиторий. Это полезно для скриптов и автоматизации на основе пользователей, которые недавно меняли файл.

Спасибо, Олег Зубченко, за твой вклад.

Загрузки для управления дизайном

PREMIUM, ULTIMATE, SILVER, GOLD

Дизайнеры и разработчики теперь могут вместе работать над дизайнами внутри задачи GitLab благодаря функции загрузок для управления дизайном на GitLab. Дизайны можно загружать в новую область внутри задачи для удобного отслеживания и совместной работы.

Контроль версий для дизайнов

PREMIUM, ULTIMATE, SILVER, GOLD

В GitLab 12.2 мы представляем контроль версий для дизайнов. Благодаря контролю версий можно легко просматривать изменения со временем и отслеживать эти изменения и прогресс.

Множественное удаление для реестра контейнеров

CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD

Очень важно соблюдать порядок в реестре контейнеров. Со временем образы накапливаются и захламляют диск. Если тегов слишком много, растягивается время загрузки страницы управления реестром контейнеров в Packages > Container Registry, и ее бывает сложно использовать.

Раньше было всего несколько вариантов управления реестром, все со своими недостатками. Можно было использовать API массового удаления тегов и сборку мусора, чтобы автоматизировать очистку, но для этого надо было писать и обслуживать скрипт. Еще можно было вручную удалять образы и теги со страницы управления, но это занимает слишком много времени, ведь удалять приходится по одному.

Теперь интерфейс GitLab позволяет гораздо быстрее прибираться вручную. Выберите сразу несколько тегов, а если выбрать образ, все связанные с ним теги выберутся автоматически. Обслуживать реестр теперь будет проще, и вы сэкономите на хранении и будете поддерживать производительность страницы. Мы рады представить это дополнение в реестре контейнеров и готовим новые удобные штуки. Не пропустите будущие улучшения, например возможность настраивать политику хранения и срока годности.

Сортировка списка задач вручную

CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD

Упорядочить большой список задач непросто — нужно указать приоритет и порядок реализации, например, чтобы навести чистоту в бэклоге.

В выпуске 12.2 можно сортировать список задач вручную в режиме Manual, где можно перетаскивать задачи по списку и располагать их в любом порядке.

Порядок сохраняется во всем экземпляре для всех списков задач проекта и списков задач групп, где включен режим Manual.

Пространство имен Kubernetes для каждой среды

CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD

Использовать один кластер Kubernetes для нескольких сред бывает полезно. Например, если для разработки и стейджинга используется один кластер, административные издержки сокращаются, ведь управлять нужно всего одним кластером. И на инфраструктуре можно сэкономить — Kubernetes будет планировать поды из обеих сред на меньшем числе нод.

Раньше GitLab недостаточно поддерживал такие сценарии, и все среды в проекте развертывались в одном пространстве имен. Если нужны были разные разрешения для каждой среды (например, вы хотели разрешить инженерам деплоить в среду разработки, но не стейджинга), приходилось заводить по отдельному кластеру. Теперь интеграция GitLab Kubernetes использует выделенное пространство имен для каждой среды проекта, и вы можете детально настраивать разрешения для каждой среды, чтобы полноценно наслаждаться преимуществами использования одного кластера для нескольких сред.

Пользователи Kubernetes смогут использовать один кластер для разных сред, и им не придется деплоить все среды в одно пространство имен. А еще операторы могут детально настраивать разрешения для каждой среды, чтобы пользователи могли деплоить в некоторые среды, но не во все.

Удаление Cert Manager из управляемых приложений Kubernetes GitLab

CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD

Если вы установили Cert Manager в кластер Kubernetes через GitLab Kubernetes, теперь его можно удалить одним щелчком на странице кластера.

Удаление Helm из управляемых приложений Kubernetes GitLab

CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD

Если вы установили Helm в кластер Kubernetes через GitLab Kubernetes, теперь его можно удалить одним щелчком на странице кластера.

Удаление Knative из управляемых приложений Kubernetes GitLab

CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD

Если вы установили Knative в кластер Kubernetes через GitLab Kubernetes, теперь его можно удалить одним щелчком на странице кластера.

Отключение уведомлений по эл. почте для группы или проекта

CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD

Теперь владельцы могут отключать уведомления на уровне группы или проекта независимо от индивидуальных настроек пользователей.
Если отключить уведомления на уровне группы, это затронет все подгруппы и проекты в родительской группе.

Фильтрация проектов по имени при импорте из Bitbucket Server

CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD

Импортировать существующие проекты из Bitbucket Server на GitLab должно быть просто. Но если таких проектов тысячи, замучаешься выбирать репозитории Bitbucket.

В выпуске 12.2 мы упрощаем эти миграции и представляем фильтр на странице импорта Bitbucket Server, где можно указать имена репозиториев, которые нужно импортировать. Мы с удовольствием добавляем этот фильтр во все импортеры проекта в будущих выпусках.

Файл блокировки, не допускающий несколько экземпляров раннера на одном хосте

CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD

Запуск нескольких экземпляров gitlab-runner на одном хосте может привести к путанице и усложнить отладку. Так не должно быть, поэтому мы представляем файл блокировки, который предотвратит это случайное событие.

Улучшенные примеры для автоматического разделения тестов

CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD

У нас уже есть ключевое слово parallel, с которым можно контролировать и гибко настраивать параллельные тесты (или выполнять вообще любое задание параллельно), но разработчику приходится много настраивать, и иногда логика разделения просто дублируется. Есть опенсорс-решения, например Test Boosters, которые совершенствуют этот процесс и разделяют конфигурацию теста на несколько файлов, автоматизируя эту часть настройки. Мы обновили документацию для ключевого слова parallel, чтобы сделать процесс более очевидным и повысить эффективность пайплайнов.

Улучшенная маскировка переменных для символов @ и :

CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD

Мы добавили поддержку двух дополнительных символов в маскировке переменных, и теперь GitLab может автоматически скрывать больше разных секретов, чем сейчас.

Ярлыки и аннотации для задач с помощью GFM в оповещениях из внешних экземпляров Prometheus

ULTIMATE, GOLD

Если у вас есть экземпляр Prometheus, который управляется за пределами GitLab, мы упростили сортировку и назначение инцидентов. Мы добавили поле gitlab_incident_markdown, где GitLab ищет оповещения. Оно отображается над инцидентами в разделе Summary. GFM (GitLab Flavored Markdown) можно добавить к файлам конфигурации оповещений в AlertManager и использовать, чтобы автоматически назначать и помечать задачи, открытые по оповещениям.

Ярлыки для задач, открытых оповещениями Prometheus с инцидентом

ULTIMATE, GOLD

Если вы настроили проект открывать задачи по оповещениям Prometheus, ярлык incident будет применяться автоматически. Поэтому теперь команда реагирования на инциденты сможет легко сортировать их на досках задач, и им не придется вручную помечать задачи на основе инцидентов и задачи другого типа.

Встроенные метрики Prometheus в задачах

CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD

Диаграммы метрик наглядно показывают, какое изменение привело к инциденту. С диаграммами метрик, встроенными прямо в задачи, вы сразу можете приступить к работе над новым инцидентом, не копаясь на панелях мониторинга в поисках метрик за период оповещения. При работе с инцидентом дежурный может использовать встроенные диаграммы, чтобы делиться знаниями и контекстом, которые он получил при изучении метрик и логов. После инцидента у команды, которая займется его расследованием, будут все нужные диаграммы в одном месте, включая метрики от исходного оповещения и весь анализ, проведенный при устранении сбоя.

Чтобы встроить диаграммы в задачи, просто создайте ссылку на диаграмму на панели мониторинга с метриками. Укажите период для данных с помощью фильтра времени на панели мониторинга, и он будет сохранен в URL. Вставьте URL в описание, и диаграмма будет встроена в задачу.

Когда оповещение будет создавать задачу на основе инцидента, может использоваться настроенный шаблон. Если добавить диаграмму метрик в шаблон задачи, она будет автоматически встраиваться и показывать метрики за период, связанный с оповещением.

Чтение и запись примечаний администратора о пользователях через API

STARTER, PREMIUM, ULTIMATE

Примечания администратора о пользователях могут быть полезны при администрировании большой базы пользователей на GitLab. На GitLab.com наши админы обычно используют атрибут note, чтобы следить за поведением пользователей. Если пользователей много, то легко запутаться в таких примечаниях, написанных через пользовательский интерфейс. Теперь можно использовать API для чтения и записи примечаний администратора, так что админам экземпляра стало совсем просто добавлять напоминания на уровне пользователей.

Загрузка CSV-файла диаграмм Prometheus на панели мониторинга с метриками

CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD

Многие работают с GitLab через скринридер. Чтобы скринридер читал контент, визуальная информация, например диаграммы, должна быть представлена в виде текста. GitLab может создавать данные диаграммы в виде CSV-файла, который можно загрузить и отправить в скринридер. Для этого откройте меню в правом верхнем углу нужной диаграммы и выберите загрузку CSV-файла.

Панель мониторинга безопасности в представлении по умолчанию для групп

ULTIMATE, GOLD

Теперь можно настраивать панель мониторинга безопасности групп как экран по умолчанию, который открывается при просмотре группы. Этот выбор делает каждый пользователь в команде по отдельности, настраивая самое интересное представление.

Теперь ответственные за безопасность и пользователи, озабоченные безопасностью группы, могут сразу видеть состояние безопасности, не путешествуя по меню.

GitLab Runner 12.2

CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD

Сегодня мы выпустили GitLab Runner 12.2! GitLab Runner — это проект с открытым исходным кодом, который используется для запуска заданий CI/CD и отправки результатов обратно в GitLab.

Самые интересные изменения:

Полный список изменений можно найти в журнале изменений GitLab Runner: CHANGELOG.

Улучшение схем GitLab

CORE, STARTER, PREMIUM, ULTIMATE

Мы внесли следующие улучшения в схемы GitLab:

Минимальная поддерживаемая версия теперь — Kubernetes 1.11.
Параметры networkproxy для registry теперь можно настраивать.
Параметры балансировщика нагрузки для gitlab-shell теперь можно настраивать.
Использование подготовленных операторов Postgres теперь можно отключить для gitlab-migrations.

Улучшения Omnibus

CORE, STARTER, PREMIUM, ULTIMATE

GitLab 12.2 включает Mattermost 5.13 — альтернативу Slack с открытым кодом, в новый выпуск которого входят новые плагины для сообщества, интеграции DevOps и многое другое.
В GitLab 12.2 формула подсчета по умолчанию для рабочего процесса Unicorn была скорректирована, чтобы улучшить обработку параллельных запросов в больших деплоях. Формула изменилась с CPUs + 1 на int(CPUs * 1.5 +1).
Пакеты GitLab 12.2 теперь доступны для Debian Buster.
nginx обновлен до 1.16.1, поддержка TLS v1.3 и ECDSA теперь включена по умолчанию.
postgresql обновлен до 9.6.14 и 10.9.
gitlab-monitor обновлен до 4.2.0, graphicsmagick — до 1.3.33.
Чтобы улучшить безопасность и доступность, команда Redis KEYS теперь отключена по умолчанию. При желании эту и другие команды можно контролировать или скрыть.
Добавлена поддержка случайных кодов и политики безопасности контента для защиты от JavaScript XSS-атак. Эти параметры отключены по умолчанию.

Улучшения производительности

CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD

Мы продолжаем улучшать производительность GitLab с каждым выпуском для экземпляров GitLab любого размера.

Некоторые улучшения в GitLab 12.2:

Устаревшие фичи

Удаление страницы интеграции с сервисом Kubernetes

Страница интеграции с сервисом Kubernetes удалена в выпуске 12.2. Ее заменит функционал кластера на уровне экземпляра, который появился в GitLab 11.11.

Дата удаления: 22 августа 2019 г.

Режим видимости Internal (внутренний) отключен на GitLab.com для новых проектов, групп и фрагментов кода.

Параметр Internal полезен для самоуправляемых экземпляров, если проект должен быть доступен для любого зарегистрированного пользователя. При использовании в экземплярах, где регистрация пользователей ограничена, это может стать неплохим инструментом для поддержки практики innersource.

Но на GitLab.com регистрация пользователей открыта и доступна всем желающим. А раз любой может зарегистрироваться и получить доступ на чтение ресурсов в режиме видимости Internal, между Internal и Public (общедоступным режимом) почти нет разницы.

Поэтому с 30 июля новые проекты, группы и фрагменты кода смогут быть только общедоступными (Public) или закрытыми (Private). Существующие ресурсы в режиме Internal останутся без изменений и в ближайшем будущем для них будет установлено Private. Владельцы могут изменить параметры видимости раньше.

Дата удаления: 30 июля 2019 г.

Требуется Ruby 2.6

Начиная с GitLab 12.2 для запуска требуется Ruby 2.6. Omnibus GitLab и GitLab Chart уже поставляются с Ruby 2.6.3, но пользователи исходных установок с версией Ruby 2.5 или раньше должны обновиться.

Дата удаления: 22 августа 2019 г.

Важные примечания об обновлении до GitLab 12.2

Как указано в посте о критическом обновлении безопасности, будет сделана резервная копия существующих данных Grafana, Grafana будет сброшена до исходной конфигурации, и GitLab SSO будет единственным доступным режимом аутиентификации.
Аутентифицированное шифрование cookie Rails теперь включено, старые сеансы автоматически обновляются. Понижение уровня cookie сеанса не поддерживается. После перехода на выпуск 12.2 понижение версии приведет к тому, что все сеансы станут недействительными, и пользователей выкинет.
Как и GitLab 12.0 и GitLab 12.1, выпуск GitLab 12.2 автоматически увеличит версию PostgreSQL до 10.7.
Вы можете пропустить автоматическое обновление до PostreSQL 10.7, создав /etc/gitlab/disable-postgresql-upgrade.

Журнал изменений

Ищите все эти изменения в журнале изменений:

Установка

Если вы настраиваете новую установку GitLab, посетите страницу загрузки GitLab.

Обновление

Загляните на страницу обновлений.

Теги:

Хабы: