このドキュメントは AI によって自動翻訳されています。不正確な部分がある場合は、英語版 を参照してください。
ジョブでの difyctl のインストール
インストーラー を使い、DIFY_VERSION には必ずサーバーのバージョンを指定します。こうしておけば、Dify の新しいリリースが出ても、ジョブがインストールするビルドは変わりません。インストーラーが GitHub のレート制限で止まる場合は、ジョブの環境に GITHUB_TOKEN または GH_TOKEN を設定します。
サインイン
無人で実行するジョブには、自分でサインインしてトークンを渡します。コードを毎回承認できる人がいる場合は、スクリプトからサインインすることもできます。ジョブへのトークンの受け渡し
トークンは、CI 専用のアカウントで取得するか、普段difyctl を使わないマシンで取得してください。インポート、テスト、公開を行うには、アカウントにエディター以上のロールが必要です。そのマシンで同じアカウントがもう一度サインインすると、ジョブのサインインは終了します。
トークンをファイルからコピーできるよう、--no-keyring を付けてサインインします：
tokens.yml から、トークンをコピーします：
DIFY_SERVER：サインイン時に指定したアドレスDIFY_TOKEN：シークレットから読み込んだトークンDIFY_WORKSPACE_ID：difyctl get workspaceの一覧に表示される、ワークスペースのid
DIFY_CONFIG_DIR に書き込み可能なフォルダを指定します。
その後、tokens.yml を削除して、トークンが CI のシークレットにだけ残るようにします。削除すると、サインインに使ったマシンはサインアウトした状態になりますが、ジョブはそのまま動き続けます。代わりに logout を実行すると、ジョブのサインインも終了してしまいます。
サインインの更新
ジョブのコマンドがauth_expired（終了コード 4）で失敗するようになったら、サインインし直して、CI のシークレットのトークンを置き換えます。
サインインは、次の場合に使えなくなります：
- 有効期限が切れた場合（既定では 14 日。サーバーで
OAUTH_TTL_DAYSを設定していれば、その日数） - そのマシンで同じアカウントがもう一度サインインした場合（別の設定フォルダでのサインインも含む）
difyctl get account session を実行します。device_label がサインインに使ったマシンになっているセッションの expires_at を確認してください。
スクリプトからのサインイン
--no-wait を付けてサインインを開始します。ほかの login と同様に、まず現在のセッションからサインアウトし、コードを表示して、承認を待たずに終了します：
verification_uri と user_code を、URL を開いて 15 分以内にコードを承認できる人に渡します。サインインを完了するまでは、別の login を開始しないでください。開始するとこのサインインが破棄され、そのコードを承認してもサインインできなくなります。
その後、同じ設定フォルダでサインインを完了します：
- コードが承認されるまでは、
{"status":"pending"}を表示して終了コード 0 で終了します。そのため、終了コードではなくstatusを確認してください。 - コードが承認されると、代わりにサインインした
accountを表示します。statusは含まれません。 - 承認前にコードが拒否されるか期限切れになると、終了コード 4 で失敗します。その場合は
login --no-waitからやり直します。
失敗への対処
各ステップは、set -eo pipefail を有効にした bash で実行します。
次のコマンドは、ジョブを止めるべき場合でも終了コード 0 で終了します。jq -e は条件が偽の場合に失敗するため、各コマンドの出力を次のように jq -e で確認してください：
check console_app dsl（ファイルが無効な場合）：jq -e '.valid'import console_app dsl（インポートが確認待ちのまま保留された場合）：jq -e '.status | startswith("completed")'check console_app dependency（アプリが使う統合がワークスペースにない場合）：jq -e '.leaked_dependencies | length == 0'test console_app workflow（実行が 一時停止したか、途中で打ち切られた 場合）：jq -e '.status == "ended"'check console_app release（ドラフトを公開する準備ができていない場合）：jq -e '.ready'
例：マージ時のアプリの更新
次の GitHub Actions ワークフローは、プルリクエストでアプリの DSL ファイルapps/order-status.yml が変更されると、そのファイルをアプリと照らし合わせて検証します。main にマージされると、アプリを更新して公開します。各ステップの内容については、アプリの更新 を参照してください。
このワークフローを使うには、まずシークレット DIFY_TOKEN と変数 DIFY_WORKSPACE_ID をリポジトリに追加します。追加先は、リポジトリの Settings > Secrets and variables > Actions です。次に、例に示した値を自分の値に置き換えます。置き換えるのは、サーバーのアドレス、アプリの ID と名前、ファイルパス、Dify のバージョン、テストの入力です。アプリの ID と名前は、どちらも difyctl get console_app で確認できます。
.github/workflows/update-order-status.yml