Saltar a contenido

CI/CD y seguridad automatizada

Los workflows validan código, dependencias y documentación. Las pruebas Docker/Odoo reales siguen siendo explícitas porque requieren daemon, imágenes y más tiempo que el CI básico.

Workflows

Workflow Eventos Responsabilidad
ci.yml Push y PR a master Ruff, pytest sin Docker, JavaScript, wheel/sdist y whitespace.
docs.yml Cambios documentales, push/PR y manual Paridad bilingüe, builds estrictos y despliegue Pages.
codeql.yml Push, PR y lunes programado Análisis de Python, JavaScript/TypeScript y Actions.
dependency-review.yml PR a master Rechaza nuevas dependencias con vulnerabilidad alta o crítica.
publish.yml Tag v* Verifica versión, pruebas y wheel; publica en PyPI mediante OIDC.

Todos usan permisos mínimos y acciones compatibles con el runtime Node actual de GitHub Actions. El CI sin Docker corre hoy en Ubuntu; la matriz Windows/Linux está planificada en el roadmap.

Publicación de documentación

En pull requests se construyen ambos idiomas sin desplegar. En pushes a master, el job genera un único artefacto con español en / e inglés en /en/; el job deploy lo publica mediante el environment github-pages y OIDC.

La primera vez, un administrador debe configurar:

  1. Settings → Pages → Build and deployment → Source → GitHub Actions.
  2. Settings → Security → Code security and analysis → Dependency graph.

Sin Pages habilitado, configure-pages devuelve Not Found. Sin Dependency Graph, Dependency Review no puede comparar manifests. Ninguno de los dos casos se arregla agregando un PAT.

Dependabot

Dependabot revisa semanalmente:

  • pip: agrupa actualizaciones minor/patch, ignora majors automáticos y limita cinco PR abiertos;
  • GitHub Actions: actualiza acciones y limita cinco PR abiertos.

Una actualización mayor debe revisarse manualmente por compatibilidad. Que un PR provenga de Dependabot no sustituye CI, revisión de changelog ni validación de comportamiento.

Publicación en PyPI

El proyecto se distribuye como aplicación CLI. El workflow solo acepta tags que coincidan exactamente con v<project.version>, construye wheel y sdist en aislamiento y comprueba que el entry point, dashboard, plantilla Compose y ejemplo de configuración estén incluidos.

Antes de cada publicación, un administrador debe:

  1. confirmar los metadatos AGPL-3.0-or-later y el archivo LICENSE;
  2. mantener protegido el environment pypi en GitHub;
  3. mantener el Trusted Publisher de PyPI restringido a este repositorio y workflow;
  4. revisar la versión y crear el tag correspondiente, por ejemplo v0.2.1.

Trusted Publishing usa OIDC y evita almacenar un token PyPI en GitHub Secrets. El dashboard también muestra el aviso AGPL y un enlace al código fuente para usuarios remotos.

Comprobaciones locales equivalentes

python -m pytest -m "not docker"
python -m ruff check .
node --check src/mini_runbot/web/app.js
python -m build
python scripts/check_distribution.py dist
python scripts/check_docs.py
python -m mkdocs build --strict --config-file gh-docs/mkdocs.es.yml --site-dir ../site
python -m mkdocs build --strict --config-file gh-docs/mkdocs.en.yml --site-dir ../site/en
git diff --check

Cobertura y límites

  • CodeQL es análisis estático; no demuestra aislamiento contra repositorios hostiles.
  • Dependency Review solo evalúa cambios presentes en el PR y requiere datos de GitHub.
  • El E2E Docker se ejecuta localmente con opt-in; un workflow manual/programado está planificado.
  • Mermaid se renderiza en el navegador, por lo que el build MkDocs valida el bloque pero no toda la semántica gráfica.

Archivos relacionados