aidentity / index

google/skills · Apache-2.0

managed-airflow-dag-authoring

Provides guidance for authoring Apache Airflow DAGs in Managed Service for Apache Airflow (MSAA; formerly Cloud Composer). Covers environment context discovery, Airflow 2 vs 3 compatibility, authoring best practices, and local/remote validation processes. Use when creating or extending an Airflow DAG. Don't use when authoring Python code unrelated to Airflow DAGs.

cloud stable

Contents

GCP Managed Airflow DAG Authoring Guide

This skill guides you through authoring and validating Apache Airflow DAGs for

Managed Service for Apache Airflow (MSAA; formerly Cloud Composer) environments.


Phase 1: Context Discovery

Before writing any DAG code, you MUST understand the constraints (e.g. version

of Airflow) and capabilities of your target environment if user is willing to

provide them.

1.1 Identify Target Environment & Access

Determine if you have direct access to the target Managed Airflow environment,

local development environment or if you are working offline (only changing local

files without validation).

  • If environment access is available: Use gcloud to inspect the

environment (see Section 1.3).

  • If offline: Rely on user provided details.
1.2 Identify Development Environment

Determine if a local development environment is available.

  • Check if composer-dev CLI is installed.
  • Check if a local Python environment with airflow is available.
1.3 Inspect Target Environment (if available and requested)

Run the following commands to discover version constraints:

  1. Get Airflow/Image Version:

    gcloud composer environments describe {env_name} \
        --location {region} \
        --format="value(config.softwareConfig.imageVersion)"
    

  1. Get Installed Packages (Versions):

    gcloud composer environments describe {env_name} \
        --location {region} \
        --format="value(config.softwareConfig.pypiPackages)"
    

  1. Get DAGs GCS Bucket:

    gcloud composer environments describe {env_name} \
        --location {region} \
        --format="value(config.dagGcsPrefix)"
    


Phase 2: DAG Authoring Best Practices

2.1 General Airflow Best Practices
  • Idempotency: Every task SHOULD be idempotent. Running it multiple times

with the same inputs (e.g., execution date) SHOULD produce the same result

and not duplicate data.

  • No Top-Level Code Execution: Do NOT execute database queries, external

API calls, or heavy computations at the top level of the DAG file (outside

of tasks/operators). This code runs every few seconds during DAG parsing and

will degrade performance.

  • Explicit Catchup: Always set catchup=False in the DAG definition

unless historical backfilling is explicitly required.

  • Use Airflow Variables/Connections: Never hardcode credentials or

environment-specific configs. Use Variable.get() (with

deserialize_json=True if applicable) and BaseHook.get_connection().

Access variables via Jinja templates (e.g., {{ var.value.my_var }}) to

avoid database calls during DAG parsing.

2.2 Airflow 2 vs Airflow 3 Compatibility

Use managed-airflow-migrations skill to navigate adjusting the code to

specific target Airflow version.


Phase 3: Validation Process

You MUST validate DAGs before concluding your task.

3.1 Local Validation (Offline/Pre-deployment)
3.1.1 Static Analysis & Linting

Use ruff or pylint if available.

ruff check path/to/dag.py

  • If targeting Airflow 3, check with Airflow 3 rules if rulesets are

available.

3.1.2 Local Dev Environment (composer-dev)

If the user has composer-dev configured:

  1. Copy the DAG to the local directory with DAGs:

    cp path/to/dag.py $(composer-dev describe {local_env} --format="value(dags_directory)")
    

  1. Verify parsing:

    composer-dev run-airflow-cmd {local_env} dags list-import-errors
    

3.2: Target Environment Validation

Only perform these steps if you have GCP access and are authorized to deploy to

a target environment.

3.2.1 Deploy to GCS

Upload the DAG to the target environment's GCS bucket:

gcloud storage cp path/to/dag.py gs://{target_bucket}/dags/

3.2.2 Verify via Airflow CLI

Wait 1-2 minutes for the scheduler to parse the file, then run:

  1. Check for Import Errors:

    gcloud composer environments run {env_name} \
        --location {region} \
        dags list-import-errors
    

Pass Criteria: Output should be "No data found" or empty.

  1. Verify DAG is Listed:

    gcloud composer environments run {env_name} \
        --location {region} \
        dags list | grep {dag_id}
    

3.2.3 Monitor Cloud Logging

Check for runtime parsing errors in Cloud Logging:

resource.type="cloud_composer_environment"
resource.labels.environment_name="{env_name}"
log_id("airflow-scheduler")
severity>=ERROR
textPayload:"{dag_file_name}"


Definition of Done

  • DAG code adheres to Airflow version constraints of the target environment.
  • DAG code follows best practices (no top-level execution, idempotent if

possible).

  • DAG parses locally without import errors.
  • (If environment is available) DAG is deployed to the target environment and

verified to have no import errors.

Provenance

Authored by Google LLC in google/skills. The content is mirrored here under its upstream license.

Related

agent-platform-alert-configuration Configures best-practice alerting policies for AI agents using OpenTelemetry (OTel) metrics, generating output as Terraform (.tf) configuration files. Use when analyzing, writing, or deploying alerting policies to monitor agent latency, error rates, token usage, and quality metrics. Don't use for standard infrastructure monitoring unrelated to AI agents, or when the agent is not instrumented with OpenTelemetry (for Reliability, Cost, Safety, Security alerts). NOTE: Reliability, Cost, Safety, and Security alerts use generic OTel metrics and work across runtimes (such as Cloud Run, Vertex AI). Quality alerts rely on Vertex AI Online Monitors and are strictly bound to Vertex AI deployments. google/skills Apache-2.0 agent-platform-deploy Deploy open models or custom weights from Model Garden to Agent Platform endpoints, check the status of an in-progress deployment operation, or clean up resources by undeploying models and deleting endpoints. Use when asked to actively deploy a model, list the Model Garden CATALOG of available models, check if a specific model is deployable (`gcloud ai model-garden models list-deployment-config`), query deployment cost, troubleshoot deployment errors (like quota limits), or undeploy/clean up endpoints. Also use when copying and deploying a 1P Tuned Model. Don't use for pure listing/discovery questions of the form "is X deployed?", "list my endpoints", or "which regions have models running?" — for those use `agent-platform-endpoint-management`. Don't use for public Vertex AI deployments (use the `vertex-deploy` skill) or for running model evaluations (use the `agent-platform-eval-flywheel` skill). google/skills Apache-2.0 agent-platform-endpoint-management Manages Agent Platform serving endpoints. Use when you need to create, list, describe, update, or delete serving endpoints for model deployment on Agent Platform. Also use when troubleshooting endpoint permission, quota, or resource busy errors. Don't use for deploying models to endpoints or for running model evaluations. google/skills Apache-2.0 agent-platform-eval-flywheel Measures and improves the quality of AI models and agents on Google Cloud using the Eval Quality Flywheel methodology. Use when evaluating an agent or model, building an eval dataset, picking or writing evaluation metrics, analyzing failures, comparing results before and after a fix, or when guidance is needed on Agent Platform eval methodology — including dataset schema, LLM-as-judge scoring, and common failure causes. For fine-tuning, use agent-platform-tuning. For general production deployment, use agent-platform-deploy. google/skills Apache-2.0 agent-platform-inference Connects to and performs inference with Google Cloud Agent Platform GenAI models, including First-Party Gemini models and Third-Party OpenMaaS models (Llama, DeepSeek, Qwen, etc.). Use when asked to perform inference, ask a model a question, run a test prompt, execute chat completions, or generate code for calling Gemini or OpenMaaS models, authenticate with GenAI SDK, OpenAI SDK, or legacy Agent Platform SDK, configure base URLs and global/regional endpoints, or troubleshoot 429 Resource Exhausted (DSQ), 400 User Validation, or 404 Not Found errors. Don't use for deploying models to endpoints or for running model evaluations. google/skills Apache-2.0