tools

Úsalo al escribir, editar o revisar herramientas de línea de comandos y scripts auxiliares en este repositorio (las cosas en bin/). Cubre dónde viven las herramientas, el análisis de argumentos con…

npx skills add https://github.com/astronomer/astronomer --skill tools

Writing tools in bin/

Repo tooling (setup scripts, one-off utilities, anything a human or CI invokes directly) lives in bin/ and follows a few rules so tools are discoverable, self-documenting, and safe to run by accident.


Critical Rules

  1. Tools live in bin/ as executable scripts: a shebang (#!/usr/bin/env python3 for Python) plus chmod +x. Python tools run via uv run bin/<tool>.py.
  2. Every tool parses arguments with argparse (or the language equivalent) so --help works and every argument is self-documenting. Parse arguments as the first thing main() does.
  3. --help and insufficient/invalid arguments must do no work. They print usage and exit before any side effect. argparse gives this for free as long as parsing happens before any side-effecting code.
  4. A tool must not perform a destructive or state-mutating operation by default. Merely running it (or running it to read --help) must not create/delete Kubernetes objects, write/delete files, call external services, or change the active context.

Non-destructive by default

The failure mode to design against: someone runs bin/some-tool.py (or bin/some-tool.py --help) expecting it to be inert or to print help, and instead it mutates whatever ambient context it finds — the current kube context, the current directory, a live cluster.

The rule that prevents it: do not give a safe-looking default to any argument that determines where a mutation lands (a namespace, a cluster, a path, a target host). Make those arguments required with no default, so a bare or accidental invocation aborts before doing anything.

With argparse, a required=True argument with no default means:

  • tool (no args) → prints usage to stderr and exits non-zero, before main() reaches any side effect.
  • tool --help → prints help and exits 0.
  • tool --namespace foo ... → runs, because the caller was explicit about the target.

Worked example: bin/setup-forgejo-ca.py

This script creates and deletes Kubernetes Secrets in a cluster. It originally defaulted its namespaces (astronomer, git-forgejo). Running bin/setup-forgejo-ca.py --help to read the help text would instead have run the whole thing against the reader's current kube context — a potentially destructive surprise.

The fix was to make the namespaces required, with no defaults:

def parse_args() -> argparse.Namespace:
    parser = argparse.ArgumentParser(description=__doc__, formatter_class=argparse.RawDescriptionHelpFormatter)
    parser.add_argument("--platform-namespace", required=True, help="...")
    parser.add_argument("--forgejo-namespace", required=True, help="...")
    return parser.parse_args()


def main() -> None:
    args = parse_args()  # aborts here on a bare run or --help, before any kubectl
    ...  # cluster mutations only happen after this line

Now --help and a bare run both abort before touching the cluster, and any real run has to name its target namespaces on purpose.

Automation still works

Making the target arguments required does not break automated callers — it just moves the intent to the caller, where it belongs. The automated invocation passes the values explicitly. For example, the git-sync-private-ca scenario's pre_helm_scripts entry names the namespaces:

pre_helm_scripts:
  - bin/setup-forgejo-ca.py --platform-namespace astronomer --forgejo-namespace git-forgejo

Checklist for a new or edited tool

  • Lives in bin/, is executable, has the right shebang.
  • Uses argparse; --help works and does nothing else.
  • Arguments that decide where a mutation lands are required with no default.
  • Side effects run only after arguments parse successfully.
  • Fails loudly on error (non-zero exit), and is idempotent (safe to re-run) where practical.
  • Callers (CI, scenario manifests, other scripts) pass the required arguments explicitly.

Más skills de astronomer

airflow-state-store
astronomer
Persists task and asset state across retries and DAG runs using Airflow 3.3's AIP-103 key/value stores (`task_state_store`, `asset_state_store`) and the…
creating-openlineage-extractors
astronomer
Extractores personalizados de OpenLineage para operadores de Airflow no soportados y escenarios complejos de linaje. Dos enfoques: agregar métodos de OpenLineage directamente a los operadores que posees (recomendado), o crear extractores personalizados para operadores de terceros que no puedes modificar. Los extractores interceptan la ejecución del operador en tres puntos: antes de la ejecución para linaje estático, después del éxito para salidas determinadas en tiempo de ejecución, y opcionalmente después del fallo para linaje parcial. Registra los extractores mediante airflow.cfg o variables de entorno...
debugging-dags
astronomer
Análisis sistemático de causa raíz y remediación para DAGs de Airflow fallidos con flujos de trabajo de investigación estructurados. Guía a través de un proceso de diagnóstico de cuatro pasos: identificar la falla, extraer detalles del error, recopilar información contextual y entregar pasos de remediación accionables. Clasifica las fallas en cuatro tipos (datos, código, infraestructura, dependencia) para enfocar la investigación y sugerir correcciones apropiadas. Proporciona comandos CLI listos para usar para recuperación de registros, comparación de ejecuciones, limpieza de tareas y DAG...
delegating-to-otto
astronomer
Drives Astronomer's Otto agent (`astro otto`) as a delegated sub-agent for Airflow, dbt, and data-engineering work. Use when the user explicitly asks to "use…
deploying-airflow
astronomer
Desplegar DAGs y proyectos de Airflow. Úsalo cuando el usuario quiera desplegar código, enviar DAGs, configurar CI/CD, desplegar a producción, o pregunte sobre estrategias de despliegue…
deploying-go-sdk-bundles
astronomer
Compila, empaqueta e implementa paquetes compilados del SDK de Airflow Go para que ExecutableCoordinator pueda ejecutarlos. Úsalo cuando el usuario quiera compilar un paquete de tareas de Go, solicite…
testing-dags
astronomer
Ciclos iterativos de prueba-depuración-corrección para DAGs de Airflow con diagnóstico completo de fallos. Comience con af runs trigger-wait <dag_id> para ejecutar un DAG y esperar su finalización; no se necesitan comprobaciones previas. En caso de fallo, use af runs diagnose para obtener un resumen completo del fallo y af tasks logs para inspeccionar los detalles del error de tareas específicas. Admite configuración personalizada, tiempos de espera e intentos de reintento; maneja escenarios de éxito, fallo y tiempo de espera con una interpretación clara de la respuesta. Validación rápida disponible...
tracing-downstream-lineage
astronomer
Rastrea el linaje de datos descendente para evaluar el impacto de cambios antes de modificar tablas o DAGs. Identifica los consumidores directos de una tabla o DAG objetivo mediante búsqueda en código fuente, dependencias de vistas y conexiones de herramientas de BI. Construye un árbol de dependencias completo que mapea todos los impactos descendentes, desde tablas hasta paneles y modelos de ML. Clasifica las dependencias por criticidad (crítica, alta, media, baja) para priorizar la comunicación con las partes interesadas y las pruebas. Genera un informe de impacto con evaluación de riesgos, afectados...