方法: CI から Orchestrator にデプロイする

このページでは、Azure DevOps、GitHub Actions、Jenkins、GitLab のいずれで実行するかに関係なく、UiPath ソリューションをデプロイするすべての CI パイプラインに必要なもの ( 認証、キャッシュ、ツールのプレインストール、バージョンのピン留め) について説明します。プラットフォーム固有の構文は レシピページ にあります — この構文は可動部分を提供するので、自信を持って読むことができます。

優れたCIパイプラインの形状

ソリューションを出荷する運用パイプラインには、常に同じ 5 つの段階があります。

1. Node.js を設定します (バージョン 18 以降)。
2. ピン留めされたバージョンで @uipath/cliをインストールします。
3. 使用するツールをプリインストールします (最初の uip 呼び出しが他の呼び出しよりも遅くならないようにするため)。
4. シークレットのプレフィックスとして env. を使用して外部アプリケーションで認証します。
5. パック、パブリッシュ、デプロイ 、およびオプションでテストします。

ステージ 4 は、シークレット構文がプラットフォーム固有であるため、プラットフォーム間で最も異なるステージです。ステージ1〜3と5はどこでもほぼ同じです。

認証: 外部アプリケーション + 環境プレフィックス

ヘッドレス環境では、 外部アプリケーション (クライアント資格情報) を使用して認証します。UiPath ポータルで認証を作成する方法について詳しくは、「 認証 — フロー 2 」をご覧ください。

資格情報をプラットフォームのシークレット ストアに保存します (ソース管理やプレーンな環境変数ファイルには保存しません)。これらを特別なenv.プレフィックスを付けてuip loginに渡します。

uip login \
  --client-id env.UIPATH_CLIENT_ID \
  --client-secret env.UIPATH_CLIENT_SECRET \
  --tenant "$UIPATH_TENANT"

env.VAR_NAME プレフィックスはuip実行時に VAR_NAME 環境変数から値を読み取るように指示します。これにより、コマンドラインで展開され、psを介して漏洩する可能性のある--client-secret "$UIPATH_CLIENT_SECRET"とは異なり、シェルの履歴とプロセスリストから秘密が守られます。

警告:

暗黙的な環境変数の読み取りに頼らないでください。フラグなしで UIPATH_CLIENT_ID / UIPATH_CLIENT_SECRET のみを設定すると、認証 されません — この機能は CLI 1.0 より前に削除されました。常に旗を渡します。 env.VAR_NAME は、環境から値を解決したい場合に使用します。

パイプラインで、参照する正確な変数名でシークレットをステップの環境に挿入します。

プラットフォーム	YAML / Groovyの秘密構文	ステップに渡された形状
GitHub Actions	${{ secrets.UIPATH_CLIENT_ID }} 次の値に含まれる env:	UIPATH_CLIENT_ID: <value>
Azure DevOps	$(UIPATH_CLIENT_ID) の変数グループから env:	UIPATH_CLIENT_ID: $(UIPATH_CLIENT_ID)
Jenkins	credentialsId: 'UIPATH_CLIENT_ID' 中に withCredentials	次の形式でエクスポート $UIPATH_CLIENT_ID
GitLab CI	UIPATH_CLIENT_ID CI/CD 変数、Protected+Masked とマーク	$UIPATH_CLIENT_ID 次の値に含まれる script

いずれの場合も、 uip login コマンド自体は同じに見えます — --client-id env.UIPATH_CLIENT_ID --client-secret env.UIPATH_CLIENT_SECRET.環境変数がステップに到達する方法のみが変更されます。

セッション ストレージ

uip login は、セッションを .uipath/ フォルダー内に保持します。ほとんどのCIランナーでは、作業ディレクトリはすでにステートレスであるため、セッションはジョブで終了します。ランナーが永続的な場合は、ジョブの最後に uip logout があるセッションを削除するか、ジョブローカルパスに --file を設定します。「セッションと資格情報」をご覧ください。

1 つのパイプラインで複数の組織

1 つのセッションでは、一度に 1 つの組織と 1 つのテナントが保持されます。同じパイプラインで異なる UiPath 組織を対象にするには (たとえば、ソリューションを構築組織から顧客組織に昇格させるには)、別の外部アプリケーションを使用して 2 つのブロック間のuip loginを再実行します。ログインするたびに、前のセッションが上書きされます。

組織ごとに 1 つの外部アプリケーションを作成します (それぞれに独自の OR.* スコープを設定します)。クライアント ID とシークレットの両方をパイプラインのシークレット ストアに個別の名前で格納します。

set -euo pipefail

# --- Organization A ---
uip login \
  --client-id env.ORGA_CLIENT_ID \
  --client-secret env.ORGA_CLIENT_SECRET \
  --tenant Prod

uip or folders list
uip solution pack ./my-solution ./dist --version "$SOLUTION_VERSION"
uip solution publish "./dist/my-solution.$SOLUTION_VERSION.zip"

# --- Organization B — this overwrites the previous session ---
uip login \
  --client-id env.ORGB_CLIENT_ID \
  --client-secret env.ORGB_CLIENT_SECRET \
  --tenant Prod

uip solution publish "./dist/my-solution.$SOLUTION_VERSION.zip"
uip solution deploy run \
  --name "my-solution-$GIT_SHA" \
  --package-name my-solution \
  --package-version "$SOLUTION_VERSION" \
  --folder-name MySolution \
  --folder-path Shared

1 つの組織内の異なるテナントでも同じパターンです — ただし、テナントでは 2 回目のログインは必要ありません。uip or …呼び出しで--tenant <name>を渡し、再認証を行わずに 1 つのコマンドでセッション テナントを上書きします。

注:

これは シリアル パターンです。各 uip login 保存されたセッションが上書きされるため、いつでも到達できる組織は 1 つだけです。2 つの組織に対して 同時に コマンドを実行する必要がある場合 (並列マトリックスジョブなど)、各ジョブに独自のランナーまたは独自の --file / HOME スコープを指定します ( 「セッションと資格情報」を参照)。

ビルド時間を決定論的に保つためのツールをプリインストールする

CLI には、ツールはプリインストールされていません。アンインストールされたツールから動詞を初めて実行すると、 uip は npm から動詞を自動インストールします — これはラップトップでは問題ありませんが、ステートレス CI ランナーの最初のコマンドに 5 〜 10 秒の待機時間が追加されます。

使用するツールは、別の手順として事前にインストールします。

uip tools install @uipath/orchestrator-tool @uipath/solution-tool

Test Manager の実行時に、@uipath/agent-tool Agents をデプロイするとき、@uipath/resource-toolソリューションの外部でアセット/キュー/バケットを管理するときに、@uipath/test-manager-toolを追加します。完全なリストについては、 ツールのリファレンス をご覧ください。

ツールがすでにインストールされている場合は自動インストールは不要であるため、インストール前の手順が必要な唯一の動作変更であり、パイプライン内の他のものはそれについて知る必要はありません。

注:

CI=true では自動インストールは無効化 されません 。env-var スイッチはありません。プレインストールがこれを回避する唯一の方法です。「 UiPath CLI をインストールする — ツールの自動インストールを制御する」をご覧ください。

npm グローバル ディレクトリをキャッシュします

すべてのジョブに @uipath/cli を再インストールする CI ランナーは、ダウンロードと解凍に 20 秒から 40 秒を浪費します。npm グローバル node_modules ディレクトリをキャッシュすると、キャッシュ ヒット (通常は 1 秒未満) になります。

キャッシュするディレクトリは、 npm root -g によって報告されたディレクトリです (通常、Linux/macOS では ~/.npm-global/lib/node_modules 、Windows では %APPDATA%\npm\node_modules )。ピン留めしたCLIバージョンのキャッシュをキーにして、バージョンアップによってキャッシュがクリーンに無効になるようにします。

プラットフォーム	キャッシュのメカニズム
GitHub Actions	path: ~/.npm-global/lib/node_modules と key: uip-${{ version }}-${{ runner.os }} を使用してactions/cache
Azure DevOps	Cache@2 バージョン変数をキーとする
Jenkins	ジョブ キャッシャー プラグインまたは手動で管理されるワークスペース フォルダー
GitLab CI	key: uip-$CLI_VERSIONを含む最上位のcache:ブロック

キャッシュがヒットすると、 npm install -g @uipath/cli と uip tools install の両方をスキップできます— uip 実行可能ファイルとそのツールはすでに PATHにあります。小さなバッシュガードはこれをきれいにします:

if ! command -v uip >/dev/null; then
  npm install -g "@uipath/cli@${CLI_VERSION}"
  uip tools install @uipath/orchestrator-tool @uipath/solution-tool
fi

各プラットフォームの具体的なYAML / Groovyは レシピページにあります。

再現性のためのピンバージョン

再現可能なパイプライン はすべてを固定します。次の 4 つのバージョンが重要です。

• Node.js — メジャーをピン留めします (GitHub Actions のsetup-node20.x、Azure DevOps versionSpec: '20.x')。
• @uipath/cli — 範囲ではなく、正確にピン留め(@1.0.0) します。
• ツール — オプション。デフォルトでは、CLIのMAJORを追跡します。マイナーライン;厳密なパッチレベルの再現性が必要な場合にのみピン留めします (@uipath/solution-tool@1.0.2)。
• 独自のソリューションのバージョン — --versionuip solution packに明示的に渡します。CIの 1.0.0 デフォルトに頼らないでください。

# Pin these once at the top of the pipeline; reuse below
CLI_VERSION="1.0.0"
SOLUTION_VERSION="1.2.0-ci.${BUILD_NUMBER}"

npm install -g "@uipath/cli@${CLI_VERSION}"
uip tools install @uipath/solution-tool @uipath/orchestrator-tool

uip solution pack ./my-solution ./dist --version "$SOLUTION_VERSION"

.zipパスは決定論的 (./dist/my-solution.${SOLUTION_VERSION}.zip) であるため、下流のステップではuip solution pack JSON 出力を解析せずにパスを構築できます。

ツールピン留めルールの詳細については 、スクリプトパターン — CI でバージョンをピン留めする を参照してください。

最小デプロイ ブロック

すべてのプラットフォームは、次のように要約されます。

set -euo pipefail

# Authenticate
uip login \
  --client-id env.UIPATH_CLIENT_ID \
  --client-secret env.UIPATH_CLIENT_SECRET \
  --tenant "$UIPATH_TENANT"

# Pack
uip solution pack ./my-solution ./dist \
  --name my-solution \
  --version "$SOLUTION_VERSION"

# Publish
uip solution publish "./dist/my-solution.${SOLUTION_VERSION}.zip"

# Deploy
uip solution deploy run \
  --name "my-solution-${ENVIRONMENT}" \
  --package-name my-solution \
  --package-version "$SOLUTION_VERSION" \
  --folder-name MySolution \
  --folder-path Shared

set -euo pipefail 、スクリプトが高速に失敗します: -e はゼロ以外の終了時に中止 -u 、未定義の変数をキャッチ -o pipefail 、パイプを介して失敗を伝播します。これは、このドキュメントのすべてのレシピが使用するパターンです。スクリプトパターン — 厳密なシェルオプション を参照してください。

任意: デプロイ後にテストを実行する

ソリューションにテスト セットが含まれている場合は、起動→→検証を待ってから、パイプラインを緑色にマークします。3ステップのパターンが重要です:uip tm testsets runは、テストに合格したときではなく、実行がキューに入れられるとすぐに0終了するため、ブロックするuip tm wait、判定を読むuip tm report getが必要です。

「 方法: CLI からテストを実行する 」で、エラー処理を含む完全なパターンを確認してください。

パイプライン中の再認証の処理

アクセス トークンは、長期実行パイプライン中に期限切れになることがあります。scripting-patterns ページには、終了コード2 (AuthenticationError) の分岐、uip loginの再実行、一度のリトライ、それ以外の場合は失敗という正規のリトライパターンがあります。ほとんどのCIパイプラインでは、これは不要ですが(ジョブは初期ログインのトークンが実行全体にわたって持続するほど短い)、長いテストスイートやマルチテナントのプロモーションループの恩恵を受けることができます。

プラットフォーム レシピ

プラットフォームのネイティブ構文でのコピー&ペースト可能な完全なパイプラインの場合:

• CI/CD レシピ: Azure DevOps
• CI/CD レシピ: GitHub Actions
• CI/CD レシピ: Jenkins
• CI/CDレシピ:GitLab CI

各レシピには、完全なパイプライン (インストール→ 認証 → パック→パブリッシュ→デプロイ→テスト)、シークレット ワイヤリング、キャッシュ エントリ、およびバージョンのピン留めとテストの実行のバリエーションが表示されます。

参照

• 最初のパイプライン — 最小限の 3 つのコマンド フロー。
• 方法: ソリューションをパッケージ化してパブリッシュする — バージョン管理の規範、複数環境の昇格、ロールバック。
• 認証 — 3 つのフローと、それぞれをいつ使用するか。
• スクリプティングパターン — 終了コード、リトライ、JSONフィルタリング。
• UiPath CLI のインストール — CI/CD — プレインストールとキャッシュの詳細