GitLab 11.10 с пайплайнами на панели управления, пайплайнами для объединенных результатов и предложениями по нескольким строкам в мердж-реквестах.

Удобные сведения о работоспособности пайплайнов в разных проектах

GitLab продолжает увеличивать прозрачность жизненного цикла DevOps. В этом выпуске на панель управления ^[1] добавлен обзор статуса пайплайнов.

Это удобно, даже если вы изучаете пайплайн одного проекта, но особенно полезно, если проектов несколько ^[2], — а так обычно и бывает, если вы используете микросервисы и хотите запустить пайплайн для тестирования и поставки кода из разных репозиториев проектов. Теперь вы сразу видите работоспособность пайплайнов на панели управления ^[3], где бы они ни выполнялись.

Запуск пайплайнов для объединенных результатов

Со временем исходная и целевая ветки расходятся, и может возникнуть ситуация, когда по отдельности они справляются, а вместе не работают. Теперь можно запустить пайплайны для объединенных результатов до мерджа ^[4]. Так вы быстро заметите ошибки, которые проявились бы только при частом перемещении изменений между ветками, а значит гораздо быстрее исправите ошибки пайплайна и будете эффективнее использовать GitLab Runner ^[5].

Дальнейшая оптимизация совместной работы

В GitLab 11.10 появилось еще больше возможностей для удобной совместной работы и упрощенных рабочих процессов. В предыдущем выпуске ^[6] мы ввели предложения по мердж-реквестам, когда рецензент мог предложить изменение одной строки в комментарии к мердж-реквесту, и его можно было сразу закоммитить прямо из треда комментариев. Нашим пользователям это понравилось, и они попросили расширить эту фичу. Теперь вы можете предлагать изменения для нескольких строк ^[7], указывая, какие строки удалить, а какие — добавить.

Спасибо за ваши отзывы и предложения!

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

В этом выпуске столько потрясающих фич, например, ярлыки в определенной области ^[8], более тщательная очистка реестра контейнеров ^[9], компонуемый Auto DevOps ^[10] и возможность покупать дополнительные минуты CI Runner ^[11]. Ниже подробности о каждой из них.

Самый ценный сотрудник этого месяца (MVP ^[12]) — Такуя Ногути

В этом месяце самым ценным сотрудником стал Такуя Ногути (Takuya Noguchi ^[13]). Такуя неплохо поработал во славу GitLab ^[14]: исправлял баги, доделывал недоработки в бэкенде и фронтенде и улучшал пользовательский интерфейс. Спасибо!

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

Пайплайны на панели управления

PREMIUM, ULTIMATE, SILVER, GOLD

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

^[15]

Пайплайны для объединенных результатов

PREMIUM, ULTIMATE, SILVER, GOLD

Обычно со временем исходная ветка отклоняется от целевой, если вы постоянно не перемещаете между ними изменения. В результате пайплайны исходной и целевой веток «зеленые» и конфликтов мерджа не возникает, но при объединении происходит сбой из-за несовместимости изменений.

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

Если вы используете пайплайны мердж-реквестов (в любом качестве) и задействуете частные GitLab-раннеры версии 11.8 или старше, их нужно обновить, чтобы не возникла проблема gitlab-ee#11122 ^[16]. Это не влияет на пользователей общедоступных GitLab-раннеров.

^[17]

Предложение изменений в нескольких строках

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

При совместной работе над мердж-реквестами вы часто замечаете проблемы и предлагаете решения. С версии GitLab 11.6 мы поддерживаем предложение изменений ^[6] для одной строки.

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

^[18]

Ярлыки в одной области

PREMIUM, ULTIMATE, SILVER, GOLD

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

Допустим, вам нужно кастомное поле в задачах, чтобы отслеживать операционную систему платформы, на которую нацелены ваши функции. Каждая задача должна относиться только к одной платформе. Можно создавать ярлыки platform::iOS, platform::Android, platform::Linux и другие по необходимости. Если применить один такой ярлык к задаче, автоматически удалится другой существующий ярлык, который начинается с platform::.

Допустим, у вас есть ярлыки workflow::development, workflow::review и workflow::deployed, обозначающие состояние рабочего процесса в вашей команде. Если у задачи уже есть ярлык workflow::development, а разработчик хочет перевести задачу на стадию workflow::review, он просто применяет новый ярлык, а старый (workflow::development) автоматически удаляется. Это поведение уже существует, когда вы перемещаете задачи между списками ярлыков на доске задач, которая представляет рабочий процесс вашей команды. Теперь члены команды, которые не работают с доской задач напрямую, могут изменить состояние рабочего процесса в самих задачах.

^[19]

Более тщательная очистка реестра контейнеров

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

При обычном использовании реестра контейнеров с CI-пайплайнами вы отправляете несколько отдельных изменений в один тег. Из-за реализации распределения Docker поведение по умолчанию — сохранить все изменения в системе, но в итоге они занимают много памяти. Если использовать параметр -m с registry-garbage-collect, можно быстро удалить все предыдущие изменения и освободить драгоценное место.

^[20]

Покупка дополнительных минут CI Runner

BRONZE, SILVER, GOLD

Пользователи с платными планами GitLab.com (Gold, Silver, Bronze) теперь могут покупать дополнительные минуты CI Runner. Раньше нужно было укладываться в квоту, предусмотренную планом. Благодаря этому улучшению можно заранее покупать минуты сверх квоты, чтобы избежать перерывов в работе из-за остановки пайплайнов.

Сейчас 1000 минут стоят 8 долларов, и покупать их можно сколько угодно. Дополнительные минуты начнут расходоваться, когда вы потратите всю месячную квоту, а остаток дополнительных минут переносится на следующий месяц. В будущем выпуске ^[21] мы хотим добавить эту фичу и в бесплатные планы.

^[22]

Компонуемый Auto DevOps

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

С Auto DevOps команды переходят на современные практики DevOps почти без усилий. Начиная с GitLab 11.10 каждый джоб в Auto DevOps предоставляется в виде независимого шаблона ^[23]. Пользователи могут использовать функцию includes ^[24] в GitLab CI, чтобы включать отдельные стадии Auto DevOps и при этом использовать свой кастомный файл gitlab-ci.yml. Таким образом можно включать только нужные джобы и пользоваться преимуществами обновлений в upstream.

^[25]

Автоматическое управление членами группы на GitLab.com с помощью SCIM

SILVER, GOLD

Раньше управлять членством в группах на GitLab.com приходилось вручную. Теперь можно использовать SAML SSO и управлять членством с помощью SCIM, чтобы создавать, удалять и обновлять пользователей на GitLab.com.

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

^[26]

Вход на GitLab.com через поставщика SAML

SILVER, GOLD

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

Пользователям не придется дважды выполнять вход, поэтому компаниям удобнее использовать SAML SSO для GitLab.com.

^[27]

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

Схема дочерних эпиков

ULTIMATE, GOLD

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

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

^[28]

Всплывающие экраны мердж-реквестов

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

В этом выпуске мы представляем информативные экраны, всплывающие при наведении курсора на ссылку мердж-реквеста. Раньше мы показывали только заголовок мердж-реквеста, а теперь еще и статус мердж-реквеста, статус CI-пайплайна и короткий URL.

В будущих выпусках мы планируем добавить больше важных сведений, например, ответственные лица и контрольные точки ^[29], а еще введем всплывающие экраны для задач ^[30].

^[31]

Фильтрация мердж-реквестов по целевым веткам

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

Рабочие процессы Git для выпуска или поставки ПО часто связаны с несколькими долгосрочными ветками — для внесения исправлений в предыдущие версии (например, stable-11-9) или перехода от проверки качества к производству (например, integration), но не так-то просто найти мердж-реквесты для этих веток среди множества открытых мердж-реквестов.

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

Спасибо, Хироюки Сато (Hiroyuki Sato ^[32])!

^[33]

Отправка и мердж при успешном пайплайне

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

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

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

^[34]

Улучшенная интеграция с внешними панелями мониторинга

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

GitLab может обращаться к нескольким серверам Prometheus (на уровне среды, проекта и группы (ожидается) ^[35]), но наличие нескольких конечных точек может усложнять систему или не поддерживаться стандартными панелями мониторинга. В этом выпуске команды могут использовать один API Prometheus, что значительно упрощает интеграцию с такими сервисами, как Grafana.

Сортировка Wiki-страниц по дате создания

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

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

^[36]

Мониторинг ресурсов, запрошенных кластером

ULTIMATE, GOLD

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

^[37]

Просмотр метрик балансировщика нагрузки на панели мониторинга Grafana

CORE, STARTER, PREMIUM, ULTIMATE

Очень важно следить за работоспособностью экземпляра GitLab. Раньше мы предоставляли панели мониторинга по умолчанию через встроенный экземпляр Grafana. Начиная с этого выпуска мы включили дополнительные панели для мониторинга балансировщиков нагрузки NGINX.

SAST для Elixir

ULTIMATE, GOLD

Мы продолжаем расширять поддержку языков и углублять проверки безопасности. В этом выпуске мы включили проверки безопасности для проектов на Elixir ^[38] и проектов, созданных на платформе Phoenix ^[39].

Несколько запросов в одной диаграмме

PREMIUM, ULTIMATE, SILVER, GOLD

В GitLab можно создавать диаграммы, чтобы визуализировать собираемые метрики. Часто — например, если нужно посмотреть максимальное или среднее значение метрики, — хочется вывести несколько значений на одной диаграмме. Начиная с этого выпуска у вас есть такая возможность.

Результаты DAST на панели безопасности группы

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

Мы добавили результаты динамического тестирования защищенности приложений (Dynamic Application Security Testing, DAST) на панель безопасности группы в дополнение к SAST, сканированию контейнеров и сканированию зависимостей.

Добавление метаданных в отчет о сканировании контейнеров

ULTIMATE, GOLD

В этом выпуске в отчете о сканировании контейнеров содержится больше метаданных — мы добавили затрагиваемый компонент (фича Clair) в существующие метаданные: приоритет, идентификатор (со ссылкой на mitre.org) и затрагиваемый уровень (например, debian:8).

Добавление типа отчета по метрикам в мердж-реквесты

PREMIUM, ULTIMATE, SILVER, GOLD

GitLab уже предоставляет несколько типов отчетов, которые можно включать прямо в мердж-реквесты: от отчетов о качестве кода ^[40] и модульном тестировании ^[41] на этапе проверки до SAST ^[42] и DAST ^[43] на этапе защиты.

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

Поддержка мультимодульных проектов Maven для сканирования зависимостей

ULTIMATE, GOLD

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

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

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

По умолчанию GitLab Runner клонирует проект в уникальный вложенный путь в $CI_BUILDS_DIR. Но для некоторых проектов, например Golang, код нужно клонировать в конкретный каталог, чтобы его можно было собрать.

В GitLab 11.10 мы ввели переменную GIT_CLONE_PATH, с помощью которой можно указать конкретный путь, куда GitLab Runner клонирует проект до выполнения задачи.

Простая маскировка защищенных переменных в логах

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

GitLab предоставляет несколько способов защитить ^[44] и ограничить область ^[45] переменных в GitLab CI/CD. Но переменные все равно могут намеренно или случайно попасть в журналы сборки.

GitLab серьезно относится к управлению рисками и аудиту и продолжает добавлять фичи для соблюдения требований. В GitLab 11.10 мы ввели возможность маскировать некоторые типы переменных в логах трассировки джобов, добавив уровень защиты от случайного попадания содержимого этих переменных в журналы. А еще GitLab теперь автоматически маскирует ^[46] многие встроенные переменные токенов.

Включение и отключение Auto DevOps на уровне группы

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

С Auto DevOps в проекте GitLab.com можно без лишних хлопот взяться за современные рабочие процессы DevOps — от сборки до поставки.

Начиная с GitLab 11.10 вы можете включать и отключать Auto DevOps для всех проектов в одной группе.

Упрощенная и улучшенная страница лицензий

STARTER, PREMIUM, ULTIMATE

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

^[47]

Обновление селектора ярлыков для деплоев Kubernetes

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

На панелях деплоя отображаются сведения обо всех деплоях Kubernetes.

В этом выпуске мы изменили способ сопоставления ярлыков с деплоями. Теперь доступны совпадения по app.example.com/app и app.example.com/env или app. Это позволит избежать конфликтов при фильтрации и риска неправильных деплоев, связанных с проектом.

Кроме того, в версии GitLab 12.0 мы удалим ярлык app из селектора деплоев Kubernetes ^[48], и совпадение будет возможно только по app.example.com/app и app.example.com/env.

Динамическое создание ресурсов Kubernetes

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

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

При деплое Kubernetes GitLab CI будет создавать эти ресурсы перед деплоем.

Групповые раннеры для кластеров на уровне группы

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

Кластеры на уровне группы теперь поддерживают установку GitLab Runner. Раннеры Kubernetes на уровне группы отображаются для дочерних проектов как групповые раннеры, помеченные ярлыками cluster и kubernetes.

Счетчик вызова для функций Knative

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

Функции, развернутые с GitLab Serverless ^[49], теперь показывают количество полученных вызовов для отдельной функции. Для этого нужно установить Prometheus на кластере, где установлен Knative.

^[50]

Контроль параметров git clean для джобов GitLab CI/CD

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

По умолчанию GitLab Runner выполняет git clean в процессе выгрузки кода при выполнении джоба в GitLab CI/CD. Начиная с GitLab 11.10 пользователи могут контролировать параметры, переданные команде git clean. Это удобно для команд с выделенными раннерами, а также для команд, которые собирают проекты из больших монорепозиториев. Теперь они могут управлять процессом выгрузки до выполнения скриптов. Новая переменная GIT_CLEAN_FLAGS по умолчанию имеет значение -ffdx и принимает все возможные параметры команды [git clean](https://git-scm.com/docs/git-clean).

Внешняя авторизация в Core

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

Защищенные среды могут требовать дополнительный внешний ресурс авторизации для доступа к проекту. Мы добавили поддержку дополнительного уровня контроля доступа в 10.6 ^[51] и получили много просьб открыть этот функционал в Core. Мы рады представить внешнюю авторизацию и дополнительный уровень безопасности для экземпляров Core, раз эта фича нужна отдельным участникам.

Возможность создания проектов в группах в Core

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

Роль Developer может создавать проекты в группах еще с версии 10.5 ^[52], а сейчас это возможно и в Core. Создание проектов — это ключевая возможность для продуктивной работы в GitLab, и благодаря включению этой функции в Core участникам экземпляра теперь проще заняться чем-то новым.

GitLab Runner 11.10

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

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

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

• Параметр для указания пути клонирования ^[53].
• Улучшенная поддержка git clean ^[54].
• Возможность отключения трассировки отладки ^[55].
• Использование отложенного расширения переменной для проверки ошибок в Windows Cmd ^[56].
• Исправление цветового вывода в Windows ^[57].

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

Исправление возвращаемого project_id в API поиска blob в Elasticsearch

STARTER, PREMIUM, ULTIMATE

Мы исправили ошибку в API поиска blob в Elasticsearch, который ошибочно возвращал 0 для project_id. Нужно будет переиндексировать Elasticsearch ^[59], чтобы получать правильные значения project_id после установки этой версии GitLab.

Улучшения Omnibus

CORE, STARTER, PREMIUM, ULTIMATE

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

• GitLab 11.10 включает Mattermost 5.9.0 ^[60], альтернативу Slack с открытым исходным кодом ^[61], в последний выпуск которого входит новый каталог интеграции для простого переноса данных из Hipchat и много чего еще. Эта версия включает обновления безопасности ^[62], и мы советуем обновиться.
• Мы интегрировали Grafana с Omnibus ^[63], и теперь начать мониторинг экземпляра GitLab стало совсем просто.
• Мы добавили поддержку удаления старых образов контейнеров из реестра Docker.
• Мы обновили ca-certs до 2019-01-23.

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

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

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

• Автозаполнение пользователей теперь происходит быстрее ^[64].
• Оптимизированы SQL-запросы для вывода задач проекта при поиске ^[65].
• Результаты поиска Elasticsearch больше не включают Gitaly ^[66].
• У запросов GraphQL теперь есть ограничение по сложности ^[67].
• Отключено инструментирование для диффов, чтобы повысить производительность мердж-реквестов, когда включен Prometheus ^[68].
• Улучшена производительность импорта пул-реквестов GitHub ^[69].
• Поиск коммитов в кэше по имени ссылки ^[70].
• Улучшена производительность диффов мердж-реквестов — теперь blob дифф-файлов запоминаются ^[71].

Улучшение диаграмм GitLab

CORE, STARTER, PREMIUM, ULTIMATE

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

• Добавлена поддержка Elasticsearch ^[72].

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

GitLab Geo обеспечит хэшированное хранение в GitLab 12.0

GitLab Geo требуется хэшированное хранилище ^[73] для смягчения конкуренции на вторичных нодах. Это было отмечено в gitlab-ce#40970 ^[74].

В GitLab 11.5 ^[75] мы добавили это требование в документацию Geo: gitlab-ee#8053 ^[76].

В GitLab 11.6 ^[77] sudo gitlab-rake gitlab:geo:check проверяет, включено ли хэшированное хранилище и все ли проекты переносятся. См. gitlab-ee#8289 ^[78]. Если вы используете Geo, пожалуйста, запустите эту проверку и мигрируйте как можно скорее.

В GitLab 11.8 ^[79] постоянно отключаемое предупреждение gitlab-ee!8433 ^[80] будет отображаться на странице Admin Area › Geo › Nodes, если вышеупомянутые проверки не разрешены.

В GitLab 12.0 ^[81] Geo будет использовать требования к хэшированному хранилищу. См. gitlab-ee#8690 ^[82].

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

Поддержка Ubuntu 14.04

GitLab 11.10 станет последним выпуском с поддержкой Ubuntu 14.04 ^[83].

Canonical объявила о прекращении стандартной поддержки Ubuntu 14.04 с апреля 2019 года ^[84]. Советуем пользователям перейти на поддерживаемую версию LTS: Ubuntu 16.04 или Ubuntu 18.04.

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

Ограничение максимального количества пайплайнов, создаваемых одной отправкой

Раньше GitLab создавал пайплайны для HEAD каждой ветки в отправке. Это удобно для разработчиков, которые отправляют сразу несколько изменений (например, в ветку фичи и в ветку develop).

Но при отправке большого репозитория, где много активных веток (например, для перемещения, отзеркаливания или разветвления), не нужно создавать пайплайн для каждой ветки. Начиная с GitLab 11.10 мы создаем максимум 4 пайплайна ^[85] при отправке.

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

Устаревшие пути legacy кода GitLab Runner

Начиная с Gitlab 11.9 GitLab Runner использует новый метод ^[86] клонирования/вызова репозитория. В настоящее время GitLab Runner будет использовать старый метод, если новый не поддерживается. Подробнее смотрите в этой задаче ^[87].

В GitLab 11.0 мы изменили вид конфигурации сервера метрик для GitLab Runner. metrics_server будет удален в пользу listen_address в GitLab 12.0. Подробнее смотрите в этой задаче ^[88].

В версии 11.3 GitLab Runner начал поддерживать несколько кэш-провайдеров ^[89]; что привело к новым настройкам для конкретной конфигурации S3 ^[90]. В документации ^[91], приведена таблица изменений и инструкции по переходу к новой конфигурации. Подробнее смотрите в этой задаче ^[92].

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

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

Устаревший параметр для фичи точки входа для GitLab Runner

В 11.4 GitLab Runner представлен параметр фичи FF_K8S_USE_ENTRYPOINT_OVER_COMMAND ^[93] для исправления таких проблем, как #2338 ^[94] и #3536 ^[95].

В GitLab 12.0 мы переключимся на правильное поведение, как если бы параметр фичи был отключен. Подробнее смотрите в этой задаче ^[96].

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

Устаревшая поддержка дистрибутива Linux, достигшего EOL, для GitLab Runner

Некоторые дистрибутивы Linux, в которые можно установить GitLab Runner, свое отслужили.

В GitLab 12.0 GitLab Runner больше не будет распределять пакеты в такие дистрибутивы Linux. Полный список дистрибутивов, которые больше не поддерживаются, можно найти в нашей документации ^[97]. Спасибо Хавьеру Ардо (Javier Jardón ^[98]) за его вклад ^[99]!

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

Удаление старых команд GitLab Runner Helper

В рамках усилий по поддержке Windows Docker executor ^[100] пришлось отказаться от некоторых старых команд, которые используются для helper image ^[101].

В GitLab 12.0 GitLab Runner запускается с помощью новых команд. Это касается только пользователей, которые переопределяют helper image ^[102]. Подробнее смотрите в этой задаче ^[103].

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

Удаление legacy механизма git clean из GitLab Runner

В GitLab Runner 11.10 мы предоставляем возможность ^[54] настроить, как Runner выполняет команду git clean. Кроме того, новая стратегия очистки удаляет использование git reset и помещает команду git clean после шага выгрузки.

Раз это изменение поведения может повлиять на некоторых пользователей, мы подготовили параметр FF_USE_LEGACY_GIT_CLEAN_STRATEGY. Если установить значение true, он восстановит legacy-стратегию очистки. Больше об использовании параметров функций в GitLab Runner можно найти в документации ^[104].

В GitLab Runner 12.0 мы удалим поддержку legacy-стратегии очистки и возможность восстанавливать ее с помощью параметра функции. Подробнее смотрите в этой задаче ^[105].

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

Раздел System Info в панели администратора

GitLab представляет информацию о вашем экземпляре GitLab в admin/system_info, но эта информация может быть неточной.

Мы удалим этот раздел ^[106] панели администратора в GitLab 12.0 и рекомендуем использовать другие возможности мониторинга ^[107].

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

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

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

• GitLab Community Edition ^[108]
• GitLab Enterprise Edition ^[109]
• GitLab Runner ^[110]

Установка

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

Обновление

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

Планы подписки GitLab

GitLab доступен в двух вариантах: самоуправляемый ^[113] и облачный SaaS ^[114].

Самоуправляемый ^[113]: локально или на предпочитаемой облачной платформе.

• Core: для небольших команд, персональных проектов или пробной версии GitLab на неограниченный период.
• Starter: для команд, работающих в одном офисе над несколькими проектами, которым нужна профессиональная поддержка.
• Premium: для распределенных команд, которым нужны расширенные функции, высокая доступность и круглосуточная поддержка.
• Ultimate: для предприятий, которым требуется надежная стратегия и реализация с улучшенной безопасностью и соответствием требованиям.

Облачный SaaS ^[114] — GitLab.com: размещается, управляется и администрируется GitLab по бесплатным и платным подпискам ^[114] для отдельных разработчиков и команд.

• Free: неограниченные частные репозитории и неограниченное количество участников проекта. У закрытых проектов есть доступ к фичам уровня Free, у открытых проектов ^[115] есть доступ к фичам уровня Gold.
• Bronze: для команд, которым нужен доступ к расширенным фичам рабочего процесса.
• Silver: для команд, которым нужны более надежные возможности DevOps, соответствие требованиям и быстрая поддержка.
• Gold: подходит для множества джобов CI/CD. Все открытые проекты могут бесплатно использовать фичи Gold независимо от плана.

Автор: nAbdullin

Источник ^[116]