circleci

Use ao escrever, editar ou revisar a configuração do CircleCI para o repositório Astronomer APC. Abrange organização de scripts, scripts inline vs externos e…

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

Mais skills de astronomer

airflow
astronomer
Consulte, gerencie e solucione problemas de DAGs, execuções, tarefas e configuração de sistema do Apache Airflow. Suporta mais de 30 comandos para inspeção de DAGs, gerenciamento de execuções, registro de tarefas, consultas de configuração e acesso direto à API REST. Gerencie múltiplas instâncias do Airflow com configuração persistente; descubra automaticamente implantações locais e Astro. Dispare execuções de DAG de forma síncrona (aguardando conclusão) ou assíncrona, diagnostique falhas, limpe execuções para repetição e acesse logs de tarefas com filtragem por repetição/índice de mapa. Saída...
official
airflow-hitl
astronomer
Portões de aprovação humana, entradas de formulário e ramificações em DAGs do Airflow usando operadores adiáveis. Quatro tipos de operadores: ApprovalOperator para decisões de aprovar/rejeitar, HITLOperator para seleção de múltiplas opções com formulários, HITLBranchOperator para roteamento de tarefas orientado por humanos e HITLEntryOperator para coleta de dados de formulário. Todos os operadores são adiáveis, liberando slots de worker enquanto aguardam resposta humana via a aba Ações Necessárias da interface do Airflow ou API REST. Suporta recursos opcionais incluindo personalização...
official
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…
official
analyzing-data
astronomer
Consulte seu data warehouse para responder perguntas de negócios com padrões em cache e mapeamentos de conceitos. Suporta busca de padrões e cache para tipos de perguntas repetidas, com registro de resultados para melhorar consultas futuras. Inclui cache de mapeamento conceito-tabela e descoberta de esquemas de tabela via INFORMATION_SCHEMA ou grep no código-fonte. Fornece funções de kernel run_sql() e run_sql_pandas() que retornam DataFrames Polars ou Pandas para análise. Comandos CLI para gerenciar caches de conceitos, padrões e tabelas, além de...
official
annotating-task-lineage
astronomer
Anotar tarefas do Airflow com linhagem de dados usando inlets e outlets. Suporta objetos OpenLineage Dataset, Assets do Airflow e Datasets do Airflow para definir entradas e saídas em bancos de dados, data warehouses e armazenamento em nuvem. Use como fallback quando operadores não possuem extratores OpenLineage integrados; segue um sistema de precedência de quatro níveis onde extratores personalizados e métodos OpenLineage têm prioridade. Inclui auxiliares de nomenclatura de datasets para Snowflake, BigQuery, S3 e PostgreSQL para garantir consistência...
official
authoring-dags
astronomer
Fluxo de trabalho guiado para criação de DAGs do Apache Airflow com integração de validação e testes. Abordagem estruturada em seis fases: descobrir o ambiente e padrões existentes, planejar a estrutura da DAG, implementar seguindo as melhores práticas, validar com comandos da CLI af, testar com consentimento do usuário e iterar em correções. Comandos da CLI para descoberta (af config connections, af config providers, af dags list) e validação (af dags errors, af dags get, af dags explore) fornecem feedback imediato sobre a DAG...
official
authoring-go-sdk-tasks
astronomer
Writes Airflow task logic in Go using the Airflow Go SDK. Use when the user wants to implement Airflow tasks in Go, asks about `BundleProvider`/`RegisterDags`,…
official
authoring-java-sdk-tasks
astronomer
Escreve a lógica de tarefas do Airflow em Java, Kotlin ou qualquer linguagem JVM usando o Airflow Java SDK. Use quando o usuário quiser implementar tarefas do Airflow em Java/JVM, pedir…
official