CI/CD para módulos Odoo: tests en Docker

Pipeline con --test-enable, lint y artefactos reproducibles

4 de julio de 2026 por

Atemi, Aitor Atencia

Odoo · DevOps · CI/CD

Un módulo Odoo sin pipeline de CI se prueba "a mano" cada vez, lo que en la práctica significa que se prueba cada vez menos. Levantar un contenedor Docker reproducible con --test-enable y un par de linters convierte cada pull request en una comprobación objetiva, no en un "a mí me funciona en local".

Pipeline

Instalar y testear el módulo en un contenedor limpio

# docker-compose.ci.yml
services:
  odoo:
    image: odoo:19
    depends_on: [db]
    command: >
      odoo -d test_db -i mi_modulo
      --test-enable --stop-after-init
      --log-level=test
  db:
    image: postgres:15
    environment:
      POSTGRES_PASSWORD: odoo

--stop-after-init es imprescindible en CI: sin él, Odoo se queda escuchando peticiones tras terminar la instalación y el pipeline nunca finaliza. El código de salida del proceso es lo que decide si el job pasa o falla.

GitHub Actions

Job mínimo con tests y lint

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Levantar stack y ejecutar tests
        run: docker compose -f docker-compose.ci.yml up --abort-on-container-exit
      - name: Lint con pylint-odoo
        run: pip install pylint-odoo && pylint --load-plugins=pylint_odoo -d all -e odoolint mi_modulo/
      - name: Formato con black
        run: pip install black && black --check mi_modulo/

--abort-on-container-exit propaga el código de salida de Odoo al job de CI; sin ese flag, docker compose up puede devolver éxito aunque los tests internos hayan fallado.

💡 Separa lint de tests en jobs distintos: un fallo de formato no debe tardar lo mismo en reportarse que un fallo de test que necesita levantar la base de datos completa. Ejecutarlos en paralelo acorta el feedback loop del pull request.

Artefactos

Guardar logs y resultados para depurar fallos

      - name: Subir logs si falla
        if: failure()
        uses: actions/upload-artifact@v4
        with:
          name: odoo-test-logs
          path: ./logs/odoo.log

Cuando un test falla en CI pero no en local, el log completo del proceso Odoo suele ser la única pista real: qué módulo se estaba instalando, qué query falló, en qué assert exacto. Sin subir ese artefacto, cada fallo intermitente se investiga a ciegas.

⚠️ Un pipeline verde no certifica un módulo listo para producción: valida lo que los tests cubren. Sin tests de los flujos críticos, un CI en verde solo demuestra que el módulo instala, no que funciona como se espera.

Resumen

Usa el mismo contenedor Docker en CI y en local con --test-enable --stop-after-init, separa lint (pylint-odoo, black) de los tests funcionales, y sube los logs como artefacto cuando algo falla. Un pipeline verde solo es tan bueno como la cobertura real de los tests que ejecuta.

← Scripts de migración Blog Odoo

en Odoo

Scripts de migración: pre_init, post_init y end hooks

Cuándo usar cada hook y cómo migrar datos entre versiones sin perder consistencia