Puerta de Liberación CI Dogfooding

Usar Decision Gate como un flujo de trabajo de puerta de lanzamiento.

Esta guía documenta cómo Decision Gate gestiona su propio proceso de liberación al restringir la elegibilidad de lanzamiento utilizando evidencia CI determinista. El objetivo es demostrar una capa de política real y auditable sin reemplazar el sistema CI.

Por Qué Esto Es Rigurosamente

  • Separación de preocupaciones: CI ejecuta pruebas; Decision Gate evalúa la política y emite una decisión determinista.
  • Impulsado por evidencia: La decisión se basa en un conjunto de evidencia versionado en lugar de registros de CI implícitos.
  • Salida auditable: Decision Gate exporta un runpack que contiene la trayectoria de decisión actual y metadatos de integridad. La verificación del runpack no establece por sí misma la reproducción semántica, la autenticidad de la evidencia, la corrección de la historia aceptada, el enlace externo o la no repudio.
  • Determinista: El mismo conjunto de evidencia produce la misma decisión.

Qué es Gated

El flujo de trabajo de la etiqueta de lanzamiento valida que un lanzamiento es elegible en función de:

  • Formateo, lint y pruebas unitarias
  • Prioridades de prueba del sistema P0 y P1 (no fases de la hoja de ruta)
  • cargo-deny
  • Verificaciones de deriva del generador
  • Cobertura completa de SBOM para cada lanzamiento sujeto
  • Verificación de la atestación de procedencia para cada sujeto de lanzamiento
  • Verificación de firma OIDC sin clave para cargas útiles de artefactos y procedencia
  • Política de vulnerabilidad bloqueada (High/Critical bloqueada + KEV bloqueado en cualquier severidad)
  • Ejecuciones de prueba de empaquetado (Python + TypeScript)
  • Prueba de humo de Docker
  • Consistencia de etiqueta/version (la etiqueta coincide con la versión del espacio de trabajo)

Si falta algún requisito o es falso, la puerta niega la liberación.

Paquete de Evidencia

El flujo de trabajo de lanzamiento escribe un paquete de evidencia en JSON y valida cada campo requerido como un booleano exacto. El envoltorio construye un registro tipado hostil y lo envía directamente para la condición exacta bajo la autoridad del llamador derivada de límites y el tiempo de recepción. DG admite ese registro contra el dominio de registro cerrado exacto y la política de uso de evidencia; no se permite la vinculación de llamadores ficticios, JSON dinámico o condiciones acopladas a proveedores en el escenario validado.

Ejemplo (solo forma):

{
  "release": {
    "tag": "v0.1.0",
    "version": "0.1.0",
    "tag_matches_version": true,
    "sha": "<git sha>",
    "generated_at": 1710000000000,
    "sbom_path": ".tmp/ci/sbom/decision-gate.sbom.spdx.json"
  },
  "checks": {
    "fmt": true,
    "clippy": true,
    "cargo_deny": true,
    "generate_all": true,
    "unit_tests": true,
    "system_tests_p0": true,
    "system_tests_p1": true,
    "sbom": true,
    "sbom_complete": true,
    "sbom_verified": true,
    "provenance_verified": true,
    "signature_verified": true,
    "vuln_policy_pass": true,
    "package_dry_run": true,
    "docker_smoke": true
  }
}

Escenario de Política

La puerta de liberación se expresa como un escenario estándar de Decision Gate:

  • Plantilla: configs/ci/release_gate_scenario.json
  • Política: Todas las condiciones deben ser verdaderas (un requisito completo de RET And)
  • Adquisición: una presentación de llamador atribuida a un límite apunta a la condición exacta directamente.
  • Ejecución: ejecución de escenario en vivo (no prechequeo) por lo que se produce un runpack

El escenario se instancia en tiempo de ejecución al reemplazar los marcadores de posición de la plantilla:

  • {{SCENARIO_ID}} -> identificador único del escenario

Cómo se ejecuta en CI

El flujo de trabajo de lanzamiento realiza la siguiente secuencia:

  1. Ejecuta verificaciones de CI (fmt, clippy, pruebas, denegar, empaquetado, prueba de humo).
  2. Genera evidencia de la cadena de suministro de lanzamiento con scripts/ci/supply_chain_generate.sh (sujetos, SBOMs, procedencia, firmas sin clave, artefactos de vulnerabilidad).
  3. Verifica la evidencia de la cadena de suministro con scripts/ci/supply_chain_verify.sh como un umbral estricto.
  4. Escribe el conjunto de evidencia de lanzamiento de Decision Gate, incluyendo los nuevos booleanos de verificación de la cadena de suministro.
  5. Valida y proyecta los booleanos requeridos, luego inicia un servidor MCP local con configs/presets/ci-release-gate.toml y su lista de permitidos de clave de entorno exacta.
  6. Evalúa el escenario utilizando el paquete de evidencia.
  7. Exporta y verifica un runpack.
  8. Carga los artefactos:
    • Conjunto de pruebas
    • Runpack
    • Paquete de evidencia de la cadena de suministro (SBOM/procedencia/firmas/artifacts de vulnerabilidad)
    • Carga útil de decisión y resumen
    • Nombre del artefacto: decision-gate-release-gate

La implementación se encuentra en scripts/ci/ci_release_gate.sh y es llamada por el flujo de trabajo de lanzamiento.

Postura de Distribución Solo de Origen

Este repositorio actualmente se detiene en lanzamientos etiquetados, de origen primero. .github/workflows/release.yml aún genera evidencia de lanzamiento auditada, pero no hay un flujo de trabajo activo que publique paquetes o imágenes de contenedor en registros públicos.

Eso significa que la elegibilidad para el lanzamiento sigue siendo estricta y reproducible, mientras que la distribución externa requiere una decisión de política futura separada fuera del contrato actual de CI.

Ejecutando Localmente

Puedes ejecutar el mismo gate de lanzamiento localmente con un paquete de evidencia personalizado:

python3 - <<'PY'
import json
from pathlib import Path

Path("evidence/release_evidence.json").write_text(json.dumps({
    "release": {
        "tag": "v0.1.0",
        "version": "0.1.0",
        "tag_matches_version": True,
        "sha": "local",
        "generated_at": 0,
        "sbom_path": "evidence/sbom/decision-gate.sbom.spdx.json",
    },
    "checks": {
        "fmt": True,
        "clippy": True,
        "cargo_deny": True,
        "generate_all": True,
        "unit_tests": True,
        "system_tests_p0": True,
        "system_tests_p1": True,
        "sbom": True,
        "package_dry_run": True,
        "docker_smoke": True,
    },
}, indent=2))
PY

bash scripts/ci/ci_release_gate.sh \
  --evidence-file evidence/release_evidence.json \
  --output-dir evidence/release-runpack \
  --config configs/presets/ci-release-gate.toml

Si alguna verificación es falsa, el script sale con un código distinto de cero y el resumen de decisiones mostrará la razón de la denegación.

Para ejecutar la generación + verificación de la cadena de suministro de paridad de lanzamiento local antes de la evaluación de la puerta:

bash scripts/ci/verify_all.sh --release-parity

Artefactos a Inspeccionar

  • decision_payload.json: carga útil de respuesta cruda del Decision Gate
  • decision_summary.json: tipo de decisión + permitir/negar
  • runpack/manifest.json: manifiesto de runpack determinista
  • runpack_verify.json: salida de verificación de runpack
  • Docs/architecture/decision_gate_ci_and_workflow_architecture.md
  • configs/ci/release_gate_scenario.json
  • scripts/ci/ci_release_gate.sh