これはブループリントの完全なフィールドリファレンスです。ブループリントの概要と、Devin の環境内でどのように機能するかについては、宣言的
環境設定を参照してください。
概要
runs-on および includes フィールド、組織レベルおよび Enterprise レベルのブループリント向けの post-build セクション、リポジトリレベルのブループリント向けの clone セクションで構成されています：
すべてのセクションは任意です。任意の組み合わせで含めることができます。
initialize はフルビルド時およびゼロから再構築されるワークスペースに対して実行されます。結果はスナップショットに保存されます。差分ビルド では、継承されたワークスペースは initialize を skip し、最新のコードを pull して、maintenance のみを実行します。maintenance は、それ単体で完結し、既存のスナップショット上で独立して実行できるように記述してください。直前に initialize の実行が必要にならないようにし、initialize が以前に $ENVRC に書き込んだ 環境変数 に依存しないようにしてください。各セッションの開始時には、maintenance コマンドは 自動実行されません。代わりに、必要に応じて (たとえば最新のコードを pull した後に) どの依存関係コマンドを実行すべきかをエージェントが把握できるよう、前提情報として提示されます。コマンドは高速で、差分的に実行できるものにしてください。ビルドは ブループリント が変更されたときと、定期的 (約 24 時間ごと) に自動実行されます。
initialize
initialize は、コードの特定の状態に依存しないツールやランタイム (言語ランタイム、システムパッケージ、グローバル CLI など) をインストールする際に利用します。
シンプルな形式
構造化された形式
run を含む 1 つのステップと同等です。
initialize と maintenance の使い分け
どちらのセクションもフルビルド中に実行されます。差分ビルドでは、継承されたワークスペースは最新のコードを取得した後、
initialize をスキップし、maintenance のみを実行します。ツールやランタイムは initialize に、コードのロックファイルに追従する依存関係コマンドは maintenance に入れます。
maintenance
maintenance は、コードのクローン後に実行する依存関係のインストールやその他のコマンドに利用します。これらのコマンドはビルド中に実行され、セッション開始時にエージェントにも共有されるため、依存関係が変更された場合はエージェントが再実行できます。npm install、pip install、uv sync などのコマンドはここに含めます。
リポジトリレベルのブループリントでは、
maintenance コマンドはリポジトリのルートディレクトリで実行されます。org レベルのブループリントでは、ホームディレクトリ (~) で実行されます。knowledge
knowledge セクションは実行されません。これは、Devin がプロジェクトで作業する際に参照する情報です。ここでは、lint、テスト、ビルド、その他のプロジェクト固有のワークフローで使用する正しいコマンドを Devin に伝えます。
name フィールドはラベルです。慣例として、lint、test、build が標準的な名前です。Devin は自身の作業を検証する際に、これらを参照します。任意のカスタム名で、追加の Knowledge アイテムを作成できます。
runs-on
runs-on フィールドには、文字列または文字列のリストを指定できます。デフォルト値は ["default"] です。default および linux ラベルは、大文字と小文字を区別しない、デフォルトの Linux プラットフォームの別名です。その他のラベルは、windows など、アカウントに登録されているマシン構成と一致する必要があります。
ブロックに複数のプラットフォームラベルを指定すると、Devin はプラットフォームごとに 1 つのスナップショットのビルドを作成し、各プラットフォームで同じステップを実行します。同じファイル内の 2 つのブロックを同じプラットフォームに解決することはできません。これには default と linux の別名も含まれます。
プラットフォーム固有のセットアップおよび Windows サポートについては、Windows サポートを参照してください。
includes
includes フィールドは、Git連携のブループリントでのみ使用できます。Devin は、リポジトリのルートにある .devin/blueprint.yaml ファイルを検出したときにこのフィールドを解決します。Settings エディタで作成されたブループリントでは無視され、インクルード先のワークスペースのブループリントでは使用できません。
文字列または文字列のリストを指定できます。各エントリにはワークスペースのサブディレクトリを指定します。Devin は <dir>/.devin/blueprint.yaml を探します。完全なファイルパスを指定することもできます。パスに .. を含めることはできません。
ネストされたインクルードは許可されず、各ワークスペースパスは1回しか指定できません。インクルード先のファイルが存在しない場合、Devin はそのワークスペースを削除されたものとして扱います。
post-build
post-build セクションは、組織レベルおよび Enterprise レベルのブループリントでのみ利用できます (リポジトリレベルのブループリントではサポートされていません) 。このセクションのステップは、ビルド中にすべてのリポジトリのクローンと、それらの initialize ステップおよび maintenance ステップの完了後、ヘルスチェックとスナップショットイメージの作成より前に実行されます。そのため、環境全体が組み上がった状態を必要とする、リポジトリ横断の検証やヘルスチェックに適しています。
環境全体がそろった状態でビルドの後半に実行されるため、post-build ステップでは、クローンされたすべてのリポジトリと、Enterprise、組織、リポジトリの各ブループリントによってインストールされたすべてのツールを参照できます。
post-build ステップでは、initialize や maintenance と同じ step types (シェルの run コマンドと GitHub Actions の uses) を使用し、ホームディレクトリ (~) から実行されます。clone
cloneセクションで、Devin がリポジトリをスナップショットにクローンする際に使われるデフォルト設定を上書きできます。すべてのフィールドは省略可能で、指定しない場合は現在の動作を維持する適切なデフォルト設定が適用されます。
clone は リポジトリレベル ブループリントでのみ有効です。これは、その特定のリポジトリを スナップショット にどのようにクローンするかを制御します。組織レベル または Enterprise レベル のブループリントでは効果はありません。step types
initialize、maintenance、または post-build の各ステップでは、シェルコマンド (run) または GitHub Actions (uses) の 2 種類のいずれかを利用します。
省略記法と検証ルール
- 文字列のみで指定したセクションは、単一の
runステップとして扱われます。 - 文字列のみで指定したリスト項目は、
runステップとして扱われます。 - ステップには
runまたはusesのいずれかを定義する必要があり、両方を定義することはできません。 withはusesステップでのみ有効です。- すべての
with値は文字列に変換されます。action が文字列を想定している場合は、数値を引用符で囲んでください。
YAML ドキュメントのルール
--- ドキュメントは YAML マッピングである必要があります。トップレベルのシーケンスは拒否され、each YAML document must be a mapping, not a sequence; use '---' to separate multiple blocks というエラーが表示されます。
シェルコマンド (run)
実行の詳細:
- コマンドは bash で実行されます。複数行スクリプト内のいずれかのコマンドが失敗すると、そのステップ全体が直ちに停止します。
- org レベルのブループリントはホームディレクトリ (
~) で実行されます。 - リポジトリレベルのブループリントは、クローンされたリポジトリのルートディレクトリで実行されます。
- 各ステップのタイムアウトは 1 時間です。
- シークレットは自動的に環境変数として利用できます。
GitHub Actions (uses)
Action 参照形式:
github.com/ プレフィックスと @<ref> サフィックスは、どちらも必須です。ref は通常、v5 のようなバージョンタグです。
よく利用されるアクション:
with の値の仕組み:
with で渡した値は、GitHub Actions のワークフローと同じ規則に従って、アクションへの入力として与えられます。すべての値は文字列に変換されます。
setup-python は Python の実行ファイルを PATH に追加するため、それ以降のすべてのステップと maintenance で引き続き利用できます。
run と uses: どちらを使うべきか
実際には、ほとんどの設定で、言語ランタイムには
uses を使い、それ以外には run を使います。
環境変数とシークレット
ステップごとの環境変数
env フィールドを使って追加の環境変数を定義できます。
ステップ間の環境変数 ($ENVRC)
$ENVRC ファイルに書き込みます。
$ENVRC に書き込まれた変数は自動的にエクスポートされ、後続のすべての
ステップおよび現在のビルドで生成された Devin セッションで利用できます。これは、
GitHub Actions の $GITHUB_ENV と同様の仕組みです。
これは PATH にも当てはまります。標準的でないディレクトリにツールをインストールした場合
(/usr/bin または /usr/local/bin 以外の場所) 、後続のステップやリポジトリレベルのブループリントが
そのバイナリを見つけられるよう、$ENVRC に追記してください。
run: ブロック内で単に export PATH=... を実行しても、影響するのはそのステップのシェルだけです。
各ステップは新しいシェルプロセスを開始するため、$ENVRC に書き込まれない
PATH の変更は失われます。
uses: actions (例: actions/setup-node) は、追加した PATH を自動的に $ENVRC
に反映します — これを手動で行う必要があるのは run: ステップだけです。$ENVRC は、差分ビルド を含むすべてのビルドの開始時にリセットされます。
あるビルド中に書き込まれた値は、次のビルドでは利用できません。特に、
継承された ワークスペース は maintenance のみを実行するため、親
ビルドで initialize が $ENVRC に書き込んだ PATH やその他の変数は利用
できません。maintenance に必要な環境は、
maintenance 自体の中で設定してください。
シークレット
$MY_SECRET) 。
シークレットは、ビルド中に各ステップが実行される前に毎回注入され、さらに 各セッションの開始時にも再度注入されます。シークレット自体はスナップショットイメージから除去されるため、認証情報が保存済みのマシンイメージに埋め込まれることはありません。
- 組織のシークレット: 組織内のすべての ブループリント にあるすべてのステップで、環境変数として利用できます。これらは組織全体のブループリントエディタの Secrets タブで設定します。
- Enterprise のシークレット: 組織のシークレットとマージされます (同名のシークレットが競合した場合は、組織のシークレットが優先されます) 。Enterprise 内のすべての組織で利用できます。
- リポジトリのシークレット: リポジトリごとのファイル
/run/repo_secrets/{owner/repo}/.env.secretsに書き込まれます。ビルド中は、そのリポジトリの ブループリント のステップが実行される前に、リポジトリのシークレットが自動的にsourceされます。セッション時には、Devin がそのリポジトリで作業するときにそれらをsourceします。これらは、リポジトリのブループリントエディタの Secrets タブで設定します。
ビルド専用のシークレット: 「build only」としてマークされたシークレットは、スナップショットのビルド中は利用できますが、スナップショットが保存される前に削除されます。これは、ビルド時にのみ必要な認証情報 (例:
initialize 中に非公開アーティファクトをダウンロードする場合) に利用してください。ファイルの添付
.npmrc、settings.xml、設定ファイルなど) をアップロードできます。アップロードされたファイルは ~/.files/ に書き込まれ、各ファイルのパスを指す環境変数が設定されます。
FILE_ が付きます。
ブループリントのステップでファイルを添付する:
Git連携のブループリント
.devin/blueprint.yaml ファイルとして直接保存し、API または UI から同期できます。セットアップ手順と詳細については、Git連携のブループリント を参照してください。
完全な例
ブループリントが階層 (enterprise → org → repo) をまたいでどのように組み合わされるか、ビルド ステータス、リポジトリの状態、再ビルドのトリガーになる条件については、宣言的構成ページのビルドと
セッションを参照してください。