circleci

Gunakan saat menulis, mengedit, atau meninjau konfigurasi CircleCI untuk repositori Astronomer APC. Mencakup pengorganisasian skrip, skrip inline vs eksternal, dan…

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

Lebih banyak skill dari 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
Ekstraktor OpenLineage kustom untuk operator Airflow yang tidak didukung dan skenario lineage yang kompleks. Dua pendekatan: tambahkan metode OpenLineage langsung ke operator yang Anda miliki (direkomendasikan), atau buat ekstraktor kustom untuk operator pihak ketiga yang tidak dapat Anda modifikasi. Ekstraktor mencegat eksekusi operator di tiga titik: sebelum eksekusi untuk lineage statis, setelah sukses untuk output yang ditentukan saat runtime, dan opsional setelah kegagalan untuk lineage parsial. Daftarkan ekstraktor melalui airflow.cfg atau lingkungan...
debugging-dags
astronomer
Analisis akar penyebab sistematis dan perbaikan untuk DAG Airflow yang gagal dengan alur investigasi terstruktur. Memandu melalui proses diagnosis empat langkah: mengidentifikasi kegagalan, mengekstrak detail kesalahan, mengumpulkan informasi kontekstual, dan memberikan langkah perbaikan yang dapat ditindaklanjuti. Mengkategorikan kegagalan ke dalam empat jenis (data, kode, infrastruktur, ketergantungan) untuk memfokuskan investigasi dan menyarankan perbaikan yang sesuai. Menyediakan perintah CLI siap pakai untuk pengambilan log, perbandingan proses, pembersihan tugas, dan 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
Menyebarkan DAG dan proyek Airflow. Gunakan saat pengguna ingin menyebarkan kode, mendorong DAG, menyiapkan CI/CD, menyebarkan ke produksi, atau bertanya tentang strategi penyebaran…
deploying-go-sdk-bundles
astronomer
Membangun, mengemas, dan menyebarkan bundel Airflow Go SDK yang telah dikompilasi agar ExecutableCoordinator dapat menjalankannya. Gunakan ketika pengguna ingin mengompilasi bundel tugas Go, meminta…
testing-dags
astronomer
Siklus uji-debug-perbaikan iteratif untuk DAG Airflow dengan diagnosis kegagalan yang komprehensif. Mulai dengan af runs trigger-wait <dag_id> untuk menjalankan DAG dan menunggu hingga selesai; tidak diperlukan pemeriksaan awal. Jika gagal, gunakan af runs diagnose untuk ringkasan kegagalan yang komprehensif dan af tasks logs untuk memeriksa detail kesalahan dari tugas tertentu. Mendukung konfigurasi kustom, batas waktu, dan percobaan ulang; menangani skenario sukses, gagal, dan batas waktu dengan interpretasi respons yang jelas. Validasi cepat tersedia...
tracing-downstream-lineage
astronomer
Lacak lineage data hilir untuk menilai dampak perubahan sebelum memodifikasi tabel atau DAG. Mengidentifikasi konsumen langsung dari tabel atau DAG target melalui pencarian kode sumber, dependensi tampilan, dan koneksi alat BI. Membangun pohon dependensi lengkap yang memetakan semua dampak hilir, dari tabel hingga dasbor hingga model ML. Mengkategorikan dependensi berdasarkan tingkat kepentingan (kritis, tinggi, sedang, rendah) untuk memprioritaskan komunikasi pemangku kepentingan dan pengujian. Menghasilkan laporan dampak dengan penilaian risiko, yang terpengaruh...