メインコンテンツへスキップ
このページでは、一般的なシナリオ向けの、自己完結した environment.yaml の使用例を紹介します。各使用例は1つの関心事を扱っているため、組み合わせて完全な設定を構築できます。 environment.yaml の構文と概念の概要については、Environment Configuration を参照してください。構文の詳細については、YAML Reference を参照してください。
シークレット: 使用例では、$SECRET_NAME を介してシークレットを参照します。使用例を利用する前に、Settings → Secrets でこれらを設定してください。各使用例には、設定する必要があるシークレットと、想定される値を正確に一覧表示した、折りたたみ可能な 「必要なシークレット」 セクションが含まれています。environment.yaml に認証情報をハードコードしないでください。

クイックリファレンス:よく使われるセットアップ

よく利用される構成を 1 か所にまとめました。完全な一覧については、以下のセクションを参照してください。
initialize: |
  npm install -g pnpm

maintenance: |
  pnpm install

knowledge:
  - name: lint
    contents: |
      エラーの確認には `pnpm lint` を実行します。
  - name: test
    contents: |
      完全なテストスイートを実行するには `pnpm test` を実行します。
initialize:
  - name: uv をインストール
    run: curl -LsSf https://astral.sh/uv/install.sh | sh

maintenance:
  - name: 依存関係を同期
    run: uv sync

knowledge:
  - name: lint
    contents: |
      lint を実行するには `uv run ruff check .` を使用します。
  - name: test
    contents: |
      完全なテストスイートを実行するには `uv run pytest` を実行します。
initialize:
  - name: pnpm をインストール
    run: npm install -g pnpm
  - name: uv をインストール
    run: curl -LsSf https://astral.sh/uv/install.sh | sh

maintenance:
  - name: フロントエンドの依存関係
    run: (cd frontend && pnpm install)
  - name: バックエンドの依存関係
    run: (cd backend && uv sync)

knowledge:
  - name: structure
    contents: |
      - `frontend/` — React アプリ(pnpm)
      - `backend/` — Python API(uv)
  - name: test
    contents: |
      Frontend: cd frontend && pnpm test
      Backend: cd backend && uv run pytest
initialize: |
  npm install -g pnpm

maintenance: |
  pnpm install

knowledge:
  - name: structure
    contents: |
      pnpm workspaces で管理されるモノレポです。
      - `packages/web` — Next.js フロントエンド
      - `packages/api` — Express.js バックエンド
      - `packages/shared` — 共通ユーティリティ
  - name: test
    contents: |
      すべての packages に対してルートから `pnpm test` を実行します。
      特定の package に対しては `pnpm --filter web test` を実行します。

レイヤーの仕組み

環境設定はレイヤーごとに適用されます。各レイヤーは、その前のレイヤーの上に積み重なります。
1

アカウント全体 (Enterprise)

証明書、プロキシ、DNS、VPN、コミット署名、ロケール、リソース制限、git identity、APTミラー。 すべての組織すべてのリポジトリに適用されます。
2

組織全体

言語ランタイム、パッケージマネージャーのレジストリ設定、コンテナレジストリ、共有ツール。 組織内のすべてのリポジトリに適用されます。
3

リポジトリ固有

ビルドコマンド、依存関係のインストール、テスト/lintコマンド、Devin向けのプロジェクト固有のメモ。 1つのリポジトリに適用されます。
まずアカウント全体、次に組織全体、最後にリポジトリ固有の順で実行されます。各項目は、Settings の適切なスコープで設定してください。

Module reference

この表を利用して、ニーズに合った適切な使用例を見つけてください。各モジュールは独立しているため、自由に組み合わせられます。
ModuleLayerSection
CA証明書Enterprise社内CA証明書
複数のCA証明書Enterprise複数のCA証明書
HTTP/HTTPSプロキシEnterpriseHTTP/HTTPSプロキシ
認証付きプロキシEnterprise認証付きプロキシ
CA証明書 + プロキシEnterpriseCA証明書 + プロキシ (併用)
VPN (OpenVPN / WireGuard)EnterpriseVPN接続
カスタムDNSEnterpriseカスタムDNS名前解決
GPGコミット署名EnterpriseGPGコミット署名
Git identity + SSHキーEnterpriseGit identity と SSHキー
システムパッケージEnterpriseシステムパッケージのインストール
環境変数Enterpriseカスタム環境変数
ロケールとタイムゾーンEnterpriseロケールとタイムゾーン
リソース制限Enterpriseリソース制限 (ulimits)
APTミラーEnterpriseAPTミラーの置き換え
Java + MavenOrgJava + Mavenでプライベートレジストリを使用する
Java + GradleOrgJava + Gradleでプライベートレジストリを使用する
Python + pip/uvOrgPython + pip/uvでプライベートレジストリを使用する
Python + PoetryOrgPython + Poetryでプライベートレジストリを使用する
Node.js + npm (scoped)OrgNode.js + npmでスコープ付きプライベートレジストリを使用する
Node.js + npm (full mirror)OrgNode.js + npmで完全なプライベートレジストリミラーを使用する
Node.js + pnpmOrgNode.js + pnpmでプライベートレジストリを使用する
Node.js + YarnOrgNode.js + Yarnでプライベートレジストリを使用する
GoOrgGoで非公開モジュールプロキシを使用する
.NET + NuGetOrg.NET + NuGetで非公開フィードを使用する
DockerOrgDockerで非公開コンテナレジストリを使用する
Rust + CargoOrgRust + Cargoでプライベートレジストリを使用する
Ruby + BundlerOrgRuby + Bundlerで非公開gemサーバーを使用する
PHP + ComposerOrgPHP + Composerでプライベートレジストリを使用する
AWS CodeArtifactOrgAWS CodeArtifactトークンの更新
Node.jsプロジェクトRepo標準のNode.jsプロジェクト
PythonプロジェクトRepo標準のPythonプロジェクト
JavaプロジェクトRepo標準のJavaプロジェクト
GoプロジェクトRepo標準のGoプロジェクト
RustプロジェクトRepo標準のRustプロジェクト
モノレポRepo複数サービスのモノレポ
複数JDKのモノレポRepo複数のJDKバージョンを含むモノレポ
KnowledgeエントリRepo詳細なKnowledgeエントリ
pre-commitフックRepopre-commitフック

Enterprise / アカウント全体の使用例

これらの使用例では、すべての組織とリポジトリにまたがって適用される、マシンレベルのインフラストラクチャを設定します。これらは Enterprise Settings (アカウント全体向け) または Settings > Environment > Organization-wide setup (組織全体向け) で設定してください。

Corporate CA certificate

組織では、社内サービス向けにプライベート認証局を利用しています。Devin が HTTPS 経由で社内レジストリやツールにアクセスするには、ルート証明書が必要です。
  • CORP_ROOT_CA_B64 — 社内CAの PEM 証明書を Base64 エンコードしたもの。生成方法: cat corp-root-ca.crt | base64 -w0
initialize:
  - name: Install corporate CA certificate
    run: |
      echo "$CORP_ROOT_CA_B64" | base64 -d \
        | sudo tee /usr/local/share/ca-certificates/corp-root-ca.crt > /dev/null
      sudo update-ca-certificates

      # Let Node.js trust the corporate CA
      echo 'export NODE_EXTRA_CA_CERTS=/usr/local/share/ca-certificates/corp-root-ca.crt' \
        | sudo tee /etc/profile.d/node-ca.sh > /dev/null

複数のCA証明書

組織によっては、内部サービスごとに異なるCAを使い分けている場合があります (例: アーティファクトレジストリ用に1つ、内部Gitサーバー用にもう1つ) 。
  • CA_CERT_REGISTRY_B64 — アーティファクトレジストリCA用のBase64エンコードされたPEM証明書
  • CA_CERT_GIT_B64 — GitサーバーCA用のBase64エンコードされたPEM証明書
initialize:
  - name: Install corporate CA certificates
    run: |
      # 各証明書をデコードしてインストールする
      echo "$CA_CERT_REGISTRY_B64" | base64 -d \
        | sudo tee /usr/local/share/ca-certificates/registry-ca.crt > /dev/null
      echo "$CA_CERT_GIT_B64" | base64 -d \
        | sudo tee /usr/local/share/ca-certificates/git-ca.crt > /dev/null

      sudo update-ca-certificates

      # Node.js: 証明書を単一のバンドルにまとめる
      cat /usr/local/share/ca-certificates/registry-ca.crt \
          /usr/local/share/ca-certificates/git-ca.crt \
        > /tmp/corp-ca-bundle.crt
      echo "export NODE_EXTRA_CA_CERTS=/tmp/corp-ca-bundle.crt" \
        | sudo tee /etc/profile.d/node-ca.sh > /dev/null

HTTP/HTTPS プロキシ

組織では、外向きのトラフィックを社内プロキシ経由でルーティングしています。
  • CORP_HTTP_PROXY — HTTP プロキシ URL (例: http://proxy.corp.internal:8080)
  • CORP_HTTPS_PROXY — HTTPS プロキシ URL (例: http://proxy.corp.internal:8080)
  • CORP_NO_PROXYlocalhost,127.0.0.1,.corp.internal,10.0.0.0/8 のように、プロキシを経由しないホストをカンマ区切りで指定します
initialize:
  - name: Configure system-wide HTTP/HTTPS proxy
    run: |
      cat << 'PROXY' | sudo tee /etc/profile.d/proxy.sh > /dev/null
      export http_proxy="$CORP_HTTP_PROXY"
      export https_proxy="$CORP_HTTPS_PROXY"
      export no_proxy="$CORP_NO_PROXY"
      export HTTP_PROXY="$CORP_HTTP_PROXY"
      export HTTPS_PROXY="$CORP_HTTPS_PROXY"
      export NO_PROXY="$CORP_NO_PROXY"
      PROXY
      source /etc/profile.d/proxy.sh

maintenance:
  - name: Configure git proxy
    run: |
      git config --global http.proxy "$CORP_HTTP_PROXY"
      git config --global https.proxy "$CORP_HTTPS_PROXY"
CORP_NO_PROXY には、localhost,127.0.0.1,.corp.internal,10.0.0.0/8 のように、プロキシを経由しないホストをカンマ区切りで指定します。

認証が必要なプロキシ

プロキシでユーザー名とパスワードによる認証が必要な場合は、認証情報をプロキシ URL に埋め込んでください。
  • PROXY_USER — プロキシ認証のユーザー名
  • PROXY_PASS — プロキシ認証のパスワード
  • PROXY_HOST — プロキシのホスト名 (例: proxy.corp.internal)
  • PROXY_PORT — プロキシのポート番号 (例: 8080)
  • CORP_NO_PROXY — プロキシを経由しないホストをカンマ区切りで指定
initialize:
  - name: Configure authenticated HTTP/HTTPS proxy
    run: |
      cat << 'PROXY' | sudo tee /etc/profile.d/proxy.sh > /dev/null
      export http_proxy="http://$PROXY_USER:$PROXY_PASS@$PROXY_HOST:$PROXY_PORT"
      export https_proxy="http://$PROXY_USER:$PROXY_PASS@$PROXY_HOST:$PROXY_PORT"
      export no_proxy="$CORP_NO_PROXY"
      export HTTP_PROXY="$http_proxy"
      export HTTPS_PROXY="$https_proxy"
      export NO_PROXY="$CORP_NO_PROXY"
      PROXY
      source /etc/profile.d/proxy.sh

maintenance:
  - name: Configure git proxy
    run: |
      git config --global http.proxy "http://$PROXY_USER:$PROXY_PASS@$PROXY_HOST:$PROXY_PORT"
      git config --global https.proxy "http://$PROXY_USER:$PROXY_PASS@$PROXY_HOST:$PROXY_PORT"

CA 証明書 + プロキシ (併用)

企業向けのベースラインとして最も一般的なのは、社内の CA 証明書をインストールし、システム全体にプロキシを設定することです。
  • CORP_ROOT_CA_B64 — 社内CAの Base64 エンコードされた PEM 証明書
  • CORP_HTTP_PROXY — HTTP プロキシ URL
  • CORP_HTTPS_PROXY — HTTPS プロキシ URL
  • CORP_NO_PROXY — プロキシをバイパスするホストのカンマ区切り一覧
initialize:
  - name: Install corporate CA certificate
    run: |
      echo "$CORP_ROOT_CA_B64" | base64 -d \
        | sudo tee /usr/local/share/ca-certificates/corp-root-ca.crt > /dev/null
      sudo update-ca-certificates
      echo 'export NODE_EXTRA_CA_CERTS=/usr/local/share/ca-certificates/corp-root-ca.crt' \
        | sudo tee /etc/profile.d/node-ca.sh > /dev/null

  - name: Configure system-wide proxy
    run: |
      cat << 'PROXY' | sudo tee /etc/profile.d/proxy.sh > /dev/null
      export http_proxy="$CORP_HTTP_PROXY"
      export https_proxy="$CORP_HTTPS_PROXY"
      export no_proxy="$CORP_NO_PROXY"
      export HTTP_PROXY="$CORP_HTTP_PROXY"
      export HTTPS_PROXY="$CORP_HTTPS_PROXY"
      export NO_PROXY="$CORP_NO_PROXY"
      PROXY
      source /etc/profile.d/proxy.sh

maintenance:
  - name: Configure git proxy
    run: |
      git config --global http.proxy "$CORP_HTTP_PROXY"
      git config --global https.proxy "$CORP_HTTPS_PROXY"

VPN 接続

非公開のレジストリ、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
initialize:
  - name: OpenVPN をインストールして設定
    run: |
      sudo DEBIAN_FRONTEND=noninteractive apt-get update -qq
      sudo DEBIAN_FRONTEND=noninteractive apt-get install -y -qq openvpn

      # VPN 設定ファイルを書き込む
      sudo mkdir -p /etc/openvpn/client
      echo "$VPN_CONFIG_B64" | base64 -d \
        | sudo tee /etc/openvpn/client/corp.conf > /dev/null

      # VPN でユーザー名/パスワード認証が必要な場合
      if [ -n "${VPN_AUTH_USER:-}" ] && [ -n "${VPN_AUTH_PASS:-}" ]; then
        printf '%s\n%s\n' "$VPN_AUTH_USER" "$VPN_AUTH_PASS" \
          | sudo tee /etc/openvpn/client/auth.txt > /dev/null
        sudo chmod 600 /etc/openvpn/client/auth.txt
        echo "auth-user-pass /etc/openvpn/client/auth.txt" \
          | sudo tee -a /etc/openvpn/client/corp.conf > /dev/null
      fi

      # VPN トンネルを開始する
      sudo systemctl daemon-reload
      sudo systemctl enable --now openvpn-client@corp

      # トンネルが確立されるまで待機する
      for i in $(seq 1 30); do
        if ip link show tun0 >/dev/null 2>&1; then break; fi
        sleep 1
      done
VPN セットアップの詳細については、VPN の設定を参照してください。

カスタム DNS の名前解決

内部サービスでは、パブリック DNS では名前解決できないプライベート DNS 名を使用しています。
initialize:
  - name: Configure custom DNS resolution
    run: |
      # 内部ホスト名を追加する
      cat << 'HOSTS' | sudo tee -a /etc/hosts > /dev/null
      10.0.1.50  nexus.corp.internal
      10.0.1.51  git.corp.internal
      10.0.1.52  artifactory.corp.internal
      HOSTS

      # 必要に応じてカスタムネームサーバーを設定する
      sudo mkdir -p /etc/systemd/resolved.conf.d
      cat << 'DNS' | sudo tee /etc/systemd/resolved.conf.d/corp.conf > /dev/null
      [Resolve]
      DNS=10.0.0.53 10.0.0.54
      Domains=corp.internal
      DNS
      sudo systemctl restart systemd-resolved || true

GPGコミットの署名

組織では、すべてのGitコミットに署名することが義務付けられています。
  • GPG_PRIVATE_KEY_B64 — Base64エンコードされたGPG秘密鍵。次のコマンドで生成します: gpg --export-secret-keys <key-id> | base64 -w0
initialize:
  - name: Prepare GPG and git signing config
    run: |
      # TTYなしでGPGを動作させる
      echo 'export GPG_TTY=$(tty)' | sudo tee -a /etc/profile.d/gpg.sh > /dev/null

      # コミットに署名するようgitを事前設定する(鍵はメンテナンス時にインポート)
      git config --global commit.gpgsign true
      git config --global tag.gpgsign true

maintenance:
  - name: Import GPG signing key
    run: |
      echo "$GPG_PRIVATE_KEY_B64" | base64 -d | gpg --batch --import

      # 署名鍵IDを設定する
      KEY_ID=$(gpg --list-secret-keys --keyid-format long 2>/dev/null \
        | grep sec | head -1 | awk '{print $2}' | cut -d'/' -f2)
      git config --global user.signingkey "$KEY_ID"

Git ID と SSH キー

SSH 経由で非公開リポジトリにアクセスするための Git ユーザー情報と SSH キーを設定します。
  • GIT_USER_NAME — Git の作成者名 (例: Devin AI)
  • GIT_USER_EMAIL — Git の作成者メールアドレス (例: devin@company.com)
  • 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 設定ファイル
initialize:
  - name: Prepare SSH directory and git identity
    run: |
      # git IDを設定する
      git config --global user.name "$GIT_USER_NAME"
      git config --global user.email "$GIT_USER_EMAIL"

      # SSHディレクトリを準備する
      mkdir -p ~/.ssh && chmod 700 ~/.ssh

      # 必要に応じてgit-lfsを有効にする
      # git lfs install

maintenance:
  - name: Install SSH keys
    run: |
      # SSH秘密鍵をインストールする(maintenanceに記述することで、セッションごとに新たに読み込まれる)
      echo "$SSH_PRIVATE_KEY_B64" | base64 -d > ~/.ssh/id_ed25519
      chmod 600 ~/.ssh/id_ed25519

      # GitサーバーのKnown Hostsを追加する
      echo "$SSH_KNOWN_HOSTS_B64" | base64 -d >> ~/.ssh/known_hosts

      # カスタムSSH設定ファイルをインストールする(任意)
      if [ -n "${SSH_CONFIG_B64:-}" ]; then
        echo "$SSH_CONFIG_B64" | base64 -d > ~/.ssh/config
        chmod 600 ~/.ssh/config
      fi
ssh-keyscan git.corp.internal | base64 -w0 を使用して、Gitサーバーの known_hosts エントリを生成します。

システムパッケージをインストールする

プロジェクトで、デフォルトのDevinイメージに含まれていないシステムレベルのパッケージ (例: 画像処理やPDF生成に必要なネイティブライブラリ) が必要になる場合があります。
initialize:
  - name: Install system packages
    run: |
      sudo apt-get update -qq
      sudo DEBIAN_FRONTEND=noninteractive apt-get install -y -qq \
        libpq-dev \
        libmagickwand-dev \
        poppler-utils \
        ffmpeg

カスタム環境変数

すべてのセッションで利用できる永続的な環境変数を設定します。 推奨される方法は、KEY=VALUE 形式の行を $ENVRC ファイルに書き込むことです。$ENVRC に書き込まれた変数は、以降のすべてのステップと Devin セッションに対して自動的にエクスポートされます (GitHub Actions の $GITHUB_ENV と同様です) 。
initialize:
  - name: Set custom environment variables
    run: |
      echo "CORPORATE_ENV=production" >> $ENVRC
      echo "DEFAULT_REGION=us-east-1" >> $ENVRC
      echo "MAX_RETRIES=3" >> $ENVRC
システム全体で利用できるように、環境変数を /etc/profile.d/ のスクリプトに書き込むこともできます。
cat << 'ENVVARS' | sudo tee /etc/profile.d/custom-env.sh > /dev/null
export CORPORATE_ENV=production
export DEFAULT_REGION=us-east-1
ENVVARS
どちらの方法でも問題なく動作します。ほとんどのケースでは、よりシンプルな $ENVRC を推奨します。

ロケールとタイムゾーン

デフォルトのベースイメージでは、ロケール設定が正しく構成されていない場合があります。ビルドツール、Java、Python、Git からの警告を防ぐため、ロケールとタイムゾーンを設定してください。
initialize:
  - name: Configure locale and timezone
    run: |
      sudo DEBIAN_FRONTEND=noninteractive apt-get update -qq
      sudo DEBIAN_FRONTEND=noninteractive apt-get install -y -qq locales

      # ロケールを生成して設定する
      sudo sed -i 's/^# *en_US.UTF-8/en_US.UTF-8/' /etc/locale.gen
      sudo locale-gen
      sudo update-locale LANG=en_US.UTF-8 LC_ALL=en_US.UTF-8

      cat << 'LOCALE' | sudo tee /etc/profile.d/locale.sh > /dev/null
      export LANG="en_US.UTF-8"
      export LC_ALL="en_US.UTF-8"
      LOCALE

      # タイムゾーンを設定する
      sudo timedatectl set-timezone UTC 2>/dev/null || \
        sudo ln -sfn /usr/share/zoneinfo/UTC /etc/localtime

リソース制限 (ulimits)

Java、Gradle、Node.js のビルドでは、デフォルトのオープンファイル数の上限である 1024 に頻繁に達します。ビルドの失敗を防ぐため、この上限を引き上げてください。
initialize:
  - name: Raise resource limits
    run: |
      cat << 'LIMITS' | sudo tee /etc/security/limits.d/99-devin.conf > /dev/null
      *    soft    nofile    65536
      *    hard    nofile    65536
      *    soft    nproc     65536
      *    hard    nproc     65536
      LIMITS

      # カーネルの最大値も設定する
      echo "fs.file-max = 65536" | sudo tee /etc/sysctl.d/99-devin-filemax.conf > /dev/null
      sudo sysctl -p /etc/sysctl.d/99-devin-filemax.conf 2>/dev/null || true

APT ミラーの置き換え

エアギャップ環境または制限のある環境では、デフォルトの Ubuntu APT ソースを内部 APT ミラーに置き換えます。
  • APT_MIRROR_URL — 内部 APT ミラーの URL (例: https://artifactory.example.com/artifactory/ubuntu-remote)
initialize:
  - name: Replace APT sources with internal mirror
    run: |
      # 元のソースをバックアップ
      sudo cp /etc/apt/sources.list /etc/apt/sources.list.bak

      # すべてのUbuntuミラーを内部ミラーに置き換える
      sudo sed -i "s|http://archive.ubuntu.com/ubuntu|$APT_MIRROR_URL|g" /etc/apt/sources.list
      sudo sed -i "s|http://security.ubuntu.com/ubuntu|$APT_MIRROR_URL|g" /etc/apt/sources.list

      # 到達不可能なサードパーティソースを無効化する
      # sudo mv /etc/apt/sources.list.d/*.list /etc/apt/sources.list.d/disabled/ 2>/dev/null || true

      sudo apt-get update -qq
一般的なAPTミラーURLのパターンは次のとおりです。
  • Artifactory: https://artifactory.example.com/artifactory/ubuntu-remote
  • Nexus: https://nexus.example.com/repository/ubuntu-proxy

組織全体の例

これらの例では、言語ランタイムをインストールし、パッケージマネージャーがプライベートレジストリを使用するように設定します。Settings > Environment > Organization-wide setup で設定してください。
プライベートレジストリで社内CAを使用している場合は、まずエンタープライズレベルで CA証明書 がインストールされていることを確認してください。以下の組織レベルの設定は、HTTPS の信頼がすでに確立されていることを前提としています。
認証情報の設定は initialize ではなく maintenance に含めてください。 シークレット (レジストリのパスワード、認証トークン) を設定ファイルに書き込む手順では、認証情報が各セッションで新たに読み込まれるよう、maintenance を使用してください。マシンイメージが保存される前にシークレットファイルは削除されるため、initialize 中に書き込まれた設定ファイルには、セッションの開始時に有効な認証情報が含まれません。

Java + Maven でプライベートレジストリを使用する

JDK をインストールし、依存関係の解決をすべてプライベートレジストリ (例: Artifactory、Nexus) 経由で行うよう、Maven を設定します。
JDK 17 は Devin のベースイメージにプリインストールされています。デフォルトの OpenJDK 17 で十分な場合は、以下のインストール手順をスキップしてください。必要なのは Maven のインストールとレジストリの設定のみです。
  • MAVEN_REGISTRY_URL — Maven レジストリの URL (例: https://artifactory.example.com/artifactory/maven-virtual)
  • REGISTRY_USER — レジストリのユーザー名
  • REGISTRY_PASS — レジストリのパスワードまたは API トークン
initialize:
  - name: Install JDK 17
    run: |
      sudo apt-get update -qq
      sudo DEBIAN_FRONTEND=noninteractive apt-get install -y -qq openjdk-17-jdk-headless
      echo 'export JAVA_HOME=/usr/lib/jvm/java-17-openjdk-amd64' \
        | sudo tee /etc/profile.d/java.sh > /dev/null

  - name: Install Maven
    run: |
      MAVEN_VERSION=3.9.9
      curl -fsSL "https://archive.apache.org/dist/maven/maven-3/${MAVEN_VERSION}/binaries/apache-maven-${MAVEN_VERSION}-bin.tar.gz" \
        | sudo tar -xz -C /opt
      sudo ln -sf /opt/apache-maven-${MAVEN_VERSION}/bin/mvn /usr/local/bin/mvn

maintenance:
  - name: Configure Maven for private registry
    run: |
      mkdir -p ~/.m2
      cat > ~/.m2/settings.xml << EOF
      <settings>
        <mirrors>
          <mirror>
            <id>private-registry</id>
            <mirrorOf>*</mirrorOf>
            <url>$MAVEN_REGISTRY_URL</url>
          </mirror>
        </mirrors>
        <servers>
          <server>
            <id>private-registry</id>
            <username>$REGISTRY_USER</username>
            <password>$REGISTRY_PASS</password>
          </server>
        </servers>
      </settings>
      EOF
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>

プライベートレジストリを使用した Java + Gradle

JDK をインストールし、すべての依存関係をプライベートレジストリ経由で解決するように Gradle を設定します。
JDK 17 は Devin のベースイメージにプリインストールされています。デフォルトで十分な場合は、JDK のインストール手順をスキップしてください。
  • GRADLE_REGISTRY_URL — Gradle/Maven レジストリの URL
  • REGISTRY_USER — レジストリのユーザー名
  • REGISTRY_PASS — レジストリのパスワードまたは API トークン
initialize:
  - name: Install JDK 17
    run: |
      sudo apt-get update -qq
      sudo DEBIAN_FRONTEND=noninteractive apt-get install -y -qq openjdk-17-jdk-headless
      echo 'export JAVA_HOME=/usr/lib/jvm/java-17-openjdk-amd64' \
        | sudo tee /etc/profile.d/java.sh > /dev/null

  - name: Install Gradle
    run: |
      GRADLE_VERSION=8.12
      curl -fsSL "https://services.gradle.org/distributions/gradle-${GRADLE_VERSION}-bin.zip" \
        -o /tmp/gradle.zip
      sudo unzip -qo /tmp/gradle.zip -d /opt
      sudo ln -sf /opt/gradle-${GRADLE_VERSION}/bin/gradle /usr/local/bin/gradle
      rm /tmp/gradle.zip

maintenance:
  - name: Configure Gradle for private registry
    run: |
      mkdir -p ~/.gradle
      cat > ~/.gradle/init.gradle << EOF
      allprojects {
          repositories {
              maven {
                  url "$GRADLE_REGISTRY_URL"
                  credentials {
                      username = "$REGISTRY_USER"
                      password = "$REGISTRY_PASS"
                  }
                  allowInsecureProtocol = false
              }
          }
      }
      EOF

Python + pip/uv でプライベートレジストリを使う

pip と uv を設定して、プライベートな PyPI レジストリ (例: Nexus、Artifactory) からパッケージを取得できるようにします。
  • PYPI_REGISTRY_HOST — PyPI レジストリのホスト名 (例: artifactory.example.com/artifactory/api/pypi/pypi-virtual)
  • REGISTRY_USER — レジストリのユーザー名
  • REGISTRY_PASS — レジストリのパスワードまたは API トークン
initialize:
  - name: Install uv
    run: curl -LsSf https://astral.sh/uv/install.sh | sh

maintenance:
  - name: Configure pip for private registry
    run: |
      mkdir -p ~/.config/pip
      cat > ~/.config/pip/pip.conf << EOF
      [global]
      index-url = https://$REGISTRY_USER:$REGISTRY_PASS@${PYPI_REGISTRY_HOST}/simple
      trusted-host = ${PYPI_REGISTRY_HOST}
      EOF

  - name: Configure uv for private registry
    run: |
      # uv は pip.conf を参照しますが、明示的に設定することもできます
      echo "export UV_INDEX_URL=https://$REGISTRY_USER:$REGISTRY_PASS@${PYPI_REGISTRY_HOST}/simple" \
        | sudo tee /etc/profile.d/uv-registry.sh > /dev/null
PyPI で一般的なレジストリ URL パターン:
  • Artifactory: https://artifactory.example.com/artifactory/api/pypi/pypi-virtual/simple
  • Nexus: https://nexus.example.com/repository/pypi-group/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
  • AWS CodeArtifact: https://<domain>.d.codeartifact.<region>.amazonaws.com/pypi/<repo>/simple

Python + Poetry with a private registry

Poetry がプライベートレジストリ上の PyPI レジストリからパッケージを取得できるように設定します。
  • PYPI_REGISTRY_HOST — ご利用の PyPI レジストリのホスト名
  • REGISTRY_USER — レジストリのユーザー名
  • REGISTRY_PASS — レジストリのパスワードまたは API トークン
initialize:
  - name: Install Poetry
    run: curl -sSL https://install.python-poetry.org | python3 -

maintenance:
  - name: Configure Poetry for private registry
    run: |
      poetry config repositories.private "https://${PYPI_REGISTRY_HOST}/simple"
      poetry config http-basic.private "$REGISTRY_USER" "$REGISTRY_PASS"

      # Optionally set the private registry as the default source
      # poetry source add --priority=primary private "https://${PYPI_REGISTRY_HOST}/simple"

スコープ付きプライベートレジストリを使う Node.js + npm

npm を設定して、スコープ付きパッケージ (例: @myorg/*) は GitHub Packages などのプライベートレジストリから取得し、公開パッケージは引き続きデフォルトの npm レジストリから取得するようにします。
  • GITHUB_PACKAGES_TOKENread:packages スコープを持つパーソナルアクセストークンまたは GitHub App トークン
maintenance:
  - name: Configure npm scoped registry
    run: |
      npm config set @myorg:registry https://npm.pkg.github.com
      npm config set //npm.pkg.github.com/:_authToken $GITHUB_PACKAGES_TOKEN
@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>

Node.js + npm with a full private registry mirror

スコープ付きパッケージだけでなく、すべての npm パッケージをプライベートレジストリ経由にします。
  • NPM_REGISTRY_URL — npm レジストリの完全な URL (例: https://artifactory.example.com/artifactory/api/npm/npm-virtual)
  • NPM_REGISTRY_HOST — プロトコルを含まないホスト名のみ (例: artifactory.example.com)
  • REGISTRY_TOKEN — レジストリ用の npm 認証トークン
maintenance:
  - name: Configure npm to use private registry
    run: |
      npm config set registry $NPM_REGISTRY_URL
      npm config set //${NPM_REGISTRY_HOST}/:_authToken $REGISTRY_TOKEN
      npm config set strict-ssl true

Node.js + pnpm with a private registry

pnpm がプライベートレジストリからパッケージを取得できるように設定します。
pnpm は Devin のベースイメージに プリインストール されています。インストール手順はスキップして、レジストリの設定のみを行えます。
  • NPM_REGISTRY_URL — npm レジストリの完全な URL
  • NPM_REGISTRY_HOST — プロトコルを含まないホスト名のみ
  • REGISTRY_TOKEN — レジストリ用の npm 認証トークン
initialize:
  - name: Install pnpm
    run: npm install -g pnpm

maintenance:
  - name: Configure pnpm for private registry
    run: |
      pnpm config set registry $NPM_REGISTRY_URL
      pnpm config set //${NPM_REGISTRY_HOST}/:_authToken $REGISTRY_TOKEN

プライベートレジストリを使用する Node.js + Yarn

Yarn (Classic v1 または Berry v2+) を設定して、プライベートレジストリからパッケージを取得できるようにします。
Yarn Classic (v1) は Devin のベースイメージにプリインストールされています。v1 のみが必要な場合は、インストール手順をスキップしてください。
  • NPM_REGISTRY_URL — npm/Yarn レジストリの完全な URL
  • REGISTRY_TOKEN — レジストリの認証トークン (Berry のみ)
initialize:
  - name: Install Yarn Classic
    run: npm install -g yarn

maintenance:
  - name: Configure Yarn for private registry
    run: |
      yarn config set registry "$NPM_REGISTRY_URL"
      # scoped packages の場合:
      # yarn config set @myorg:registry "https://npm.pkg.github.com"

Go でプライベートモジュールプロキシを使用する

Go をインストールし、Go がプライベートモジュールプロキシ (例: Athens、Artifactory、または GOPROXY エンドポイント) 経由でモジュールを解決するように設定します。
  • GO_PROXY_URL — Go モジュールプロキシの URL (例: https://athens.corp.internal)
  • GIT_TOKEN — Go モジュールをホストする非公開 Git リポジトリ用のパーソナルアクセストークン
initialize:
  - name: Install Go
    run: |
      GO_VERSION=1.23.5
      ARCH=$(dpkg --print-architecture)
      curl -fsSL "https://go.dev/dl/go${GO_VERSION}.linux-${ARCH}.tar.gz" \
        | sudo tar -xz -C /usr/local
      echo 'export PATH="/usr/local/go/bin:$HOME/go/bin:$PATH"' \
        | sudo tee /etc/profile.d/golang.sh > /dev/null

  - name: Configure Go for private modules
    run: |
      cat << 'GOENV' | sudo tee /etc/profile.d/go-private.sh > /dev/null
      export GOPROXY="$GO_PROXY_URL,direct"
      export GONOSUMCHECK="corp.internal/*,github.com/myorg/*"
      export GOPRIVATE="corp.internal/*,github.com/myorg/*"
      GOENV

maintenance:
  - name: Authenticate Go private modules
    run: |
      git config --global url."https://$GIT_TOKEN@github.com/myorg/".insteadOf "https://github.com/myorg/"
一般的な Go プロキシ URL パターン:
  • Artifactory: https://artifactory.example.com/artifactory/go-virtual
  • Nexus: https://nexus.example.com/repository/go-proxy
  • Athens: https://athens.corp.internal

.NET + NuGet でプライベートフィードを使用する

.NET SDK をインストールし、NuGet がプライベートフィード (例: Azure Artifacts、Artifactory) からパッケージを取得できるように設定します。
  • NUGET_FEED_URL — NuGet フィードの URL (例: https://pkgs.dev.azure.com/org/project/_packaging/feed/nuget/v3/index.json)
  • REGISTRY_USER — レジストリのユーザー名
  • REGISTRY_PASS — レジストリのパスワードまたは API トークン
initialize:
  - name: Install .NET SDK
    run: |
      curl -fsSL https://dot.net/v1/dotnet-install.sh -o /tmp/dotnet-install.sh
      chmod +x /tmp/dotnet-install.sh
      sudo /tmp/dotnet-install.sh --channel 8.0 --install-dir /usr/local/dotnet
      echo 'export DOTNET_ROOT=/usr/local/dotnet' \
        | sudo tee /etc/profile.d/dotnet.sh > /dev/null
      echo 'export PATH="$DOTNET_ROOT:$DOTNET_ROOT/tools:$PATH"' \
        | sudo tee -a /etc/profile.d/dotnet.sh > /dev/null
      rm /tmp/dotnet-install.sh

maintenance:
  - name: Configure NuGet for private feed
    run: |
      dotnet nuget add source "$NUGET_FEED_URL" \
        --name private-feed \
        --username "$REGISTRY_USER" \
        --password "$REGISTRY_PASS" \
        --store-password-in-clear-text

      # 必要に応じてデフォルトの nuget.org ソースを無効にする
      # dotnet nuget disable source nuget.org
一般的な NuGet フィードの URL:
  • Azure Artifacts: https://pkgs.dev.azure.com/org/project/_packaging/feed/nuget/v3/index.json
  • Artifactory: https://artifactory.example.com/artifactory/api/nuget/v3/nuget-virtual
  • GitHub Packages: https://nuget.pkg.github.com/myorg/index.json
  • Nexus: https://nexus.example.com/repository/nuget-hosted/index.json

Docker でプライベートコンテナレジストリを使用する

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 トークン
initialize:
  - name: Create Docker config directory
    run: sudo mkdir -p /etc/docker

maintenance:
  - name: Configure Docker for private registry
    run: |
      # レジストリミラーを設定する(オプション — Docker Hub のプルをレジストリ経由でルーティングする)
      cat << EOF | sudo tee /etc/docker/daemon.json > /dev/null
      {
        "registry-mirrors": ["$DOCKER_MIRROR_URL"]
      }
      EOF
      sudo systemctl restart docker || true

      # プライベートコンテナレジストリにログインする
      echo "$DOCKER_REGISTRY_PASS" | docker login "$DOCKER_REGISTRY_URL" \
        --username "$DOCKER_REGISTRY_USER" \
        --password-stdin
一般的なコンテナレジストリの 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

Rust + Cargo でプライベートレジストリを使用する

Rust をインストールし、Cargo がプライベートレジストリからクレートを解決できるように設定します。
Rust (rustup 経由) と Cargo は、Devin のベースイメージにプリインストールされています。デフォルトの安定版ツールチェーンで十分な場合は、インストール手順をスキップしてください。必要なのはレジストリの設定だけです。
  • CARGO_REGISTRY_INDEX — 非公開レジストリのインデックスの URL (例: sparse+https://cargo.corp.internal/api/v1/crates/)
  • CARGO_REGISTRY_TOKEN — 非公開レジストリ用の認証トークン
initialize:
  - name: Install Rust
    run: |
      curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs \
        | sh -s -- -y --default-toolchain stable
      echo 'source "$HOME/.cargo/env"' \
        | sudo tee /etc/profile.d/rust.sh > /dev/null

maintenance:
  - name: Configure Cargo for private registry
    run: |
      mkdir -p ~/.cargo
      cat > ~/.cargo/config.toml << EOF
      [registries.private]
      index = "$CARGO_REGISTRY_INDEX"
      token = "$CARGO_REGISTRY_TOKEN"

      [source.crates-io]
      replace-with = "private"

      [source.private]
      registry = "$CARGO_REGISTRY_INDEX"
      EOF
crates.io を置き換えずに非公開レジストリを追加するだけでよい場合は、[source.crates-io] セクションと [source.private] セクションを削除し、cargo install --registry private を利用するか、Cargo.toml[dependencies] my-crate = { version = "1.0", registry = "private" } を利用します。

Ruby + Bundler でプライベート gem サーバーを使用する

Ruby をインストールし、Bundler がプライベート gem サーバーから gem を取得できるように設定します。
  • GEM_SERVER_URL — 非公開 gem サーバーの URL (例: https://artifactory.example.com/artifactory/api/gems/gems-virtual)
  • REGISTRY_USER — レジストリのユーザー名
  • REGISTRY_PASS — レジストリのパスワードまたは API トークン
initialize:
  - name: Install Ruby
    run: |
      sudo apt-get update -qq
      sudo DEBIAN_FRONTEND=noninteractive apt-get install -y -qq ruby-full

maintenance:
  - name: Configure Bundler for private gem server
    run: |
      bundle config set mirror.https://rubygems.org "$GEM_SERVER_URL"
      bundle config set "$GEM_SERVER_URL" "$REGISTRY_USER:$REGISTRY_PASS"
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>

AWS CodeArtifact トークンの更新

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 — 各エコシステムのリポジトリ名
maintenance:
  - name: Refresh CodeArtifact auth token
    run: |
      # 新しいトークンを取得する(12時間有効)
      export CODEARTIFACT_AUTH_TOKEN=$(aws codeartifact get-authorization-token \
        --domain $CA_DOMAIN \
        --domain-owner $CA_DOMAIN_OWNER \
        --region $CA_REGION \
        --query authorizationToken \
        --output text)

      CA_ENDPOINT="https://${CA_DOMAIN}-${CA_DOMAIN_OWNER}.d.codeartifact.${CA_REGION}.amazonaws.com"

      # npmを設定する
      npm config set registry "${CA_ENDPOINT}/npm/${CA_NPM_REPO}/"
      npm config set "//${CA_DOMAIN}-${CA_DOMAIN_OWNER}.d.codeartifact.${CA_REGION}.amazonaws.com/npm/${CA_NPM_REPO}/:_authToken" "$CODEARTIFACT_AUTH_TOKEN"

      # pipを設定する
      mkdir -p ~/.config/pip
      cat > ~/.config/pip/pip.conf << EOF
      [global]
      index-url = https://aws:${CODEARTIFACT_AUTH_TOKEN}@${CA_DOMAIN}-${CA_DOMAIN_OWNER}.d.codeartifact.${CA_REGION}.amazonaws.com/pypi/${CA_PYPI_REPO}/simple/
      EOF

      # Mavenを設定する(任意)
      mkdir -p ~/.m2
      cat > ~/.m2/settings.xml << EOF
      <settings>
        <servers>
          <server>
            <id>codeartifact</id>
            <username>aws</username>
            <password>${CODEARTIFACT_AUTH_TOKEN}</password>
          </server>
        </servers>
        <mirrors>
          <mirror>
            <id>codeartifact</id>
            <mirrorOf>*</mirrorOf>
            <url>${CA_ENDPOINT}/maven/${CA_MAVEN_REPO}/</url>
          </mirror>
        </mirrors>
      </settings>
      EOF

PHP + Composer でプライベートレジストリを使用する

PHP をインストールし、非公開の Packagist または Satis レジストリからパッケージを取得できるように Composer を設定します。
  • COMPOSER_REGISTRY_URL — 非公開の Composer レジストリの URL (例: https://repo.packagist.com/<org>)
  • REGISTRY_USER — レジストリのユーザー名
  • REGISTRY_PASS — レジストリのパスワードまたは API トークン
initialize:
  - name: Install PHP and Composer
    run: |
      sudo apt-get update -qq
      sudo DEBIAN_FRONTEND=noninteractive apt-get install -y -qq \
        php-cli php-mbstring php-xml php-curl unzip

      # Composerをインストール
      curl -sS https://getcomposer.org/installer | php
      sudo mv composer.phar /usr/local/bin/composer

maintenance:
  - name: Configure Composer for private registry
    run: |
      composer config --global repositories.private \
        composer "$COMPOSER_REGISTRY_URL"

      # registryで認証する
      composer config --global http-basic.$(echo "$COMPOSER_REGISTRY_URL" \
        | sed 's|https\?://||;s|/.*||') "$REGISTRY_USER" "$REGISTRY_PASS"

      # デフォルトのpackagist.orgを無効にする場合(任意)
      # composer config --global repositories.packagist false
一般的な 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

リポジトリ固有の使用例

これらの使用例では、リポジトリごとのビルド手順、依存関係の管理、Knowledge エントリを設定します。設定は Settings > Environment > [your repo] から行えます。

標準的な Node.js プロジェクト

lint、test、build のコマンドを備えた標準的な Node.js プロジェクトです。
initialize: |
  npm install -g pnpm

maintenance: |
  pnpm install

knowledge:
  - name: lint
    contents: |
      Run `pnpm lint` to check for errors.
      Run `pnpm lint --fix` to auto-fix.
  - name: test
    contents: |
      Run `pnpm test` for the full test suite.
      Run `pnpm test -- --watch` during development.
  - name: build
    contents: |
      Run `pnpm build` to create a production build.
      Output goes to the `dist/` directory.

標準的なPythonプロジェクト

依存関係の管理にuvを使うPythonプロジェクト。
initialize:
  - name: Install uv
    run: curl -LsSf https://astral.sh/uv/install.sh | sh

maintenance:
  - name: Sync dependencies
    run: uv sync

knowledge:
  - name: lint
    contents: |
      Run `uv run ruff check .` to lint.
      Run `uv run ruff format .` to format.
  - name: test
    contents: |
      Run `uv run pytest` for the full test suite.
      Run `uv run pytest -x` to stop on first failure.

Standard Java project

Maven を利用して依存関係を管理する Java プロジェクト。
maintenance:
  - name: Resolve dependencies
    run: mvn dependency:resolve -U -q

knowledge:
  - name: build
    contents: |
      Run `mvn clean package` to build.
      Run `mvn clean package -DskipTests` to build without tests.
  - name: test
    contents: |
      Run `mvn test` for unit tests.
      Run `mvn verify` for integration tests.
  - name: lint
    contents: |
      Run `mvn checkstyle:check` for style checks.
      Run `mvn spotbugs:check` for bug detection.

Standard Go project

標準的なツールチェーンを利用する Go プロジェクト。
maintenance:
  - name: Download dependencies
    run: go mod download

knowledge:
  - name: build
    contents: |
      Run `go build ./...` to build all packages.
      Run `go build -o bin/app ./cmd/app` to build the main binary.
  - name: test
    contents: |
      Run `go test ./...` for all tests.
      Run `go test -race ./...` to include race detection.
      Run `go test -v ./pkg/... -run TestSpecific` for a specific test.
  - name: lint
    contents: |
      Run `golangci-lint run` for linting (if installed).
      Run `go vet ./...` for basic static analysis.

Standard Rust project

Cargo を利用する Rust プロジェクト。
maintenance:
  - name: Fetch dependencies
    run: cargo fetch

knowledge:
  - name: build
    contents: |
      Run `cargo build` for a debug build.
      Run `cargo build --release` for a release build.
  - name: test
    contents: |
      Run `cargo test` for all tests.
      Run `cargo test -- --test-threads=1` for sequential execution.
  - name: lint
    contents: |
      Run `cargo clippy -- -D warnings` for lint checks.
      Run `cargo fmt --check` to verify formatting.

複数サービスを含むモノレポ

フロントエンドとバックエンドが分かれており、それぞれ異なるパッケージマネージャーを使用するモノレポ。
initialize:
  - name: Install pnpm
    run: npm install -g pnpm
  - name: Install uv
    run: curl -LsSf https://astral.sh/uv/install.sh | sh

maintenance:
  - name: Install frontend dependencies
    run: (cd packages/frontend && pnpm install)
  - name: Install backend dependencies
    run: (cd packages/backend && uv sync)
  - name: Build shared library
    run: (cd packages/shared && pnpm install && pnpm build)

knowledge:
  - name: structure
    contents: |
      This is a monorepo with three packages:
      - `packages/frontend` — React app (TypeScript, pnpm)
      - `packages/backend` — Python API (FastAPI, uv)
      - `packages/shared` — Shared TypeScript utilities (must be built before frontend)
  - name: frontend
    contents: |
      Run `cd packages/frontend && pnpm dev` to start the dev server.
      Run `cd packages/frontend && pnpm lint` to lint.
      Run `cd packages/frontend && pnpm test` to test.
  - name: backend
    contents: |
      Run `cd packages/backend && uv run uvicorn app.main:app --reload` to start the API.
      Run `cd packages/backend && uv run ruff check .` to lint.
      Run `cd packages/backend && uv run pytest` to test.
ステップごとに作業ディレクトリがリセットされるよう、cd dir && command ではなくサブシェル (cd dir && command) を使用してください。

複数のJDKバージョンがあるモノレポ

異なるサービスごとに異なるJDKバージョンが必要なJavaモノレポです。セットアップ時に両方のJDKをインストールし、その後 Knowledge エントリを使って、各サービスで使用する JAVA_HOME をDevinに指定します。
initialize:
  - name: Install JDK 17 (primary)
    run: |
      sudo apt-get update -qq
      sudo DEBIAN_FRONTEND=noninteractive apt-get install -y -qq openjdk-17-jdk-headless
      echo 'export JAVA_HOME=/usr/lib/jvm/java-17-openjdk-amd64' \
        | sudo tee /etc/profile.d/java.sh > /dev/null

  - name: Install JDK 11 (legacy service)
    run: |
      sudo DEBIAN_FRONTEND=noninteractive apt-get install -y -qq openjdk-11-jdk-headless

maintenance:
  - name: Warm dependency caches
    run: |
      export JAVA_HOME=/usr/lib/jvm/java-17-openjdk-amd64
      (cd services/api && ./gradlew dependencies --refresh-dependencies)

      export JAVA_HOME=/usr/lib/jvm/java-11-openjdk-amd64
      (cd services/legacy && ./gradlew dependencies --refresh-dependencies)

knowledge:
  - name: build_api
    contents: |
      Build the API service (JDK 17):
        JAVA_HOME=/usr/lib/jvm/java-17-openjdk-amd64 \
        cd services/api && ./gradlew clean build
  - name: build_legacy
    contents: |
      Build the legacy service (JDK 11):
        JAVA_HOME=/usr/lib/jvm/java-11-openjdk-amd64 \
        cd services/legacy && ./gradlew clean build
  - name: test_all
    contents: |
      Run tests for all services:
        JAVA_HOME=/usr/lib/jvm/java-17-openjdk-amd64 \
        (cd services/api && ./gradlew test)

        JAVA_HOME=/usr/lib/jvm/java-11-openjdk-amd64 \
        (cd services/legacy && ./gradlew test)

pre-commit フック

プロジェクトで pre-commit フックを利用している場合は、毎回のセッションですぐに使えるよう、maintenance にインストールしてください。
initialize:
  - name: Install pre-commit
    run: pip install pre-commit

maintenance:
  - name: Install pre-commit hooks
    run: pre-commit install --install-hooks
プロジェクトですでに pre-commit を開発依存関係として使用している場合 (例: pyproject.toml) 、initialize ステップはスキップし、代わりに maintenance では uv run pre-commit install --install-hooks または pipx run pre-commit install --install-hooks を利用してください。

充実したKnowledgeエントリ

プロジェクトのアーキテクチャ、規約、ワークフローを knowledge エントリに文書化します。
knowledge:
  - name: architecture
    contents: |
      This is a microservices application:
      - `api-gateway/` — Express.js reverse proxy (port 3000)
      - `auth-service/` — JWT authentication service (port 3001)
      - `user-service/` — User CRUD service (port 3002)
      - `shared/` — Shared protobuf definitions and utilities

      Services communicate via gRPC. The API gateway is the only public-facing service.

  - name: conventions
    contents: |
      - All API responses use the `{ data, error, meta }` envelope format
      - Database migrations are in `migrations/` and run with `npm run migrate`
      - Environment-specific config is in `config/{env}.json`
      - Feature flags are managed via LaunchDarkly (SDK key in $LD_SDK_KEY)

  - name: testing
    contents: |
      Unit tests: `npm test`
      Integration tests: `npm run test:integration` (requires Docker for Postgres)
      E2E tests: `npm run test:e2e` (requires all services running)

      Coverage report: `npm run test:coverage` (must be > 80% for CI to pass)

  - name: deployment
    contents: |
      CI/CD runs on GitHub Actions. Merges to `main` auto-deploy to staging.
      Production deploys require a manual approval step in the Actions UI.
      Docker images are pushed to ECR: 123456789.dkr.ecr.us-east-1.amazonaws.com/

組み合わせ使用例

これらの使用例では、Enterprise レベルと組織レベルの設定をどのように組み合わせるかを示します。実際には、これらはスコープごとに分けて使用しますが、ここでは参考用にまとめて示しています。

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) : レジストリの認証情報 (各セッションで更新)
ここでは参考用にまとめて示しています。
initialize:
  # ── アカウント全体: ネットワークと信頼 ──────────────────────────────────────

  - name: 企業CA証明書のインストール
    run: |
      echo "$CORP_ROOT_CA_B64" | base64 -d \
        | sudo tee /usr/local/share/ca-certificates/corp-root-ca.crt > /dev/null
      sudo update-ca-certificates
      echo 'export NODE_EXTRA_CA_CERTS=/usr/local/share/ca-certificates/corp-root-ca.crt' \
        | sudo tee /etc/profile.d/node-ca.sh > /dev/null

  - name: システム全体のプロキシ設定
    run: |
      cat << 'PROXY' | sudo tee /etc/profile.d/proxy.sh > /dev/null
      export http_proxy="$CORP_HTTP_PROXY"
      export https_proxy="$CORP_HTTPS_PROXY"
      export no_proxy="$CORP_NO_PROXY"
      export HTTP_PROXY="$CORP_HTTP_PROXY"
      export HTTPS_PROXY="$CORP_HTTPS_PROXY"
      export NO_PROXY="$CORP_NO_PROXY"
      PROXY
      source /etc/profile.d/proxy.sh

  # ── 組織全体: 言語ランタイム ──────────────────────────────────────────

  - name: JDK 17 + Maven のインストール
    run: |
      sudo apt-get update -qq
      sudo DEBIAN_FRONTEND=noninteractive apt-get install -y -qq openjdk-17-jdk-headless
      echo 'export JAVA_HOME=/usr/lib/jvm/java-17-openjdk-amd64' \
        | sudo tee /etc/profile.d/java.sh > /dev/null

      MAVEN_VERSION=3.9.9
      curl -fsSL "https://archive.apache.org/dist/maven/maven-3/${MAVEN_VERSION}/binaries/apache-maven-${MAVEN_VERSION}-bin.tar.gz" \
        | sudo tar -xz -C /opt
      sudo ln -sf /opt/apache-maven-${MAVEN_VERSION}/bin/mvn /usr/local/bin/mvn

  - name: uv のインストール
    run: curl -LsSf https://astral.sh/uv/install.sh | sh

maintenance:
  # ── アカウント全体: git プロキシ (セッションごとに更新) ───────────────────

  - name: git プロキシの設定
    run: |
      git config --global http.proxy "$CORP_HTTP_PROXY"
      git config --global https.proxy "$CORP_HTTPS_PROXY"

  # ── 組織全体: レジストリ認証情報 (セッションごとに更新) ──────────────

  - name: Maven → Artifactory の設定
    run: |
      mkdir -p ~/.m2
      cat > ~/.m2/settings.xml << EOF
      <settings>
        <mirrors>
          <mirror>
            <id>artifactory</id>
            <mirrorOf>*</mirrorOf>
            <url>$ARTIFACTORY_MAVEN_URL</url>
          </mirror>
        </mirrors>
        <servers>
          <server>
            <id>artifactory</id>
            <username>$ARTIFACTORY_USER</username>
            <password>$ARTIFACTORY_TOKEN</password>
          </server>
        </servers>
      </settings>
      EOF

  - name: pip/uv → Artifactory PyPI の設定
    run: |
      mkdir -p ~/.config/pip
      cat > ~/.config/pip/pip.conf << EOF
      [global]
      index-url = $ARTIFACTORY_PYPI_URL
      trusted-host = $(echo "$ARTIFACTORY_PYPI_URL" | sed 's|https\?://||;s|/.*||')
      EOF

      echo "export UV_INDEX_URL=$ARTIFACTORY_PYPI_URL" \
        | sudo tee /etc/profile.d/uv-registry.sh > /dev/null

  - name: npm → Artifactory の設定
    run: |
      npm config set registry "$ARTIFACTORY_NPM_URL"
      REGISTRY_HOST=$(echo "$ARTIFACTORY_NPM_URL" | sed 's|https\?://||;s|/.*||')
      npm config set "//${REGISTRY_HOST}/:_authToken" "$ARTIFACTORY_TOKEN"

  - name: Docker → Artifactory の設定
    run: |
      echo "$ARTIFACTORY_TOKEN" | docker login "$ARTIFACTORY_DOCKER_URL" \
        --username "$ARTIFACTORY_USER" \
        --password-stdin
この例では、すべてのレジストリが同じ 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 の非公開モジュール用のパーソナルアクセストークン
maintenance:
  # Maven → Nexus
  - name: Maven → Nexus を設定する
    run: |
      mkdir -p ~/.m2
      cat > ~/.m2/settings.xml << EOF
      <settings>
        <mirrors>
          <mirror>
            <id>nexus</id>
            <mirrorOf>*</mirrorOf>
            <url>$NEXUS_MAVEN_URL</url>
          </mirror>
        </mirrors>
        <servers>
          <server>
            <id>nexus</id>
            <username>$NEXUS_USER</username>
            <password>$NEXUS_PASS</password>
          </server>
        </servers>
      </settings>
      EOF

  # npm → GitHub Packages(スコープ付き)
  - name: npm → GitHub Packages を設定する
    run: |
      npm config set @myorg:registry https://npm.pkg.github.com
      npm config set //npm.pkg.github.com/:_authToken $GITHUB_PACKAGES_TOKEN

  # Python → Artifactory
  - name: pip → Artifactory を設定する
    run: |
      mkdir -p ~/.config/pip
      cat > ~/.config/pip/pip.conf << EOF
      [global]
      index-url = https://$ARTIFACTORY_USER:$ARTIFACTORY_TOKEN@artifactory.example.com/artifactory/api/pypi/pypi-virtual/simple
      EOF

  # Go → git 経由の非公開モジュール
  - name: Go の非公開モジュールを設定する
    run: |
      git config --global url."https://$GIT_TOKEN@github.com/myorg/".insteadOf "https://github.com/myorg/"

プライベートミラーを使用するエアギャップ環境

完全にエアギャップ化された環境では、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
initialize:
  - name: Install corporate CA certificate
    run: |
      echo "$CORP_ROOT_CA_B64" | base64 -d \
        | sudo tee /usr/local/share/ca-certificates/corp-root-ca.crt > /dev/null
      sudo update-ca-certificates

  - name: Replace apt sources with internal mirror
    run: |
      sudo sed -i "s|http://archive.ubuntu.com/ubuntu|$APT_MIRROR_URL|g" /etc/apt/sources.list
      sudo sed -i "s|http://security.ubuntu.com/ubuntu|$APT_MIRROR_URL|g" /etc/apt/sources.list
      sudo apt-get update -qq

  - name: Install JDK from internal mirror
    run: |
      # 内部アーティファクトストアからJDK tarballをダウンロード
      curl -fsSL -u "$MIRROR_USER:$MIRROR_PASS" "$JDK_TARBALL_URL" \
        | sudo tar -xz -C /usr/local
      sudo ln -sf /usr/local/jdk-17.*/bin/java /usr/local/bin/java
      sudo ln -sf /usr/local/jdk-17.*/bin/javac /usr/local/bin/javac
      echo "export JAVA_HOME=$(ls -d /usr/local/jdk-17.*)" \
        | sudo tee /etc/profile.d/java.sh > /dev/null

  - name: Install Node.js from internal mirror
    run: |
      curl -fsSL -u "$MIRROR_USER:$MIRROR_PASS" "$NODE_TARBALL_URL" \
        | sudo tar -xz -C /usr/local --strip-components=1

maintenance:
  - name: Configure all package managers for internal registry
    run: |
      # Maven
      mkdir -p ~/.m2
      cat > ~/.m2/settings.xml << EOF
      <settings>
        <mirrors>
          <mirror>
            <id>internal</id>
            <mirrorOf>*</mirrorOf>
            <url>$INTERNAL_MAVEN_URL</url>
          </mirror>
        </mirrors>
        <servers>
          <server>
            <id>internal</id>
            <username>$MIRROR_USER</username>
            <password>$MIRROR_PASS</password>
          </server>
        </servers>
      </settings>
      EOF

      # npm
      npm config set registry "$INTERNAL_NPM_URL"

      # pip
      mkdir -p ~/.config/pip
      cat > ~/.config/pip/pip.conf << EOF
      [global]
      index-url = $INTERNAL_PYPI_URL
      EOF
エアギャップ環境では、Devinが必要とするすべてのツール (言語ランタイム、CLIツールなど) が社内ミラーで利用できるようにしてください。公開レジストリやダウンロードサイトにはアクセスできません。

VPN + 証明書 + プロキシ + 多言語対応

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:
  # 1. VPN — 内部リソースにアクセスできるよう、最初に実行する必要があります
  - name: Establish VPN connection
    run: |
      sudo DEBIAN_FRONTEND=noninteractive apt-get update -qq
      sudo DEBIAN_FRONTEND=noninteractive apt-get install -y -qq openvpn
      sudo mkdir -p /etc/openvpn/client
      echo "$VPN_CONFIG_B64" | base64 -d \
        | sudo tee /etc/openvpn/client/corp.conf > /dev/null
      sudo systemctl daemon-reload
      sudo systemctl enable --now openvpn-client@corp
      for i in $(seq 1 30); do
        if ip link show tun0 >/dev/null 2>&1; then break; fi
        sleep 1
      done

  # 2. DNS — 内部ホスト名を解決する
  - name: Configure DNS
    run: |
      sudo mkdir -p /etc/systemd/resolved.conf.d
      cat << 'DNS' | sudo tee /etc/systemd/resolved.conf.d/corp.conf > /dev/null
      [Resolve]
      DNS=10.0.0.53
      Domains=corp.internal
      DNS
      sudo systemctl restart systemd-resolved || true

  # 3. 証明書 — 内部CAを信頼する
  - name: Install CA certificate
    run: |
      echo "$CORP_ROOT_CA_B64" | base64 -d \
        | sudo tee /usr/local/share/ca-certificates/corp-root-ca.crt > /dev/null
      sudo update-ca-certificates
      echo 'export NODE_EXTRA_CA_CERTS=/usr/local/share/ca-certificates/corp-root-ca.crt' \
        | sudo tee /etc/profile.d/node-ca.sh > /dev/null

  # 4. プロキシ — 企業プロキシ経由でトラフィックをルーティングする
  - name: Configure proxy
    run: |
      cat << 'PROXY' | sudo tee /etc/profile.d/proxy.sh > /dev/null
      export http_proxy="$CORP_HTTP_PROXY"
      export https_proxy="$CORP_HTTPS_PROXY"
      export no_proxy="$CORP_NO_PROXY"
      export HTTP_PROXY="$CORP_HTTP_PROXY"
      export HTTPS_PROXY="$CORP_HTTPS_PROXY"
      export NO_PROXY="$CORP_NO_PROXY"
      PROXY
      source /etc/profile.d/proxy.sh

  # 5. language runtimes
  - name: Install JDK 17
    run: |
      sudo DEBIAN_FRONTEND=noninteractive apt-get install -y -qq openjdk-17-jdk-headless
      echo 'export JAVA_HOME=/usr/lib/jvm/java-17-openjdk-amd64' \
        | sudo tee /etc/profile.d/java.sh > /dev/null

  - name: Install Node.js tooling
    run: npm install -g pnpm

  - name: Install uv
    run: curl -LsSf https://astral.sh/uv/install.sh | sh

maintenance:
  - name: Configure git proxy
    run: |
      git config --global http.proxy "$CORP_HTTP_PROXY"
      git config --global https.proxy "$CORP_HTTPS_PROXY"

  - name: Configure Maven
    run: |
      mkdir -p ~/.m2
      cat > ~/.m2/settings.xml << EOF
      <settings>
        <mirrors>
          <mirror>
            <id>corp</id>
            <mirrorOf>*</mirrorOf>
            <url>$MAVEN_REGISTRY_URL</url>
          </mirror>
        </mirrors>
        <servers>
          <server>
            <id>corp</id>
            <username>$REGISTRY_USER</username>
            <password>$REGISTRY_PASS</password>
          </server>
        </servers>
      </settings>
      EOF

  - name: Configure npm
    run: |
      npm config set registry "$NPM_REGISTRY_URL"
      NPM_HOST=$(echo "$NPM_REGISTRY_URL" | sed 's|https\?://||;s|/.*||')
      npm config set "//${NPM_HOST}/:_authToken" "$REGISTRY_TOKEN"

  - name: Configure pip/uv
    run: |
      mkdir -p ~/.config/pip
      cat > ~/.config/pip/pip.conf << EOF
      [global]
      index-url = https://$REGISTRY_USER:$REGISTRY_PASS@${PYPI_REGISTRY_HOST}/simple
      EOF
      echo "export UV_INDEX_URL=https://$REGISTRY_USER:$REGISTRY_PASS@${PYPI_REGISTRY_HOST}/simple" \
        | sudo tee /etc/profile.d/uv-registry.sh > /dev/null
initialize ステップでは順序が重要です。 まず VPN (内部ホストにアクセスできるようにするため) 、次に DNS (名前解決を行えるようにするため) 、その次に証明書 (HTTPS を利用できるようにするため) 、続いてプロキシ (トラフィックが正しくルーティングされるようにするため) 、最後に言語ランタイム (内部ミラーからダウンロードする場合があるため) を設定する必要があります。

適切な設定を書くためのヒント

  • まずセッションでコマンドをテストする — 設定に追加する前に、Devin のセッションでコマンドを手動で実行してください。完全なビルド サイクルを待つよりも、そのほうが速く確認できます。
  • 一度だけインストールするツールには initialize、依存関係には maintenance を利用する — インストールに数分かかるもの (コンパイラ、大きなバイナリ、グローバル ツール) は initialize に入れます。短時間で終わる依存関係のコマンド (npm installuv sync) は maintenance に入れます。
  • maintenance コマンドは高速に保つ — 2 分未満を目安にしてください。これらは各セッションの開始時に実行されます。
  • 環境変数には $ENVRC を利用する.bashrc.profile には書き込まないでください。ステップやセッションをまたいで変数を設定するためのサポート対象の仕組みは $ENVRC です。
  • ステップには名前を付けるname フィールドを使う展開形式にすると、ビルド ログで失敗箇所を大幅に特定しやすくなります。
  • モノレポではサブシェルを利用する(cd packages/foo && npm install) はサブシェル内で実行されるため、後続のステップはディレクトリ変更の影響を受けません。
構文と実行の詳細については、YAML Reference を参照してください。ビルド失敗のトラブルシューティングについては、Troubleshooting & FAQ を参照してください。