本文档由 AI 自动翻译。如有任何不准确之处,请参考 英文原版。
在任务中安装 difyctl
使用 安装程序 安装,并始终把 DIFY_VERSION 设为服务器的版本号,这样 Dify 发布新版本后,任务装到的构建版本也不会跟着变。如果安装程序因触及 GitHub 的请求上限而中止,在任务的环境变量中设置 GITHUB_TOKEN 或 GH_TOKEN。
登录
任务无人值守时,由你自己登录,再把令牌交给任务。如果每次都有人能批准验证码,脚本也可自行登录。把令牌交给任务
用 CI 专用的账户获取令牌,或者在一台平时不运行difyctl 的机器上获取。账户需具备编辑及以上角色,才能导入、测试和发布。如果同一账户在那台机器上再次登录,任务的登录就会失效。
登录时加上 --no-keyring,这样就能从文件中复制令牌:
tokens.yml 复制令牌:
DIFY_SERVER:登录时使用的地址。DIFY_TOKEN:令牌,从 Secret 中读取。DIFY_WORKSPACE_ID:工作空间的id,可在difyctl get workspace的结果中查到。
DIFY_CONFIG_DIR 设为一个可写的目录。
然后删除 tokens.yml,让令牌只保存在 CI Secret 中。删除后,你登录所用的那台机器会退出登录,任务则照常运行。如果改为运行 logout,任务的登录也会一并失效。
续期登录
任务中的命令报auth_expired 错误(退出码 4)时,重新登录,再替换 CI Secret 中的令牌。
以下情况会让登录失效:
- 登录到期:默认为 14 天,如果服务器上设置了
OAUTH_TTL_DAYS,则以它设定的天数为准。 - 同一账户在那台机器上再次登录,即使换了配置目录也一样。
difyctl get account session,找到 device_label 为你登录所用机器的那个会话,查看它的 expires_at。
在脚本中登录
用--no-wait 发起登录。和其他 login 一样,它会先退出当前的会话,然后打印验证码,不等批准就结束运行:
verification_uri 和 user_code 发给能在 15 分钟内打开该 URL 并批准验证码的人。完成这次登录之前,不要再发起 login:新的 login 会让这次登录作废,即使对方批准了这次的验证码,你也登录不了。
然后在同一个配置目录中完成登录:
- 验证码获批之前,它会打印
{"status":"pending"}并以 0 退出,因此要检查status,而不是退出码。 - 验证码获批后,它改为打印已登录的
account,不再带有status。 - 如果验证码被拒绝,或在获批前过期,命令会失败并返回退出码 4。这时用
login --no-wait重新开始。
处理失败
每个步骤都用 bash 运行,并设置set -eo pipefail。
以下命令即使遇到任务该停下的情况,也会以 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 工作流会在 Pull Request 改动应用的 DSL 文件apps/order-status.yml 时,对照应用检查该文件;合并到 main 后,再更新并发布应用。每一步的作用详见 更新应用。
使用前,在仓库的 Settings > Secrets and variables > Actions 中添加 Secret DIFY_TOKEN 和变量 DIFY_WORKSPACE_ID。然后把示例值换成你自己的:服务器地址、应用的 ID 和名称(两者都可通过 difyctl get console_app 查到)、文件路径、Dify 版本号和测试输入。
.github/workflows/update-order-status.yml