Eventos de despliegue y configuración de CI

CoRoid solo marca una versión como desplegada cuando lo indica tu CI/CD. Esta página muestra cómo informa una canalización sobre los despliegues, ya sea que CoRoid los inicie o se ejecuten por sí solos.

Todo lo que sigue se configura por entorno en la sección de Configuración → Lanzamientos → Canalización de despliegueCrea un token de informes allí. Un Propietario o Administrador lo verá una vez. Guárdalo como secreto en la canalización de CI de ese entorno. CoRoid solo conserva un hash, y al reemplazar el token se revoca inmediatamente el anterior. El token solo puede informar sobre su proyecto y entorno. Nunca lo incluyas en un archivo del repositorio ni en una solicitud del navegador.

Acciones de GitHub y GitLab CI/CD#

Si deseas que el Desplegar en… botón en la página de lanzamientos, selecciona CoRoid inicia un flujo de trabajo de GitHub Actions o CoRoid inicia una canalización de GitLab CI/CD en la configuración de la canalización de despliegue del entorno. Introduce el nombre exacto del trabajo de despliegue, la referencia de rama o etiqueta y, si procede, el nombre del archivo del flujo de trabajo de GitHub. Esa referencia debe apuntar al commit de lanzamiento en el momento de la solicitud, a menos que el flujo de trabajo de GitHub declare una coroid_artifact_sha entrada (ver más abajo). El flujo de trabajo de GitHub recibe coroid_release_id, coroid_attempt_id, coroid_commit_sha, y coroid_environment entradas, además de coroid_version, coroid_build_number, coroid_release_name y coroid_artifact_sha cuando el flujo de trabajo los declare. GitLab recibe las variables equivalentes en mayúsculas COROID_* . Usa estos valores para desplegar e informar del SHA y el intento exactos.

Un flujo de trabajo de GitHub que declare coroid_artifact_sha Se ejecuta desde su propia referencia, normalmente tu rama predeterminada, y despliega el commit incluido en esa entrada. CoRoid puede luego desplegar cualquier versión, incluida una reversión a una anterior, con el flujo de trabajo actual, y la referencia ya no necesita apuntar al commit de la versión. CoRoid registra desde qué commit se inició la ejecución y lo verifica cuando la ejecución informa. El flujo de trabajo también debe registrar un despliegue de GitHub del commit desplegado cuyo estado enlace con la ejecución, ya que la comprobación de despliegue de CoRoid lo lee cuando la ejecución se inició desde otro commit.

Dos entradas opcionales más hacen que los despliegues sean seguros para recuperarse:

• coroid_expected_revision es el commit que ejecutaba el entorno cuando se solicitó el despliegue. Compáralo con lo que ejecuta el entorno antes de desplegar. Si difieren, alguien realizó un despliegue entretanto, por lo que se detendrá sin desplegar.
• coroid_rollback es true Cuando la ejecución revierte el entorno. Asigna a dichas ejecuciones su propio grupo de concurrencia para que una reversión nunca espere detrás de un despliegue. Antes de una reversión, CoRoid cancela un despliegue que todavía esté en curso y espera hasta que se detenga. Si no se detiene a tiempo, no se realiza ninguna reversión y se avisa a los Propietarios y Administradores.

GitLab los recibe como COROID_EXPECTED_REVISION y COROID_ROLLBACK. Incluye la versión en tu compilación muestra cómo incrustar la versión en la compilación.

Nombra cada ejecución según su intento para que CoRoid pueda encontrar una ejecución de la que nunca recibió confirmación de inicio. En GitHub Actions, configura run-name para que el texto contenga coroid_attempt_id. En GitLab, configura workflow:name para que el texto contenga $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'

Si CoRoid inicia una ejecución pero el proveedor nunca confirma que haya comenzado, el despliegue espera. Después de 5 minutos, CoRoid busca una ejecución cuyo nombre incluya el intento y, si la encuentra, sigue esa ejecución. Si no se encuentra ninguna ejecución después de 15 minutos, el despliegue se considera perdido, su versión se marca como fallida y el entorno acepta un nuevo despliegue.

Guarda el token de devolución de llamada del entorno en los secretos de Acciones de GitHub o en las variables enmascaradas de GitLab CI/CD. Envía un evento running cuando comience el trabajo de despliegue y un evento terminal succeeded, failed, o cancelled evento cuando finaliza. CoRoid verifica la ejecución del proveedor, el commit y el trabajo nombrado antes de aceptar el éxito para una canalización configurada. La URL de la ejecución del proveedor sigue siendo el lugar para inspeccionar los registros.

Un flujo de trabajo de GitHub que se ejecuta desde un commit y despliega otro, por ejemplo uno con una ref entrada para desplegar un commit anterior o realizar un rollback, debe specificar qué commit desplegó. Crea un Despliegue de GitHub para el commit desplegado en el entorno, y asigna su estado final success un log_url que vincule la ejecución del flujo de trabajo. La aplicación de GitHub necesita entonces el permiso de repositorio Despliegues: Solo lectura. El Flujo de trabajo de producción de CoRoid contiene un ejemplo concreto de Acciones de GitHub; adapta sus nombres de secretos y trabajos a tu repositorio.

Devolución de llamada de CI genérica#

Una canalización externa puede enviar los mismos eventos sin activar el envío. Autentícate con el token portador con alcance del entorno. El punto de conexión acepta JSON con esta estructura versionada:

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"
}

Incluye releaseId y attemptId al informar sobre una ejecución solicitada por CoRoid. Agrega version y buildNumber para registrar lo que desplegaste. Para un proyecto alojado en CoRoid, repository es el ID del proyecto. failureReason puede explicar una ejecución fallida. Usa queued, running, succeeded, failed, cancelled, o rolled_back para status. Informe rolled_back cuando la ejecución actualizó el entorno y luego restauró la revisión anterior porque la nueva falló. Mantén uno providerRunId durante toda una ejecución y asigna un identificador único a cada transición de estado. eventId. Un reintento del mismo evento debe conservar su ID; una nueva ejecución de CI necesita un nuevo ID de ejecución. Una re-ejecución de GitHub mantiene el attemptId y registra su intento de ejecución en el providerRunId (<run id>-<run attempt>). Si reejecuta el último despliegue del entorno, CoRoid sigue el mismo despliegue. De lo contrario, CoRoid lo registra como un despliegue separado que observó. La marca de tiempo del evento debe ser reciente. CoRoid verifica el repositorio, el entorno, el commit, el alcance de las credenciales y el estado final antes de aplicarlo; los eventos conflictivos se mantienen en revisión. Un despliegue válido sin una versión preparada puede crear una versión observada, claramente separada de un candidato aprobado previamente. Toma el version el evento informa o, cuando CoRoid asigna las versiones del proyecto, la siguiente.

La versión 2 del evento ("schemaVersion": 2) también registra las dos identidades de un despliegue: qué se desplegó y quién lo desplegó. artifact contiene el commit desplegado, que debe coincidir con commitSha, y el digest de cada imagen. workflow contiene el commit desde el cual se inició la ejecución y, opcionalmente, su referencia:

{
  "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 retiene un evento v2 para revisión cuando el commit del flujo de trabajo no es el mismo para el que se solicitó el despliegue, o cuando el proveedor muestra que la ejecución comenzó desde otro commit. Los eventos de versión 1 siguen siendo aceptados.

Para una canalización sin devoluciones de llamada, un Propietario o Administrador puede elegir Registrar despliegue externo en la página de la versión. Indica el entorno, el commit coincidente, la hora y una URL de motivo o evidencia. La certificación manual resultante registra el resultado sin afirmar que CoRoid ejecutó CI o superó una barrera.

Relacionado#

• Configuración de lanzamiento
• Lanzamientos
• Recuperación y trenes de lanzamiento
• Incluye la versión en tu compilación