mcpField
C
circleci-config

circleci-config

github.com/circleci-publicクラウド・DevOps769 回インストール1 週間前に更新
リポジトリ

circleci-config について

circleci-configは、測定したボトルネックに基づき、段階的な設定変更でCircleCIの性能と安定性を改善するスキルです。開発者向けに、問題分析から安全な調整、効果検証までを案内します。

主な機能

  1. 01ジョブ時間と失敗率の基準測定
  2. 02重複ジョブとワークフローの削除
  3. 03キャッシュと成果物フローの調整
  4. 04ボトルネックに絞った並列化
  5. 05検証とロールバック基準の設定

活用シーン

  1. 01遅い、または不安定なCircleCIジョブの調査
  2. 02依存関係キャッシュのヒット率改善
  3. 03重複するビルドとテスト作業の削減

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/circleci-public/skills --skill circleci-config

インストール後、Claude Code で/circleci-configを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

references/
cache-optimization.md
patterns.md
persisting-data.md
test-results.md

詳細

CircleCI Config

概要

このスキルを使って、プロダクトの動作を変えずに CircleCI のパフォーマンスと安定性を改善します。まず実測したボトルネックに注目し、明確な検証基準を定めたうえで、安全な設定変更を最小限実施します。

リクエストに save_cache、restore_cache、persist_to_workspace、attach_workspace、キャッシュキーの設計、依存関係のキャッシュ、ロックファイル、またはキャッシュヒット率の低さ、キャッシュサイズの過大さ、不要な永続化ステップに関する問題が含まれる場合は、references/cache-optimization.md を読んでください。 リクエストにキャッシュ、ワークスペース、アーティファクトの使い分け、またはジョブ間のデータ転送の非効率さが含まれる場合は、references/persisting-data.md を読んでください。 リクエストにテストジョブの遅さ、並列処理、テストの所要時間、または JUnit XML の不足が含まれる場合は、references/test-results.md を読んでください。 リクエストに承認、ブランチ/タグのフィルター、スケジュール、デプロイフローの構造、または環境昇格のパターンが含まれる場合は、references/patterns.md を読んでください。

収集する入力情報

  • .circleci/ 内の .yaml および .yml ファイルと、再利用可能な設定フラグメント
  • 現在の課題:所要時間、不安定さ、コスト、保守性
  • ベースライン指標:最も遅いジョブ、再試行/失敗の頻度、キュー時間と実行時間
  • 構造変更に対するリスク許容度

ワークフロー

  1. ベースラインを作成します。
    • 所要時間が最も長いジョブ上位 1~3 件と、不安定なジョブを特定します。
    • 変更前の指標(所要時間、合格率、再試行回数)を記録します。
  2. パイプラインの無駄を取り除きます。
    • 重複するジョブ/ワークフローを排除します。
    • ブランチ/タグのフィルターとワークフロートリガーを適切に絞り込みます。
  3. 依存関係とアーティファクトの流れを改善します。
    • 決定的なロックファイルのチェックを含むようにキャッシュキーを修正します。
    • ワークスペース/アーティファクトを使い、同一の出力を再ビルドしないようにします。
    • 範囲が狭く、再現可能で、復元コストの低いキャッシュスコープを優先します。
  4. 安全な並列処理を適用します。
    • 実証済みのボトルネックのみを並列化します。
    • ファンアウト/ファンインを読みやすく、決定的な状態に保ちます。
  5. 影響を検証します。
    • 最終決定の前に、期待する指標の変化と受け入れ基準を定義します。

ガードレール

  • アプリケーションコードの変更を提案する前に、設定の修正を優先します。
  • 決定的な失敗を隠すために、一律の再試行を追加しないでください。
  • ビルド/テストの各段階を最適化する際も、デプロイの安全ゲートを維持します。
  • 変更は段階的に行い、簡単に元に戻せるようにします。
  • 広範なプロジェクト全体のスナップショットより、言語固有のキャッシュディレクトリを優先します。
  • ユーザーが実質的に書き込み専用のキャッシュを明示的に求めている場合を除き、実行ごとにローテーションするキャッシュキーは避けます。

出力要件

以下を提示します。

  1. ベースラインのボトルネック概要。
  2. 提案または適用した設定変更とその理由。
  3. 実行時間/信頼性への期待される影響。
  4. 検証計画とロールバックに関する注記。

コメント