События развертывания и настройка системы непрерывной интеграции

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

Все нижеприведенные параметры настраиваются для каждой среды в проекте в разделе Настройки → Релизы → Конвейер развертыванияТам создайте токен для отчетности. Его увидит только Владелец или Администратор. Сохраните его в виде секрета в конвейере CI соответствующей среды. CoRoid хранит лишь хеш токена, а замена токена немедленно аннулирует старый вариант. Токен может формировать отчеты только для своего проекта и среды. Никогда не помещайте его в файл репозитория или запрос браузера.

Действия GitHub и GitLab CI/CD#

Если вы хотите Развернуть в… кнопку на странице релиза, выберите CoRoid запускает рабочий процесс Actions GitHub или CoRoid запускает конвейер GitLab CI/CD в настройках конвейера развертывания соответствующей среды. Укажите точное имя задания развертывания, ссылку на ветку или тег, а при необходимости — имя файла рабочего процесса GitHub. Эта ссылка должна указывать на коммит релиза в момент запроса, если только рабочий процесс GitHub не объявляет coroid_artifact_sha входной параметр (см. ниже). Рабочий процесс GitHub получает coroid_release_id, coroid_attempt_id, coroid_commit_sha, и coroid_environment входные параметры, плюс coroid_version, coroid_build_number, coroid_release_name и coroid_artifact_sha когда рабочий процесс их объявляет. GitLab получает эквивалентные переменные в верхнем регистре COROID_* . Используйте эти значения для развертывания и отчетности о точном хэше и попытке.

Рабочий процесс GitHub, объявляющий coroid_artifact_sha Он выполняется из собственной ветки, обычно из вашей ветки по умолчанию, и развертывает коммит, указанный в качестве входных данных. Затем CoRoid может развернуть любой релиз, включая откат к более старой версии, используя текущий рабочий процесс; при этом ветка больше не обязана указывать на коммит релиза. CoRoid фиксирует, с какого коммита начался запуск, и проверяет эту информацию при получении отчета о выполнении. Рабочий процесс также должен зафиксировать развертывание GitHub для развернутого коммита, причем статус этого развертывания связывает запуск с соответствующим релизом — это необходимо для случаев, когда запуск стартовал из другого коммита.

Еще два необязательных входных параметра делают развертывания безопасными для восстановления:

• coroid_expected_revision — это коммит, который выполнялся в среде в момент запроса на развертывание. Сравните его с тем, что выполняется в среде перед развертыванием. Если они различаются, значит кто-то уже выполнил развертывание, поэтому процесс останавливается без фактического развертывания.
• coroid_rollback — это true Это происходит при откате среды. Для таких запусков выделите отдельную группу параллельного выполнения, чтобы откат никогда не задерживался из-за развертывания. Перед откатом CoRoid отменяет еще не завершившееся развертывание и ждет его остановки. Если оно не остановится вовремя, откат не произойдет, и Владельцам и Администраторам будет отправлено уведомление.

GitLab получает их как COROID_EXPECTED_REVISION и COROID_ROLLBACK. Укажите версию в сборке показывает, как внедрить версию в сборку.

Называйте каждый запуск в соответствии с номером попытки, чтобы CoRoid мог найти запуск, о начале которого он не получил подтверждения. В Actions GitHub установите: run-name на текст, содержащий coroid_attempt_id. В GitLab установите workflow:name на текст, содержащий $COROID_ATTEMPT_ID:

# GitHub Actions
run-name: ${{ inputs.coroid_attempt_id && format('Deploy (attempt {0})', inputs.coroid_attempt_id) || 'Deploy' }}

# GitLab CI/CD
workflow:
  name: 'Deploy $COROID_ATTEMPT_ID'

Если CoRoid запустил запуск, но провайдер так и не подтвердил его начало, развертывание будет ожидать. Через 5 минут CoRoid ищет запуск с таким же номером попытки в названии; если находит — продолжает работу по нему. Если через 15 минут запуск не найден, развертывание считается потерянным, релиз помечается как неудачный, и среда становится готовой к новому развертыванию.

Сохраните токен обратной связи среды в секретах GitHub Actions или в зашифрованных переменных GitLab CI/CD. Отправьте running событие при начале задания развертывания и терминальное succeeded, failed, или cancelled Событие при завершении. CoRoid проверяет запуск провайдера, коммит и указанную задачу перед тем, как признать успешным выполнение для настроенного конвейера. URL запуска провайдера остается основным местом для просмотра логов.

Рабочий процесс GitHub, запускающийся из одного коммита и развертывающий другой — например, с ref входным параметром для развертывания более старого коммита или отката — должен указать, какой коммит был развернут. Создайте Развертывание GitHub для развернутого коммита в среде и присвойте его окончательному success статусу log_url , ссылающееся на запуск рабочего процесса. Приложению GitHub затем требуется разрешение на доступ к репозиторию Развертывания: Только для чтения. Рабочий процесс продакшена CoRoid содержит конкретный пример настройки GitHub Actions; адаптируйте имена секретов и заданий под свой репозиторий.

Универсальный обратный вызов CI#

Внешний конвейер может отправлять те же события без включения функции диспетчеризации. Аутентифицируйтесь с помощью облачного токена доступа к среде. Эндпоинт принимает запросы JSON в следующем версионированном формате:

POST /api/v1/release-deployment-events
Authorization: Bearer <environment-callback-token>
Content-Type: application/json

{
  "schemaVersion": 1,
  "eventId": "ci:run-812:production:succeeded",
  "providerRunId": "run-812",
  "projectId": "<project-uuid>",
  "environmentKey": "production",
  "repository": "owner/repository",
  "commitSha": "0123456789abcdef0123456789abcdef01234567",
  "status": "succeeded",
  "occurredAt": "2026-09-24T12:00:00Z",
  "runUrl": "https://ci.example.com/runs/812"
}

Укажите releaseId и attemptId При формировании отчета о запуске, инициированном CoRoid, добавьте: version и buildNumber Чтобы зафиксировать то, что было развернуто. Для проекта, размещенного на CoRoid,: repository — это идентификатор проекта. failureReason может объяснить причину сбоя запуска. Используйте queued, running, succeeded, failed, cancelled, или rolled_back для status. Отчет rolled_back когда выполнение обновило среду, а затем восстановило предыдущую версию из-за сбоя новой версии. Сохраните один providerRunId в ходе выполнения и присвойте каждому переходу состояния уникальный eventId. Повторная попытка того же события должна сохранять свой идентификатор; для нового запуска CI требуется новый идентификатор запуска. Повторный запуск GitHub сохраняет attemptId и отображает информацию о попытке запуска в providerRunId (<run id>-<run attempt>). Если он повторно запускает последнее развертывание среды, CoRoid следует тому же сценарию развертывания. В противном случае CoRoid регистрирует его как отдельное развертывание, которое он зафиксировал. Метка времени события должна быть актуальной. CoRoid проверяет репозиторий, среду, коммит, область действия учетных данных и конечное состояние перед применением данных; противоречивые события направляются на рассмотрение. Допустимое развертывание без подготовленного релиза может создать зафиксированный релиз, четко отличимый от кандидата, одобренного на этапе предварительной проверки. Он использует: version Событие отчетности или, если CoRoid назначает версии проекта, следующую доступную версию.

Версия 2 события ("schemaVersion": 2) также отображает две идентичности развертывания: что было развернуто и что осуществило развертывание. artifact содержит развернутый коммит, который должен совпадать с commitSha, а также хэш каждого образа. workflow содержит коммит, с которого начался запуск, и при необходимости его ссылку:

{
  "schemaVersion": 2,
  "commitSha": "0123456789abcdef0123456789abcdef01234567",
  "artifact": {
    "sha": "0123456789abcdef0123456789abcdef01234567",
    "images": [{ "name": "app", "digest": "sha256:…" }]
  },
  "workflow": {
    "sha": "89abcdef0123456789abcdef0123456789abcdef",
    "ref": "owner/repository/.github/workflows/deploy.yml@refs/heads/main"
  }
}

CoRoid сохраняет событие v2 для рассмотрения, если коммит рабочего процесса не совпадает с коммитом, по которому запрашивалось развертывание, или если провайдер указывает, что запуск стартовал из другого коммита. События версии 1 по-прежнему принимаются.

Для конвейера без обратных вызовов Владелец или Администратор могут выбрать Записать внешнее развертывание На странице релиза. Укажите среду, соответствующий коммит, время, а также причину или URL с доказательствами. Результатом ручной аттестации станет запись о результате без утверждения, что CoRoid выполнил этап CI или прошел проверку.

Связанное#

• Настройки релиза
• Релизы
• Восстановление и релизные цепочки
• Укажите версию в своей сборке