initializeセクションでGitHub Actionsを直接参照できます。Devinはスナップショットのビルド時にそのアクションをダウンロードして実行します。これは、GitHubのCIランナーがアクションのステップを実行するのと同じ仕組みです。
これは、setup-python、setup-node、setup-goのような言語セットアップ用アクションで特に便利です。これらは、バージョン管理やPATHの設定を自動的に処理します。
構文
initialize セクションに uses ステップを追加します:
ステップでは、
run (シェルコマンド) または uses (アクション) のいずれか一方を指定する必要があり、両方は指定できません。アクションの参照形式
github.com/ プレフィックスと @<ref> サフィックスは、どちらも必須です。ref は通常、v5 のようなバージョンタグです。
使用例:
入力の指定
with フィールドを使用します。すべての値は、GitHub Actions の動作に合わせて文字列として扱われます。
環境変数の設定
env フィールドを利用して、1 つのアクションステップのみに適用される環境変数を設定します。
GITHUB_ENV または GITHUB_PATH 経由) は、ブループリント内の以降のステップにも自動的に引き継がれます。
使用例
特定のバージョンを指定した Python プロジェクト
多言語プロジェクト
アクションとシェルコマンドを組み合わせる
Gradle を使用する Java プロジェクト
Actions とシェルスクリプト
- GitHub Actions を使う場合
- 同等のシェルスクリプト
仕組み
usesステップを検出すると、次の処理を行います。
- アクションのリポジトリをダウンロードします (ピン留めされた ref の shallow clone)
- アクションの
action.ymlメタデータを読み取り、アクションの種類 (runs.using) とエントリポイントを特定します INPUT_*、GITHUB_*、RUNNER_*変数を使って実行環境を構築します- 種類に応じてアクションを実行します:
- Node.jsアクション —
preスクリプト (定義されている場合) を実行し、その後mainを実行します - コンポジットアクション —
runs.stepsの各ステップを順に実行します。ネストされたrunおよびusesステップも含まれます - Dockerアクション — アクションの
Dockerfileからイメージをビルド (またはdocker://イメージをプル) し、その後コンテナを実行します。定義されている場合はpre-entrypointも実行します
- Node.jsアクション —
- 副作用を引き継ぎます — アクションが
GITHUB_PATHまたはGITHUB_ENVに書き込んだエントリは、後続のブループリントのステップに適用されます
Actionsは実際のGitHubワークフローの外で実行されます。
github.repositoryのような前提情報変数にはスタブ値が設定されます。GitHub APIへのライブアクセスを必要とするActions (例: PRへのコメント、リリースの作成) は、ブループリントでは動作しません。制限事項
-
サポートされるアクションの種類 — ブループリントは以下のアクションの種類 (
runs.using) をサポートしています: -
maintenanceでは利用不可 —usesステップはinitializeとpost-buildで実行できますが、maintenanceでは実行できません。構文を参照してください。 -
postライフサイクルなし — ビルドは使い捨ての VM 上で実行されるため、Devin はpreとmainのステップ (および Dockerアクション のpre-entrypoint) は実行しますが、postのクリーンアップステップ (postとpost-entrypoint) はスキップします。 - GitHub 前提情報はスタブ — GitHub APIコール、ワークフロー のイベントデータ、または リポジトリ の前提情報に依存する action は、これらの値がビルド環境ではプレースホルダーであるため、正しく動作しない場合があります。
-
バージョンを固定する — 再現可能なビルドのため、ブランチ名ではなく、必ず特定のバージョンタグ (例:
@v5) を参照してください。

