Запуск сборщика backport в конвейере выпуска

Инструменты сборки, а не зависимость времени выполнения. На этой странице описано, как управлять конвейером выпуска, который создаёт backport. Конвейер выполняется в CI; он никогда не запускается в нижестоящем приложении.

Обзор

Производственный путь использует два рабочих процесса. 0-ci.yml проверяет каждое изменение в каждой долгоживущей ветке. Выпуск исходного кода запускает build.yml, который собирает и публикует дистрибутив. Оба рабочих процесса проверяются по .github/workflows/.

Контроль CI

0-ci.yml запускается по событиям push и pull request для PHP74 и PHP81. Он последовательно выполняет три задания:

1. PHPStan (инструменты сборки) — composer analyse, уровень 10 для rector/rules и scripts.
2. PHPUnit (правила Rector) — composer test, наборы фикстур для трёх пользовательских правил.
3. Пробный запуск сборки — composer build:dry, выполняется только после первых двух заданий.

Доверенные события используют собственные PHP-раннеры. Pull request из форков и Dependabot используют размещённые на GitHub раннеры с подготовленным PHP 8.5. Это проверяется по 0-ci.yml (выражение runs-on и условный шаг setup-php). Модель с двумя ветками независимо проверяет изменения, затрагивающие обе цели, в pull request каждой ветки.

Конвейер выпуска

build.yml — это производственная сборка. Она запускается по событию repository_dispatch типа source-release либо вручную через workflow_dispatch с указанием тега. Конвейером управляет тег версии. Номер версии имеет формат MAJOR.MINOR.PATCH для объявленного публичного API (Semantic Versioning 2.0.0 §2).

Линия PHP 8.1

1. build-php81 — извлекает инструменты сборки, подготавливает PHP 8.5, устанавливает зависимости сборки, клонирует репозитории исходного кода по тегу выпуска, запускает scripts/build.php, переключает раннер на PHP 8.1, проверяет синтаксис output/src на PHP 8.1, а затем устанавливает полученный пакет с --no-dev. После этого выгружает результат как артефакт.
2. validate-php81 — загружает артефакт, затем устанавливает и тестирует его на матрице PHP 8.1, 8.2, 8.3 и 8.4.
3. release-php81 — загружает артефакт, фиксирует и тегирует сгенерированное дерево, создаёт zip-архив без vendor/ и .git/, а затем публикует выпуск GitHub с прикреплённым архивом.

Линия PHP 7.4

1. build-php74 — извлекает инструменты сборки в ветке PHP74, подготавливает PHP 8.5, клонирует по тегу только основной репозиторий исходного кода, запускает scripts/build.php --target=php74, переключается на PHP 7.4 и проверяет синтаксис результата на PHP 7.4.
2. validate-php74 — устанавливает и тестирует результат на матрице PHP 7.4 и 8.0.
3. release-php74 — создаёт zip-архив только из основного результата и прикрепляет его к тому же выпуску как второй архив.

Этот поток проверяется по определениям заданий и матрицам в build.yml.

Обе линии используют один выпуск GitHub. Линия PHP 8.1 создаёт выпуск, а линия PHP 7.4 прикрепляет свой архив к тому же тегу. Группа concurrency backport-build с cancel-in-progress: false запускает сборки строго по одной, поэтому два выпуска исходного кода не могут конфликтовать.

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

Запуск сборки

Обычно сборка запускается автоматически, когда исходная организация публикует выпуск. Чтобы вручную пересобрать определённый тег, запустите build.yml с этим тегом, например v2.0.0. Токен диспетчеризации — secrets.BACKPORT_TRIGGER_TOKEN; он авторизует клонирование репозиториев исходного кода. Это проверяется по build.yml (workflow_dispatch.inputs.tag, GH_TOKEN).

Анализ неудавшейся сборки

Скрипт сборки останавливается на первом неудачном этапе и выводит имя этапа и ошибку. Пять этапов: слияние, Rector, генерация composer.json, копирование ресурсов и проверка. Если шаг проверки синтаксиса после сборки завершается неудачей, значит Rector создал результат, который отвергает целевая среда выполнения. Этот шаг защищает выпуск. Сопоставьте сбой с его причиной в /integrations/backport/troubleshooting/.

Что публикуется

Выпуск включает zip-архивы дистрибутива. Пакет поставляется как теги версий, а не как ветки. Потребители устанавливают nextpdf/backport (и при необходимости nextpdf/backport-pro) из канала выпусков. В архив не включаются vendor/ и .git/. Это проверяется по build.yml (zip -r ... -x '*/vendor/*' '*/.git/*').

Версионирование результата

Создаваемый composer.json содержит версию, переданную в командной строке (--version, либо тег диспетчеризации без ведущего v). Пакет Pro закрепляет nextpdf/backport на соответствующем ограничении с символом каретки для major.minor. Это проверяется по scripts/adjust-composer.php (majorMinor(), generateProComposer()). Поддерживайте согласованность между тегом выпуска исходного кода и версией backport, чтобы карта replace оставалась непротиворечивой.

Далее

• /integrations/backport/security-and-operations/ — граница доверия конвейера и состояние цепочки поставок.
• /integrations/backport/troubleshooting/ — справочник по сбоям на каждом этапе.