Skip to main content
一般的な言語やユースケース向けの、コピー&ペーストですぐ使えるブループリントです。各テンプレートはそれ単体で完結しています。組み合わせて設定全体を構成できます。 各フィールドの詳細は、Blueprint referenceを参照してください。
Secrets: テンプレートは $SECRET_NAME を介してSecretsを参照します。テンプレートを利用する前に、各ブループリントエディタ内の Secrets タブでこれらを設定してください。ブループリントに認証情報をハードコードしないでください。

クイックスタート

よくあるセットアップ向けの最小構成のブループリントです。1 つをコピーしてブループリントエディタに貼り付ければ完了です。

リポジトリのブループリント

リポジトリごとのビルド手順、依存関係管理、Knowledge エントリ。これらは Settings > Environment > Blueprints > [ご利用のリポジトリ] で設定します。

Python

依存関係の管理に uv を利用する Python プロジェクト向けの推奨セットアップです。

Node.js

npm を使う標準的な Node.js のセットアップです。
maintenance では npm ci ではなく npm install を利用してください。npm install は差分更新を行いますが、npm ci は毎セッション node_modules を削除し、すべてを最初から再インストールします。

Go

モジュールを使用した標準的なGoのセットアップ。

Java

Gradle を使用する Java のセットアップ。
JDK 17 は Devin のベースイメージにプリインストールされています。デフォルトの OpenJDK 17 で十分な場合は、JDK のインストール手順をスキップしてください。

Ruby on Rails

PostgreSQL を使用する Rails のセットアップ。

Rust

cargo を使った標準的な Rust のセットアップ。
Rust (rustup 経由) と Cargo は、Devin のベースイメージにあらかじめインストールされています。デフォルトの安定版ツールチェーンで十分な場合は、インストール手順は省略できます。必要なのは依存関係の取得だけです。

モノレポ

Node.js のフロントエンドと Python のバックエンドを持つモノレポです。各サブプロジェクトには、それぞれ専用のKnowledge エントリを設定します。
ステップ間で作業ディレクトリがリセットされるように、cd dir && command ではなくサブシェル (cd dir && command) を利用してください。

非公開パッケージレジストリ

パッケージマネージャーが非公開レジストリから依存関係を取得できるように設定します。これらは Settings > Environment > Blueprints > Org-wide setup で設定してください (必要なのが 1 つのリポジトリだけであれば、リポジトリ単位でも設定できます) 。
認証情報の設定は initialize ではなく maintenance に記述してください。 シークレット (レジストリのパスワードや認証トークン) を設定ファイルに書き込むステップでは、各セッションで認証情報が 毎回新しく読み込まれるように、maintenance を使用してください。シークレットはスナップショットが保存される前に削除されるため、initialize 中に書き込まれた設定ファイルには、セッション開始時に有効な認証情報が含まれません。
非公開レジストリで社内 CA を使用している場合は、まず Enterprise レベルで CA 証明書 がインストールされていることを確認してください。以下の設定では、HTTPS の信頼関係が すでに確立されていることを前提としています。

Node.js レジストリ

npm を設定して、スコープ付きパッケージ (例: @myorg/*) は非公開レジストリから取得し、公開パッケージは引き続きデフォルトの npm レジストリから取得するようにします。
- GITHUB_PACKAGES_TOKENread:packages スコープを持つパーソナルアクセストークン、または GitHub App トークン
@myorg は実際の npm スコープに置き換えてください。一般的な非公開レジストリ URL:
  • GitHub Packages: https://npm.pkg.github.com
  • Artifactory: https://artifactory.example.com/artifactory/api/npm/npm-virtual
  • Nexus: https://nexus.example.com/repository/npm-group
  • GitLab: https://gitlab.example.com/api/v4/packages/npm
  • AWS CodeArtifact: https://<domain>.d.codeartifact.<region>.amazonaws.com/npm/<repo>

Python レジストリ

pip と uv が非公開の PyPI レジストリ (例: Nexus、Artifactory) からパッケージを取得できるように設定します。
  • PYPI_REGISTRY_URL — 必要に応じて認証情報を含む、PyPI インデックスの完全な URL (例: https://user:token@nexus.example.com/repository/pypi-proxy/simple)
一般的な PyPI レジストリ URL パターン:
  • Artifactory: https://artifactory.example.com/artifactory/api/pypi/pypi-virtual/simple
  • Nexus: https://nexus.example.com/repository/pypi-proxy/simple
  • AWS CodeArtifact: https://aws:TOKEN@domain-owner.d.codeartifact.region.amazonaws.com/pypi/repo/simple/
  • Azure Artifacts: https://pkgs.dev.azure.com/org/project/_packaging/feed/pypi/simple
  • GitLab: https://gitlab.example.com/api/v4/groups/<group-id>/-/packages/pypi/simple

JVM 用レジストリ

JDK をインストールし、すべての依存関係の解決が非公開レジストリ (例: Artifactory、Nexus) を経由するように Maven を設定します。
Devin のベースイメージには JDK 17 がプリインストールされています。デフォルトの OpenJDK 17 で十分な場合は、インストール手順をスキップしてください。必要なのは Maven のインストールとレジストリ設定のみです。
  • MAVEN_REGISTRY_URL — Maven レジストリの URL (例: https://artifactory.example.com/artifactory/maven-virtual) - REGISTRY_USER — レジストリのユーザー名 - REGISTRY_PASS — レジストリのパスワードまたは API トークン
Mavenでよく使われるレジストリURLのパターン:
  • Artifactory: https://artifactory.example.com/artifactory/maven-virtual
  • Nexus: https://nexus.example.com/repository/maven-public
  • Azure Artifacts: https://pkgs.dev.azure.com/org/project/_packaging/feed/maven/v1
  • GitHub Packages: https://maven.pkg.github.com
  • GitLab: https://gitlab.example.com/api/v4/groups/<group-id>/-/packages/maven
  • AWS CodeArtifact: https://<domain>.d.codeartifact.<region>.amazonaws.com/maven/<repo>

その他のレジストリ

Go をインストールし、非公開のモジュールプロキシ (例: Athens、Artifactory、または GOPROXY エンドポイント) 経由でモジュールを取得できるように設定します。
  • GO_PROXY_URL — Go モジュールプロキシの URL (例: https://athens.corp.internal)
  • GIT_TOKEN — Go モジュールをホストする非公開 Git リポジトリ用のパーソナルアクセストークン
一般的な Go プロキシ URL パターン:
  • Artifactory: https://artifactory.example.com/artifactory/go-virtual
  • Nexus: https://nexus.example.com/repository/go-proxy
  • Athens: https://athens.corp.internal
非公開フィードからパッケージを取得できるように NuGet を設定します。
  • NUGET_SOURCE_URL — NuGet フィードの URL
  • NUGET_API_KEY — フィードの APIキーまたは PAT
Docker が非公開のコンテナレジストリからイメージをプルできるように設定します。
  • DOCKER_MIRROR_URL (任意) — Docker Hub ミラーの URL (例: https://mirror.corp.internal)
  • DOCKER_REGISTRY_URL — 非公開のコンテナレジストリの URL (例: registry.corp.internal:5000)
  • DOCKER_REGISTRY_USER — レジストリのユーザー名
  • DOCKER_REGISTRY_PASS — レジストリのパスワードまたは API トークン
よく使われるコンテナレジストリのURL:
  • Amazon ECR: <account-id>.dkr.ecr.<region>.amazonaws.com
  • Azure Container Registry: <name>.azurecr.io
  • Google Artifact Registry: <region>-docker.pkg.dev
  • GitHub Container Registry: ghcr.io
  • GitLab Container Registry: registry.gitlab.example.com
  • Nexus: https://nexus.example.com:8443
  • JFrog: <name>.jfrog.io
Cargo が非公開レジストリからクレートを解決するように設定します。
Rust (rustup 経由) と Cargo は、Devin のベースイメージに プリインストール されています。デフォルトの stable ツールチェーンで十分な場合は、インストール手順をスキップしてください。必要なのはレジストリの設定のみです。
  • CARGO_REGISTRY_INDEX — 非公開レジストリインデックスの URL (例: sparse+https://cargo.corp.internal/api/v1/crates/)
  • CARGO_REGISTRY_TOKEN — 非公開レジストリ用の認証トークン
crates.io を置き換えずに非公開レジストリを追加するだけでよい場合は、[source.crates-io][source.private] セクションを削除し、代わりに cargo install --registry private を利用するか、Cargo.toml[dependencies] my-crate = { version = "1.0", registry = "private" } を利用してください。
Ruby をインストールし、非公開の gem サーバーから gem を取得できるように Bundler を設定します。
  • GEM_SERVER_URL — 非公開の gem サーバーの URL (例: https://artifactory.example.com/artifactory/api/gems/gems-virtual)
  • REGISTRY_USER — レジストリのユーザー名
  • REGISTRY_PASS — レジストリのパスワードまたは API トークン
一般的な gem サーバーの URL パターン:
  • Artifactory: https://artifactory.example.com/artifactory/api/gems/gems-virtual
  • Nexus: https://nexus.example.com/repository/rubygems-proxy
  • Gemfury: https://gem.fury.io/<org>
PHP をインストールし、Composer が非公開の Packagist または Satis レジストリからパッケージを取得できるように設定します。
  • COMPOSER_REGISTRY_URL — 非公開の Composer レジストリの URL (例: https://repo.packagist.com/<org>)
  • REGISTRY_USER — レジストリのユーザー名
  • REGISTRY_PASS — レジストリのパスワードまたは API トークン
一般的な Composer レジストリの URL パターン:
  • Artifactory: https://artifactory.example.com/artifactory/api/composer/packagist-virtual
  • Nexus: https://nexus.example.com/repository/packagist-proxy
  • Private Packagist: https://repo.packagist.com/<org>
  • Satis: https://satis.corp.internal
AWS CodeArtifact のトークンは 12 時間で期限切れになります。必要に応じてエージェントが再実行できるよう、maintenance を利用してトークン更新コマンドを設定します。この例では、npm、pip、Maven で CodeArtifact を利用するよう設定します。
awscli は Devin のベースイメージにあらかじめインストールされています。必要なのは、トークンの更新とレジストリの設定だけです。
  • AWS_ACCESS_KEY_IDAWS_SECRET_ACCESS_KEYcodeartifact:GetAuthorizationToken および sts:GetServiceBearerToken 権限を持つ IAM 認証情報
  • CA_DOMAIN — CodeArtifact のドメイン名
  • CA_DOMAIN_OWNER — ドメインを所有する AWS アカウント ID
  • CA_REGION — AWS リージョン (例: us-east-1)
  • CA_NPM_REPO, CA_PYPI_REPO, CA_MAVEN_REPO — 各エコシステムのリポジトリ名

Enterprise インフラストラクチャ

すべての org と repo に共通して適用されるマシンレベルのインフラストラクチャです。これらは Settings > Devin’s base environment (enterprise-wide の場合) または Settings > Environment > Blueprints > Org-wide setup (org-wide の場合) で設定します。

ネットワークと接続

お使いの組織では、内部サービス向けに非公開の認証局を利用しています。Devin が HTTPS 経由で内部レジストリやツールに接続するには、ルート証明書が必要です。
- CORP_ROOT_CA_B64 — 社内 CA の PEM 証明書を Base64 エンコードしたもの。生成方法: cat corp-root-ca.crt | base64 -w0
組織で複数のCA証明書 (例:内部サービスごとに異なるCA) を利用している場合。
- CORP_ROOT_CA_B64 — Base64エンコードされたプライマリCA証明書 - CORP_INTERMEDIATE_CA_B64 — Base64エンコードされた中間CA証明書
すべてのネットワークトラフィックを社内プロキシ経由で送信します。
  • CORP_HTTP_PROXY — HTTP プロキシ URL (例: http://proxy.corp.example.com:8080) - CORP_HTTPS_PROXY — HTTPS プロキシ URL - CORP_NO_PROXY — プロキシを経由しないホストのカンマ区切りリスト (例: localhost,127.0.0.1,.corp.example.com)
企業内プロキシでユーザー名/パスワード認証が必要な場合。
  • PROXY_USER — プロキシのユーザー名 - PROXY_PASS — プロキシのパスワード - PROXY_HOST — プロキシのホスト名とポート (例: proxy.corp.example.com:8080) - CORP_NO_PROXY — プロキシを経由しないホスト
社内CAとプロキシの両方が必要な環境向けの設定です。これは、内部サービスが社内証明書を利用し、すべてのトラフィックをプロキシ経由にする必要があるEnterprise環境で一般的です。
  • CORP_ROOT_CA_B64 — Base64エンコードされた社内CA証明書 - CORP_HTTP_PROXY, CORP_HTTPS_PROXY — プロキシURL - CORP_NO_PROXY — プロキシをバイパスするホスト
非公開レジストリ、Git サーバー、その他の社内サービスには、VPN 経由でのみアクセスできます。これは、社内リソースへのネットワークアクセスが必要な他のモジュールより前に実行する必要があります。
OpenVPN:
  • VPN_CONFIG_B64 — Base64 エンコードされた OpenVPN 設定ファイル (.ovpn) 。生成方法: cat corp.ovpn | base64 -w0
  • VPN_AUTH_USER (任意) — VPN でユーザー名/パスワード認証が必要な場合の VPN ユーザー名
  • VPN_AUTH_PASS (任意) — VPN パスワード
WireGuard:
  • WG_CONFIG_B64 — Base64 エンコードされた WireGuard 設定ファイル。生成方法: cat wg0.conf | base64 -w0
OpenVPN:
WireGuard:
VPN の設定の詳細については、VPN Configurationを参照してください。
お客様の内部サービスでは、公開DNSでは名前解決できない非公開DNS名を利用しています。

ID とセキュリティ

組織で、すべてのGitコミットに署名する必要があり、DevinのコミットをGitHubでVerifiedとして表示したい場合。
  • GPG_PRIVATE_KEY_B64 — Base64エンコードされたGPG秘密鍵。生成方法: gpg --export-secret-keys <key-id> | base64 -w0
  • GIT_USER_NAME — Gitの作成者名 (例: Devin AI)
  • GIT_USER_EMAIL — Gitの作成者メールアドレス。GPGキー上のUIDと一致している必要があります。一致しない場合、GitHubは署名を検証しません。
Devinがプッシュに利用する認証情報に対応するGitHubアカウントにも、対応する公開鍵をアップロードしてください (GitHub Settings > SSH and GPG keys) 。GitHubがコミットをVerifiedとして表示するのは、コミットの作成者アカウントに署名用の公開鍵が登録されている場合のみです。
非公開GitサーバーにアクセスするためのDevinのGit IDとSSHキーを設定します。
  • GIT_USER_NAME — Gitの作成者名 - GIT_USER_EMAIL — Gitの作成者メールアドレス - SSH_PRIVATE_KEY_B64 — Base64エンコードされたSSH秘密鍵。生成方法: cat ~/.ssh/id_ed25519 | base64 -w0 - SSH_KNOWN_HOSTS_B64 — Base64エンコードされたknown hostsエントリ。生成方法: ssh-keyscan git.corp.internal | base64 -w0 - SSH_CONFIG_B64 (任意) — Base64エンコードされたSSH設定ファイル
Gitサーバー用のknown hostsエントリは、ssh-keyscan git.corp.internal | base64 -w0 で生成できます。

システム構成

Devinのデフォルトイメージに含まれていないシステムレベルのパッケージ (例:画像処理やPDF生成に必要なネイティブライブラリ) をインストールします。
すべてのセッションで利用できる永続的な環境変数を設定します。推奨される方法は、KEY=VALUE 形式の行を $ENVRC ファイルに書き込むことです。$ENVRC に書き込まれた変数は、以降のすべてのステップと Devin セッションで自動的にエクスポートされます (GitHub Actions の $GITHUB_ENV と同様です) 。
システム全体で利用できるように、環境変数を /etc/profile.d/ のスクリプトに書き込むこともできます。
どちらの方法でも問題ありません。ほとんどの場合は、$ENVRC のほうが簡単でおすすめです。
デフォルトのベースイメージでは、ロケール設定が正しくない場合があります。ビルドツール、Java、Python、Git で警告が表示されないように、ロケールとタイムゾーンを設定してください。
Java、Gradle、Node.js のビルドでは、デフォルトの 1024 のオープンファイル上限に頻繁に達します。ビルドの失敗を防ぐため、この上限を引き上げてください。
air-gapped または制限された環境では、デフォルトの Ubuntu APT ソースを内部ミラーに置き換えます。
- APT_MIRROR_URL — 内部 APT ミラーの URL (例: https://artifactory.example.com/artifactory/ubuntu-remote)
一般的なAPTミラーのURLパターン:
  • Artifactory: https://artifactory.example.com/artifactory/ubuntu-remote
  • Nexus: https://nexus.example.com/repository/ubuntu-proxy

高度なパターン

Devinのベース環境には direnv が含まれています。.envrc ファイルを作成するには initialize を利用します。direnv がそれらを自動的に読み込みます。
direnv は Devin のシェルにあらかじめ組み込まれているため、.envrc の変数は自動的に読み込まれます。手動で source する必要はありません。
機密性の高い環境変数 (APIキー、トークン、データベースのパスワード) には、.envrc ファイルではなく repo secrets を利用してください。Repo secrets は安全に保存され、セッション時に自動的に注入されます。ブループリントやスナップショットに含まれることはありません。
.nvmrc を使って、リポジトリごとに Node.js のバージョンを切り替えるには、nvm (プリインストール済み) を利用します。
nvm use はリポジトリのルートにある .nvmrc を読み取ります。リポジトリに .nvmrc があることを確認してください (例: 20 を含むもの) 。
Devin では、セッション中localhost:29229 の CDP エンドポイントを備えた Chrome ブラウザを利用できます。Playwright スクリプトを利用して、ブラウザベースのログインを自動化してください。
ブラウザを利用できるのはセッション中のみで、スナップショットのビルドでは利用できません。initialize で Playwright をインストールし、ログインスクリプトはリポジトリに保存してください。
ログインスクリプトの例 (scripts/login.py) :
ログイン認証情報はソースコードに含めず、シークレットとして保存してください。長期間使用する認証が必要な場合は、Devin が自動で再認証できるよう、ログインスクリプトを .agents/skills/ にコミットしてください。
initialize でシステムパッケージやカスタムバイナリをインストールし、PATH を設定します。
Devin では、Node.js ベースの GitHub Actions をブループリント内で直接実行できます。これにより、CI で利用しているのと同じアクションを使って、特定のバージョンのツールをインストールできます。
setup-nodesetup-python などのアクションは、PATH と環境変数を変更します。あるアクションでインストールされたバイナリは、後続のすべてのステップと maintenance で利用できます。サポートされるのは Node.js ベースの GitHub Actions のみです。Composite アクションと Docker ベースのアクションはサポートされていません。
基本的なツールのセットアップに GitHub Actions は必要ありません。シェルコマンドを直接実行しても (nvm install 20curl ... | shapt-get install) 、同様に機能し、多くの場合はこちらのほうが簡単です。GitHub Actions が特に有用なのは、CI のセットアップと完全に一致させたい場合や、複数のディストリビューションに対応する setup-java のようなアクションの利便性が必要な場合です。
app.example.comapi.example.comadmin.example.com のような実在しそうなホスト名で、複数のサービスを HTTPS 経由で公開できます。initialize で 1 つのリバースプロキシをインストールし、各ホスト名をそれぞれ異なるローカルのアップストリームポートにルーティングします。Caddy は、ルーティングとローカル TLS を 1 つのツールでまとめて処理します。Caddyfile では各ホスト名をアップストリームに対応付け、tls internal は Caddy に組み込まれた CA から、ホスト名ごとに信頼された証明書を自動発行します。caddy trust はその CA ルートをシステムの信頼ストアにインストールし、同じルートを NSS データベースにも追加すると、ブラウザでも受け入れられるようになります。Caddyfile はブループリントエディタの File attachments セクションからアップロードしてください。アップロードすると、$FILE_CADDYFILE として利用できるようになります。
Caddyfile
/etc/hosts ループによって、セッション内では app.example.com127.0.0.1 に名前解決されます。Caddyfile に記述する各ホスト名について、/etc/hosts ループにもエントリを追加してください。
サービスを追加するには、Caddyfile に 3 行のブロックを追記し、/etc/hosts ループにエントリを 1 つ追加してから、そのホスト名に HTTPS でアクセスしてください。Caddy は最初のリクエスト時に証明書を発行するため、app ごとに証明書を生成する必要はありません。

フルスタックの使用例

これらの使用例では、Enterprise と org レベルの設定がどのように組み合わさるかを示しています。実際には、これらはスコープごとに分けて扱うのが一般的です。ここでは参考用にまとめて示しています。
Enterprise環境のフルセット構成例:社内CA証明書、プロキシ、Java (Maven) 、Python (pip/uv) 、Node.js (npm) 、Dockerをすべて単一のArtifactoryインスタンスに向けた設定です。
ネットワーク & 信頼設定 (アカウント全体) :
  • CORP_ROOT_CA_B64 — Base64 エンコードされた社内CA証明書
  • CORP_HTTP_PROXY — HTTP プロキシ URL
  • CORP_HTTPS_PROXY — HTTPS プロキシ URL
  • CORP_NO_PROXY — プロキシをバイパスするホスト
レジストリ認証情報 (組織全体) :
  • ARTIFACTORY_USER — Artifactory のユーザー名
  • ARTIFACTORY_TOKEN — Artifactory API トークンまたはパスワード
  • ARTIFACTORY_MAVEN_URL — Maven リポジトリ URL (例: https://artifactory.example.com/artifactory/maven-virtual)
  • ARTIFACTORY_PYPI_URL — PyPI リポジトリ URL (例: https://user:token@artifactory.example.com/artifactory/api/pypi/pypi-virtual/simple)
  • ARTIFACTORY_NPM_URL — npm リポジトリ URL (例: https://artifactory.example.com/artifactory/api/npm/npm-virtual)
  • ARTIFACTORY_DOCKER_URL — Docker レジストリ URL (例: artifactory.example.com)
これは通常、3つのスコープに分割されます:
  • アカウント全体で共通 (initialize) : 証明書とプロキシ
  • 組織全体 (initialize): 言語ランタイムのインストール
  • 組織全体 (maintenance): レジストリ認証情報 (ビルド中に更新され、セッション開始時にエージェントに渡される)
参考までに、まとめて示します:
この例では、すべてのレジストリが同じ Artifactory インスタンスを参照していますが、URL パスはそれぞれ異なります。各パッケージエコシステムには、それぞれ固有のエンドポイント形式があります。Maven、PyPI、npm、Docker の URL は、同じレジストリであってもそれぞれ異なります。
言語ごとに異なる非公開レジストリを利用する場合 (例: Maven は Nexus、npm は GitHub Packages、Python は Artifactory) 。
  • NEXUS_MAVEN_URL — Nexus Maven リポジトリ URL
  • NEXUS_USER — Nexus のユーザー名
  • NEXUS_PASS — Nexus のパスワード
  • GITHUB_PACKAGES_TOKENread:packages スコープを持つ GitHub パーソナルアクセストークン
  • ARTIFACTORY_USER — Artifactory のユーザー名
  • ARTIFACTORY_TOKEN — Artifactory API トークン
  • GIT_TOKEN — Go の非公開モジュール用パーソナルアクセストークン
完全にエアギャップされた環境では、Devin は公開 URL に一切アクセスできません。すべてのツール、ランタイム、パッケージは内部ミラー経由で取得する必要があります。
証明書:
  • CORP_ROOT_CA_B64 — Base64 エンコードされた社内CA証明書
ミラーへのアクセス:
  • APT_MIRROR_URL — 内部 Ubuntu APT ミラーの URL
  • MIRROR_USER — ミラー認証用のユーザー名
  • MIRROR_PASS — ミラー認証用のパスワード
  • JDK_TARBALL_URL — 内部ミラーから JDK tarball をダウンロードするための URL
  • NODE_TARBALL_URL — 内部ミラーから Node.js tarball をダウンロードするための URL
パッケージレジストリ:
  • INTERNAL_MAVEN_URL — 内部 Maven レジストリの URL
  • INTERNAL_NPM_URL — 内部 npm レジストリの URL
  • INTERNAL_PYPI_URL — 内部 PyPI レジストリの URL
エアギャップ環境では、Devin が必要とするすべてのツール (言語ランタイム、CLI ツールなど) を社内ミラーで利用できるようにしておく必要があります。公開レジストリやダウンロードサイトにはアクセスできません。
VPN接続、証明書、プロキシ、多言語サポートを組み合わせた包括的なEnterpriseセットアップです。以下が推奨される操作手順です。
VPN:
  • VPN_CONFIG_B64 — Base64 でエンコードされた OpenVPN 設定ファイル
ネットワークと信頼設定:
  • CORP_ROOT_CA_B64 — Base64 でエンコードされた社内CA証明書
  • CORP_HTTP_PROXY — HTTP プロキシ URL
  • CORP_HTTPS_PROXY — HTTPS プロキシ URL
  • CORP_NO_PROXY — プロキシを経由しないホスト
レジストリ認証情報:
  • MAVEN_REGISTRY_URL — Maven レジストリ URL
  • NPM_REGISTRY_URL — npm レジストリ URL
  • PYPI_REGISTRY_HOST — PyPI レジストリのホスト名
  • REGISTRY_USER — レジストリのユーザー名 (Maven と pip 用)
  • REGISTRY_PASS — レジストリのパスワード (Maven と pip 用)
  • REGISTRY_TOKEN — npm 認証トークン
initialize ステップでは順序が重要です。 まず VPN (内部ホストに到達できるようにするため) 、次に DNS (名前解決を行えるようにするため) 、次に証明書 (HTTPS を機能させるため) 、次にプロキシ (トラフィックを正しくルーティングするため) 、最後に言語ランタイム (内部ミラーからダウンロードする場合があるため) を設定する必要があります。

良い ブループリント を書くためのヒント

  • まずセッションでコマンドをテストする。 ブループリント に追加する前に、Devin のセッションでコマンドを手動で実行してください。フルビルドを待つより、そのほうが速く済みます。
  • 一度だけインストールするツールには initialize、依存関係には maintenance を利用する。 インストールに数分かかるもの (コンパイラ、大きなバイナリ、グローバルツール) は initialize に入れます。短時間で終わる依存関係コマンド (npm installuv sync) は maintenance に入れます。
  • maintenance コマンドは高速に保つ。 2 分以内を目安にしてください。これらはビルド中に実行され、セッション開始時にエージェントに提示されます。
  • 環境変数には $ENVRC を利用する。 .bashrc.profile には書き込まないでください。ステップ間やセッション間で変数を設定するための正式な仕組みは $ENVRC です。
  • ステップには名前を付ける。 name フィールドを使う expanded form にすると、ビルドログ内の失敗箇所を特定しやすくなります。
  • モノレポ では サブシェル を利用する。 (cd packages/foo && npm install) は サブシェル 内で実行されるため、後続のステップはディレクトリ変更の影響を受けません。
  • npm ci ではなく npm install を利用する。 npm cinode_modules を削除し、ゼロから再インストールするため、maintenance には不向きです。
  • 機密性の高い値には repo secrets を利用する。 ブループリント に直接書き込むのではなく、リポジトリのブループリントエディタの Secrets タブで設定してください。
構文の詳細については、Blueprint reference を参照してください。ビルド失敗のトラブルシューティングについては、Declarative configuration > Troubleshooting を参照してください。