Dependencia y gobernanza de CI/CD

Esta página explica cómo PayCal mantiene deterministas las dependencias de JavaScript y cómo se aplican las puertas de CI antes del lanzamiento.

Metadatos de verificación

  • Ruta: /transparency/dependency-ci/
  • Última verificación:
  • Próxima revisión pendiente:
  • Alcance de la verificación: Política de paquetes npm, comportamiento del archivo de bloqueo, flujos de trabajo de GitHub Actions y documentación de lanzamiento.

Política de dependencia de npm

PayCal utiliza una política de dependencia de archivos de bloqueo primero para las herramientas de JavaScript y las comprobaciones de automatización del navegador.

  • Install mode for automation: npm ci only (frozen lockfile install).
  • Lockfile source of truth: package-lock.json is required for deterministic CI installs.
  • Declared package manifest: package.json defines lint, smoke, and accessibility command surfaces.
  • Override controls: dependency overrides are declared in package.json to pin selected transitive risk points.

If npm ci reports a mismatch between package.json and package-lock.json, the lockfile is updated intentionally in a dedicated maintenance change before CI reruns.

Para qué se utiliza npm

Propósito Comando Control primario
Comprobaciones de pelusa y fregadero de JavaScript npm run test:js Reglas ESLint + comprobaciones de políticas de receptor JS
Controles de humo del dramaturgo npm run test:smoke:ui Comportamiento de ruta a nivel de navegador y validación de regresión
Verificaciones de políticas y rutas de accesibilidad npm run test:a11y:all Conjuntos de pruebas WCAG, reflujo, contraste y ARIA
Generación de matriz de contraste. npm run test:a11y:contrast Verificación de conformidad de contraste a nivel de tema

Modelo de puerta CI/CD

PayCal separa los controles de calidad entre los flujos de trabajo para que las fallas sean explícitas y rastreables:

  • .github/workflows/javascript.yml: Node 20 + npm ci + JavaScript quality gates.
  • .github/workflows/phpunit.yml: staged backend validation from fast gate to deep verification and artifacts.
  • .github/workflows/phpstan.yml: strict static analysis with baseline-blocking policy.

Los flujos de trabajo de higiene de versiones tratan las puertas fallidas como bloqueadores y requieren una nueva ejecución después de las correcciones.

Limitaciones conocidas

  • Las páginas de transparencia pública se sincronizan manualmente con los cambios de flujo de trabajo y paquetes en los ciclos de lanzamiento.
  • El comportamiento de la canalización de CI está documentado en varias páginas y puede variar si las actualizaciones no se aplican de manera consistente.

Mejoras planificadas en la documentación

  • Publique una matriz de puerta canónica que asigne cada trabajo de CI al estado de propietario, activador, comando y bloqueo.
  • Agregue una instantánea de gobierno de dependencia trimestral que incluya paquetes npm directos, justificación y cadencia de actualización.
  • Agregue un elemento de la lista de verificación de lanzamiento para confirmar que los documentos de gobernanza de npm permanecen alineados con el flujo de trabajo y la política de archivos de bloqueo.

Cómo verificar

# Reproduce JavaScript CI gates locally
npm ci
npm run test:js

# Reproduce broader release-level accessibility gate
npm run test:a11y:all

# Inspect workflow definitions
cat .github/workflows/javascript.yml
cat .github/workflows/phpunit.yml
cat .github/workflows/phpstan.yml

Related transparency pages: Testing and Validation Governance and Verification and Governance.