circleci

作成者: astronomer

Astronomer APCリポジトリのCircleCI設定を作成、編集、またはレビューする際に使用します。スクリプトの構成、インラインスクリプトと外部スクリプトの比較などに対応します。

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

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
カスタムOpenLineage抽出器。未対応のAirflowオペレーターや複雑な系列シナリオ向け。2つのアプローチ:所有するオペレーターに直接OpenLineageメソッドを追加する方法(推奨)、または変更できないサードパーティ製オペレーター用にカスタム抽出器を作成する方法。抽出器は3つの時点でオペレーターの実行をインターセプトします:静的な系列のための実行前、実行時に決定される出力のための成功後、およびオプションで部分的な系列のための失敗後。抽出器はairflow.cfgまたは環境変数経由で登録...
debugging-dags
astronomer
失敗したAirflow DAGに対する体系的な根本原因分析と修正、構造化された調査ワークフローを提供。4段階の診断プロセス(障害の特定、エラー詳細の抽出、コンテキスト情報の収集、実行可能な修正手順の提示)をガイド。障害を4つのタイプ(データ、コード、インフラストラクチャ、依存関係)に分類し、調査を集中させ適切な修正を提案。ログ取得、実行比較、タスククリア、DAG...のための即時使用可能なCLIコマンドを提供。
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
AirflowのDAGやプロジェクトをデプロイします。ユーザーがコードのデプロイ、DAGのプッシュ、CI/CDの設定、本番環境へのデプロイ、またはデプロイ戦略について質問した場合に使用します…
deploying-go-sdk-bundles
astronomer
コンパイルされたAirflow Go SDKバンドルをビルド、パッケージ化、デプロイし、ExecutableCoordinatorが実行できるようにします。ユーザーがGoタスクバンドルをコンパイルしたい場合、または…と尋ねた場合に使用します。
testing-dags
astronomer
Airflow DAGに対する反復的なテスト・デバッグ・修正サイクルと、包括的な障害診断を提供します。af runs trigger-wait <dag_id> でDAGを実行し完了を待機します。事前チェックは不要です。失敗時はaf runs diagnoseで包括的な障害サマリーを取得し、af tasks logsで特定タスクのエラー詳細を確認できます。カスタム設定、タイムアウト、リトライ試行に対応。成功、失敗、タイムアウトの各シナリオを明確な応答解釈で処理します。迅速な検証が可能です...
tracing-downstream-lineage
astronomer
テーブルやDAGを変更する前に、下流のデータ系列を追跡して変更影響を評価します。ソースコード検索、ビュー依存関係、BIツール接続を通じて、対象テーブルまたはDAGの直接的な消費者を特定します。テーブルからダッシュボード、MLモデルに至るまで、すべての下流影響をマッピングする完全な依存関係ツリーを構築します。依存関係を重要度(クリティカル、高、中、低)で分類し、ステークホルダーへの連絡とテストの優先順位付けを行います。リスク評価と影響を受けるものを含む影響レポートを生成します。