Эксплуатационный release gate

Release gate CodeGraph собирает результаты проверок безопасности, качества, тестов, соответствия требованиям и ревью в один отчёт выпуска. Выберите проект, версию и профиль, чтобы сопоставить результаты с настроенными порогами. Используйте JSON и код возврата в pipeline, а историю — для сравнения запусков.

Перед проверкой

Подготовьте локальное окружение Python и конфигурацию по руководству CLI. Выполняйте примеры в PowerShell из корня репозитория CodeGraph. До запуска замените все обозначения в угловых скобках внутри кавычек; значения с пробелами оставляйте в кавычках. Выберите новый путь отчёта, чтобы не принять результат прежнего запуска за текущий.

1. Определите точные проект, версию и базовую Git-ревизию.
2. Убедитесь, что CPG и входы проверок относятся к этой ревизии.
3. Получите список профилей из установленной конфигурации.
4. Если профиль требует оператора, используйте разрешённый operator-id.
5. Заранее определите место для неизменяемого отчёта и связанных свидетельств.

Состав и пороги проверок задаются в release_gate.profiles. Сохраните использованную конфигурацию вместе с отчётом.

Список профилей

python -m src.cli release profiles

Команда показывает имя и описание каждого профиля, идентификаторы проверок и их уровни: blocker, warning или info. Выберите нужное имя для --profile; параметры и пороги прочитайте в конфигурации профиля.

Запуск проверки

python -m src.cli release check --project "<project>" --version "<version>" --base-ref "<git-ref>" --profile "<profile>" --operator-id "<operator-id>" --format json --language ru --output "<release-gate.json>"

Без --project используется unknown, поэтому в промышленной автоматизации проект следует задавать явно. Без --profile применяется профиль по умолчанию. Параметр --db передаёт путь к CPG в контекст запуска проверок.

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

После команды сохраните код возврата и прочитайте тот же файл отчёта:

$gateExit = $LASTEXITCODE
$decision = Get-Content "<release-gate.json>" -Raw | ConvertFrom-Json
$decision | Select-Object status, project, profile, version, passed, total, blockers, warnings
$decision.checks | Select-Object id, passed, severity, message, value, threshold
"CLI exit code: $gateExit"

Замените путь на значение, переданное в --output. Сверьте проект, профиль и версию с запросом; изучите неуспешные проверки и сообщения о недостающих данных. --output записывает отчёт и при отказе проверки. Если запуск завершился до создания отчёта, старый файл может остаться на месте: используйте новый путь и убедитесь, что файл создан именно этим запуском.

Коды завершения CLI

Код возврата соответствует полю status отчёта. Для каждой проверки прочитайте message, измеренное value и порог threshold: эти поля объясняют полученный результат и доступность входных данных.

Просмотр истории

python -m src.cli release history --project "<project>" --limit 20

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

Принятие риска замечания

Исключение (suppression) учитывает согласованный риск конкретного замечания при проверке выпуска. Оператор записывает причину, согласующего, срок действия и ссылку на заявку:

python -m src.cli release suppress --finding-id "<finding-id>" --reason "<reason>" --approved-by "<approver>" --expires "<iso-8601>" --ticket "<ticket>" --project "<project>"

Просмотрите активные исключения проекта:

python -m src.cli release suppressions list --project "<project>"

Для удаления используйте административный маршрут DELETE /api/v1/admin/runtime/release-gate/suppressions/{finding_id} в контексте того же проекта. Успешное удаление возвращает HTTP 204; HTTP 404 означает, что исключение с этим идентификатором в выбранном проекте не найдено. Повторите просмотр списка, чтобы проверить результат.

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

Административный REST API

Административный маршрут с аутентификацией подключён по префиксу /api/v1/admin/runtime/release-gate:

Пример тела проверки:

{
  "profile": "standard",
  "version": "1.2.3",
  "base_ref": "origin/main"
}

Если включено создание снимков, REST-проверка также может вернуть идентификаторы снимков до и после запуска и их сравнение. Свежесть входных свидетельств проверяйте по их ревизиям, временным меткам и источникам.

Как использовать результат

Эта эксплуатационная проверка формирует отчёт выпуска. Успешный результат не завершает приёмку продукта и не закрывает задачу поставки. До закрытия сохраните обязательные свидетельства ревью, тестирования, безопасности и согласований в процессе поставки.

Отчёт объединяет результаты проверок выбранного профиля и переданного контекста. Сопоставьте каждое value с threshold, разберите message, блокеры и предупреждения. Сохраните отчёт, конфигурацию профиля и точную ревизию исходников вместе с результатами тестирования. Этот комплект позволяет объяснить решение о выпуске и повторить проверку после исправлений.

Восстановление

• Если профиль неизвестен, выполните python -m src.cli release profiles и исправьте конфигурацию вызывающей стороны.
• Если входы проекта устарели, обновите их через процесс ответственного владельца и повторите ту же проверку.
• Если предупреждение должно блокировать CI, добавьте --fail-on-warn; не переопределяйте код 2 в последующем скрипте.
• Если исключение истекло или потеряло обоснование, удалите его и повторите проверку.
• Если история расходится с текущим отчётом, опирайтесь на свежий запуск, привязанный к ревизии и исследуйте область старой записи.