circleci

À utiliser lors de l'écriture, de la modification ou de la révision de la configuration CircleCI pour le dépôt Astronomer APC. Couvre l'organisation des scripts, les scripts en ligne vs externes, et…

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

CircleCI Configuration Guide

Critical Rules

  1. No long inline scripts — script logic for any language must not be written inline in .circleci/config.yml if the script has complicated flow control. Complicated scripts belong in bin/.
  2. Scripts live in bin/ — every script called from CircleCI must exist as a file in the bin/ directory with an appropriate extension (e.g. bin/my-script.sh, bin/my-script.py).
  3. Pin all versions — never use latest or unpinned tags for Docker images or installed tools. Always specify an exact version to prevent supply chain vulnerabilities and ensure reproducible builds.

Script Organization

Scripts invoked by CircleCI jobs must be committed to the repository under bin/ so they can be:

  • Linted and reviewed like any other source file
  • Tested and run locally without needing CI
  • Reused across multiple jobs or workflows
# ✅ CORRECT — call a script from bin/
steps:
  - run:
      name: Build Helm chart
      command: bin/build-helm-chart.sh
# ❌ WRONG — inline shell logic in the CircleCI config
steps:
  - run:
      name: Build Helm chart
      command: |
        helm package .
        mv astronomer-*.tgz /tmp/chart/

Config Generation Pipeline

.circleci/config.yml is never edited directly. It is a generated file produced by rendering the Jinja2 template .circleci/config.yml.j2 via bin/generate_circleci_config.py:

# Regenerate config.yml from the template
uv run bin/generate_circleci_config.py

The generator injects a small set of computed variables (e.g. ci_runner_version, kube_versions, machine_image_version, docker_images) into the template at render time. Always edit .circleci/config.yml.j2, then regenerate.


Version Pinning

Always pin exact versions for Docker images and any tools installed during a job. Using latest or loose tags introduces supply chain risk and makes builds non-reproducible.

All pinned versions must be declared as Jinja2 variables at the top of .circleci/config.yml.j2, not scattered inline throughout the file. This makes them easy to audit and update in one place. All version declarations must include a link to where the list of released versions can be found, so that updating them is straightforward and doesn't require searching online to find more recent releases.

{# ✅ CORRECT — versions declared at top of config.yml.j2 #}
{#- https://circleci.com/docs/guides/execution-managed/building-docker-images/#docker-version -#}
{%- set circleci_docker_version = 'docker23' -%}

{#- https://circleci.com/developer/machine/image/ubuntu-2404 -#}
{%- set machine_image_version = 'ubuntu-2404:2025.09.1' -%}
# Then referenced inline:
docker:
  - image: cimg/python:{{ python_image_version }}
# ❌ WRONG — version hardcoded inline, not declared at top
docker:
  - image: cimg/python:3.8.1
# ❌ WRONG — unpinned image
docker:
  - image: cimg/python:latest
# ✅ CORRECT — pinned tool version installed in a step
- run:
    name: Install helm
    command: bin/install-ci-tools.py 3.17.2

# ❌ WRONG — unversioned tool install
- run:
    name: Install helm
    command: curl https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash

Plus de 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
Extracteurs OpenLineage personnalisés pour les opérateurs Airflow non pris en charge et les scénarios de lignage complexes. Deux approches : ajouter des méthodes OpenLineage directement aux opérateurs que vous possédez (recommandé), ou créer des extracteurs personnalisés pour les opérateurs tiers que vous ne pouvez pas modifier. Les extracteurs interceptent l'exécution des opérateurs à trois moments : avant l'exécution pour le lignage statique, après le succès pour les sorties déterminées à l'exécution, et optionnellement après l'échec pour un lignage partiel. Enregistrez les extracteurs via airflow.cfg ou l'environnement...
debugging-dags
astronomer
Analyse systématique des causes profondes et correction des DAG Airflow défaillants, avec des flux d'investigation structurés. Guide à travers un processus de diagnostic en quatre étapes : identifier l'échec, extraire les détails de l'erreur, rassembler les informations contextuelles et fournir des étapes de correction exploitables. Classe les échecs en quatre types (données, code, infrastructure, dépendance) pour cibler l'investigation et suggérer les correctifs appropriés. Fournit des commandes CLI prêtes à l'emploi pour la récupération des logs, la comparaison des exécutions, l'effacement des tâches et des 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
Déployer des DAGs et projets Airflow. Utiliser lorsque l'utilisateur souhaite déployer du code, pousser des DAGs, configurer CI/CD, déployer en production, ou demande des stratégies de déploiement…
deploying-go-sdk-bundles
astronomer
Construit, empaquette et déploie des bundles compilés du SDK Go Airflow afin que l'ExecutableCoordinator puisse les exécuter. À utiliser lorsque l'utilisateur souhaite compiler un bundle de tâches Go, demande…
testing-dags
astronomer
Cycles itératifs de test-débogage-correction pour les DAGs Airflow avec diagnostic complet des échecs. Commencez par af runs trigger-wait <dag_id> pour exécuter un DAG et attendre son achèvement ; aucune vérification préalable nécessaire. En cas d'échec, utilisez af runs diagnose pour un résumé complet des échecs et af tasks logs pour inspecter les détails des erreurs de tâches spécifiques. Prend en charge la configuration personnalisée, les délais d'attente et les tentatives de réessai ; gère les scénarios de succès, d'échec et de dépassement de délai avec une interprétation claire des réponses. Validation rapide disponible...
tracing-downstream-lineage
astronomer
Tracer la lignée des données en aval pour évaluer l'impact des modifications avant de modifier des tables ou des DAG. Identifie les consommateurs directs d'une table ou d'un DAG cible via la recherche dans le code source, les dépendances de vues et les connexions aux outils BI. Construit un arbre de dépendances complet cartographiant tous les impacts en aval, des tables aux tableaux de bord en passant par les modèles ML. Catégorise les dépendances par criticité (critique, élevée, moyenne, faible) pour prioriser la communication avec les parties prenantes et les tests. Génère un rapport d'impact avec évaluation des risques, éléments affectés...