CreaRack-SL

Feature: Herramienta de frescura de dependencias (s93)

Vista limpiaEditar
Funcionalidadactivecreado Thu May 28#ci#devops#feature#dependency-management#tooling#observability

Descripción general

Sesión 93: herramienta interna que da visibilidad única sobre el estado de frescura de las dependencias de terceros en dos repositorios (CreaRack-Pro + CreaRackSL-Workspace).

Muestra, de un vistazo, qué librerías se han quedado viejas sin necesidad de Dependabot ni Renovate:

  • Versión pineada (del manifiesto)
  • Versión instalada (del lockfile o CI)
  • Versión última (consultada en vivo en PyPI/npm)
  • Desfase semver (major/minor/patch) con alertas visuales por severity

Ordena por mayor desfase primero.

Motivación

No había detección automatizada de dependencias desactualizadas. Con ~112 deps (22 major desactualizadas al día de entrega), el riesgo de quedar peligrosamente atrás era alto.

Alcance en s93

CreaRack-Pro (este repo)

  • scripts/deps_freshness.py (353 LOC, stdlib puro)

    • Parsea manifiestos sin hardcodeo: requirements.txt, frontend/package.json, terminal/agent/requirements-agent.lock
    • Resuelve instaladas de pip-list.json, lockfiles, pnpm-list.json
    • Consulta PyPI/npm JSON APIs (nunca caché de modelo LLM)
    • Calcula desfase semver e publica en el Workspace

  • .github/workflows/deps-freshness.yml (121 LOC)

    • Cron semanal lunes 06:30 UTC
    • Triggers: push a manifiestos, workflow_dispatch manual
    • Setup backend (pip) + workspace (pnpm) en CI
    • Ejecuta colector y publica snapshot en POST /api/tools/deps

Workspace (repo separado, PR propio)

  • Tool /tools/deps (página web)
  • Endpoint GET/POST /api/tools/deps
  • Tabla D1 deps_freshness
  • 2 guías wiki: feature coloquial + runbook técnica

Manifiestos cubiertos

RepoRutaEcosistema
CreaRack-Prorequirements.txtPyPI
CreaRack-Profrontend/package.jsonnpm
CreaRack-Proterminal/agent/requirements-agent.lockPyPI (lockfile 100% ==)
CreaRack-Protests/requirements.txtPyPI (is_dev=1, desde 11-07-2026)
CreaRack-Protests/parity_validation/requirements.txtPyPI (is_dev=1, desde 11-07-2026)
Workspacepackage.jsonnpm

Desde el 28-08-2026 las filas se deduplican por (repo, ecosistema, paquete): un paquete que aparece en varios de estos manifiestos sale una sola vez, con la horquilla más restrictiva, y la fila lista el resto en el campo manifests.

Flujo de datos

┌─ CreaRack-Pro/main
│  ├─ requirements.txt ─┐
│  ├─ frontend/package.json ├─> scripts/deps_freshness.py
│  ├─ terminal/agent/requirements-agent.lock ─┤ (+ deps_specs.py, deps_sources.py)
│  ├─ tests/**/requirements.txt ──────────────┤ • latest + versiones via PyPI/npm
│  └─ Workspace/package.json ─────────────────┘ • resuelve cada horquilla
│                                                • "instalada": PROD → CI → lock
│  Fuentes de "instalada", por orden:
│   1. PROD   GET crearack.com/api/installed-packages  (Bearer INTERNAL_TOOLS_TOKEN)
│   2. runner pip list / pnpm list del job de CI       (respaldo)
│   3. lock   package-lock.json · requirements-agent.lock
│
│  .github/workflows/deps-freshness.yml
│  └─> POST /api/tools/deps (Workspace) ──────────────────┐
│                                                            │
└──────────────────────────────────────────────────────────┤
                                                            │
                                          Workspace/D1 table
                                          deps_freshness
                                               │
                                               v
                                        /tools/deps (UI)
                                        ┌────────────────────────────┐
                                        │ PKG | PEDIDA | EN USO | LAG│
                                        │ django | ==6.0.8 | prod |  │
                                        │ ...                        │
                                        └────────────────────────────┘

Desde el 28-08-2026 (task #275) la columna «en uso» sale por defecto del contenedor de producción, no de lo que resuelve el runner: el colector consulta GET /api/installed-packages (endpoint interno de Django, Bearer INTERNAL_TOOLS_TOKEN, mismo patrón que /openapi-export) y guarda en installed_source de dónde vino cada valor (prod / runner / lockfile). Falla suave: si PROD no contesta, la pasada sigue con el respaldo del runner. El paso «Probe PROD installed packages» del workflow (continue-on-error) deja el código HTTP en el log.

Datos de entrada / verificación en local

Dry-run real (28-05-2026):

112 dependencias · major=22 · minor=25 · patch=17 · unknown=0 · uptodate=48

Cronograma

  • Semanal: lunes 06:30 UTC (cron)
  • Al toque: push a main + manifiesto
  • Manual: GitHub Actions UI

Reglas aplicadas

  • Regla 15 (HTTP 200 ≠ éxito): validación del body en respuesta de /api/tools/deps
  • Regla 17 (cloud, no PC): todo ejecutable en GitHub Actions, nunca requiere acción manual en PC

Fase 2

  • Eje CVE: cruce con OSV (Open Source Vulnerabilities) HECHO 11-07-2026 — ver [[feature—harness—osv-security-deps-freshness]].
  • Motor fiable: horquillas resueltas a la versión que de verdad se instala, «instalada» desde PROD, aviso de horquillas sin techo y si el arreglo cabe en el pin HECHO 28-08-2026 (task #275, scripts/deps_specs.py + scripts/deps_sources.py, 38 casos en tests/scripts/test_deps_freshness.py).
  • Botón Context7: “ver cambios” por fila → guía de migración IA-asistida (pendiente)
  • Integración Pulse/alertas: señal crítica si major ≥ 5 paquetes sin actualizar >6 meses (pendiente)

Complementaridad con otras herramientas

  • Dependabot: no instalado en este proyecto
  • Renovate: no instalado
  • agent-pip-audit.yml: eje ortogonal — CVEs vs frescura. Ambos necesarios.

Véase también

  • [[entity—ci—service—deps-freshness-collector]]
  • [[entity—ci—workflow—deps-freshness]]
  • [[concept—infra—dependency-management]]
  • [[concept—saas—observability]]
  • [[concept—ci—automation]]

Referenciado desde

Inicio
Yo