PDM

Действия над приложением ​

Действие приложения — это операция, которую можно запустить для конкретного сервиса платформы, не заходя в GitLab. Все действия отвечают на один и тот же вопрос: «какой тег образа должен оказаться на стенде». Разница только в том, откуда этот тег берётся.

Какие действия есть ​

У большинства сервисов набор одинаковый — три действия:

ДействиеЧто делает
Сборка ветвиЗапускает в GitLab сборку из указанной ветки кода. Тег получившегося образа становится результатом действия
Сборка версииЗаписывает в репозиторий указанный номер версии (например, 3.14.2) и запускает сборку от него
Установить тегНичего не собирает: просто берёт уже существующий тег образа из собранных ранее

Первые два помечены в системе как сборочные — они действительно запускают пайплайн и занимают время. «Установить тег» сборку не запускает и отрабатывает мгновенно.

Набор действий зависит от сервиса

У некоторых сервисов доступны не все три — например, «Сборка ветви» может отсутствовать. В интерфейсе показываются только те действия, которые реально настроены для этого приложения.

Где запускаются действия ​

Действие можно запустить в двух местах, и результат у них разный:

  • Страница «CI-сборки» — сборка ради сборки. Образ собирается и кладётся в реестр, но никуда не выкатывается. Подробнее — Сборки и пайплайны.
  • Вкладка «Сервисы» стенда — сборка ради выкладки. Действие подставляется как значение поля «версия», и после применения изменений собранный образ попадает на стенд.

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

Запуск действия на стенде ​

Это основной сценарий: «поставить на стенд свежую сборку такой-то ветки».

  1. На вкладке Сервисы стенда у поля версии сервиса выберите действие: Сборка ветви, Сборка версии или Установить тег.
  2. Заполните значение — ветку, тег или номер версии. Для «Сборки версии» PDM подставляет текущую версию сервиса как исходную, её нужно поправить.
  3. Выбранное действие попадает в панель несохранённых изменений. На этом этапе ничего ещё не запущено: действие сохранено как намерение.
  4. Нажмите Развернуть изменения и подтвердите.

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

В работу уходят только изменённые поля

PDM применяет ровно те значения, которые вы поменяли. Нетронутые настройки и версии остальных сервисов не трогаются.

Что происходит после запуска ​

Порядок шагов для сборочного действия:

  1. PDM запускает пайплайн в GitLab. Имя пайплайна помечается признаком запуска из PDM и вашим логином — по нему сборку легко найти среди чужих.
  2. Пока пайплайн идёт, шаг обработки остаётся в состоянии Выполняется. PDM опрашивает GitLab примерно раз в 10 секунд, поэтому долгая сборка — это долго висящий шаг, и это нормально.
  3. Когда пайплайн завершается успешно, PDM определяет тег собранного образа и подставляет его как значение поля версии.
  4. Итоговый набор значений применяется к живому окружению стенда, а сами значения записываются в файл конфигурации стенда.

Для действия «Установить тег» первые три шага пропускаются: тег известен сразу.

Как следить за ходом ​

Сразу после запуска операция появляется в разделе Рабочие пространства. На её странице видны шаги со статусами, логи каждого шага и, у сборочного шага, ссылка на пайплайн в GitLab — подробнее в разделе Запуск и наблюдение.

Где смотреть результат ​

Что проверитьГде
Операция дошла до концаСтатус обработки — Завершено
Что именно собралосьЛог сборочного шага и ссылка на пайплайн
Что теперь стоит на стендеКолонка Развёрнутая версия на вкладке «Сервисы»
Стенд поднялся после выкладкиВкладка Дашборд стенда — статус и готовность сервисов

Если что-то пошло не так ​

У упавшей операции статус обработки — Ошибка. Что делать:

  1. Прочитайте текст ошибки в упавшем шаге.
  2. Если упала сборка — перейдите по ссылке на пайплайн и смотрите причину в GitLab: ошибка почти всегда в коде или в самом пайплайне, а не в PDM.
  3. Типовые причины, которые видно по тексту ошибки:
    • пайплайн завершился неуспешно — сборка не прошла, тега нет, дальше PDM не идёт;
    • не найден GitLab-токен — некоторые операции (в частности, запись номера версии при «Сборке версии») выполняются от вашего имени. Токен указывается в настройках аккаунта;
    • не хватает прав — операция не выполнилась на стороне сервера.
  4. Устранив причину, запустите действие заново. Каждый запуск создаёт новую обработку — упавшую нельзя «дотолкать», она остаётся в истории как есть.

Упавшая операция не откатывает то, что уже сделано

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

Смотрите также ​