fn_registry/dev/flows/0006-metabase-versioning.md

name, id, status, created, updated, priority, risk, related_issues, apps, trigger, schedule, expected_runtime_s, tags

name	id	status	created	updated	priority	risk	related_issues	apps	trigger	schedule	expected_runtime_s	tags
metabase-versioning	0006	pending	2026-05-16	2026-05-16	medium	medium		auto_metabase dag_engine agents_and_robots	cron	0 2 * * *	60	metabase sync gitops backup

Goal

Probar flujo INVERSO al tipico: extraer estado de un servicio interno (Metabase) y persistirlo como codigo. Sirve de backup + auditoria + reproducibilidad.

Pre-requisitos

• Metabase corriendo (local docker o produccion).
• auto_metabase configurado con credenciales (METABASE_URL, METABASE_TOKEN).
• projects/metabase_registry/ existe con sub-repo git inicializado.

Flow

1. DAG metabase-snapshot.yaml diario 02:00:

   name: metabase-snapshot
   schedule: "0 2 * * *"
   steps:
     - name: pull_metabase
       function: auto_metabase_pull_bash_pipelines
       args: ["--target", "projects/metabase_registry"]
     - name: git_diff_check
       command: cd projects/metabase_registry && git diff --stat
     - name: commit_if_changes
       command: |
         cd projects/metabase_registry
         git add -A
         if ! git diff --cached --quiet; then
           git commit -m "snapshot: $(date -u +%FT%TZ)"
           git push origin master
           echo "CHANGES_PUSHED"
         else
           echo "NO_CHANGES"
         fi
       depends: [pull_metabase]
     - name: notify
       function: matrix_send_message_<id>
       args: ["#fn-registry-ops", "Metabase snapshot: <stdout from prev step>"]
       depends: [commit_if_changes]
   

2. data_factory: node metabase_snapshot kind=extractor (source=metabase). Tag gitops.
3. Verificar que YAML files generados son legibles y diff-friendly.

Acceptance

• DAG corre 3 dias consecutivos sin error.
• >=1 commit registrado en repo metabase_registry.
• data_factory.runs muestra historico.
• Matrix recibe 1 mensaje/dia (con "NO_CHANGES" o "CHANGES_PUSHED").
• Si se rompe un dashboard manualmente en Metabase -> push de YAML viejo lo restaura (test).

Telemetria esperada

• 1 run/dia en data_factory.
• 7 commits en metabase_registry repo (1 semana baseline).

Definition of Done

Ver README.md seccion DoD + user-facing.

Generico

• Repetibilidad: cron diario 02:00 corre 7 dias consecutivos sin error.
• Observabilidad: data_factory.runs + 1 commit en repo metabase_registry por dia (o NO_CHANGES).
• Error-path: token Metabase expirado → healthcheck pre-pull falla con mensaje claro, no silencio.
• Idempotencia: NO_CHANGES no genera commit vacio en git.
• Secrets: token Metabase en pass metabase/api-token.
• Docs: ## Notas con onboarding + rollback procedure.
• Registry-first: pull/diff/push reusan funciones registry.
• INDEX + status: status: done + INDEX + movido.

User-facing

• User-facing: usuario navega a https://gitea.../dataforge/metabase_registry/commits/master → ve commits diarios con diff YAML de dashboards/cards.
• User-facing repeat: misma URL manana muestra commit nuevo (o NO_CHANGES skip); rollback con click derecho en commit → restore.
• User-facing onboarding: parrafo en ## Notas: "Para auditar cambios Metabase: abrir Gitea repo dataforge/metabase_registry. Rollback: revertir commit en Gitea → push trigger DAG manual → Metabase restaurado. Matrix bot diario en #fn-registry-ops a las 09:00."
• User-facing latencia: cambio manual en Metabase → commit visible al dia siguiente 02:00.

Custom

• Rollback E2E probado: revertir commit → siguiente run aplica YAML viejo → Metabase restaura dashboard.
• Diff YAML estable: keys ordenadas, no churn aleatorio.
• Dashboards eliminados → commit DELETED:, no tombstone huerfano.
• Backup adicional a vault (no solo git).

Notas

• Riesgo: si Metabase token expira, el DAG falla silenciosamente. Anadir healthcheck pre-pull.
• Restore es manual hoy. Futuro: comando auto_metabase push --from-commit <SHA>.