Azure DevOps推送Flowable镜像到ACR报client id must be guid错误

报错核心由两个问题共同导致：

• AzureCLI@2任务存在执行上下文隔离机制：任务运行时会使用独立的临时Azure配置目录，脚本执行完成后默认自动执行az account clear清除所有登录态，你在该任务内执行az acr login生成的容器注册表凭证仅在当前任务生命周期内有效，后续运行Maven构建的步骤完全读不到合法的ACR认证信息。
• Jib插件读取到格式非法的凭证：你当前使用的jib-maven-plugin 2.6.0版本对Azure ACR的AAD认证兼容存在缺陷，读取到残留的非GUID格式客户端ID时，就会抛出client id must be guid的401未授权错误。

• 对比不同步骤的Docker配置内容：在AzureCLI任务的inlineScript末尾加cat ~/.docker/config.json，同时在后续修改pom文件的脚本开头也加同样的命令，对比输出即可发现，AzureCLI任务内生成的ACR认证信息不会保留到后续步骤。
• 校验服务主体格式：检查Azure DevOps服务关联的服务主体客户端ID是否为标准GUID格式，避免误将服务主体显示名、ACR名称等非GUID值填入认证配置。
• 验证Jib凭证读取逻辑：Jib默认不会主动继承Azure CLI的临时登录态，仅会读取固定路径下的Docker配置文件、或显式传入的认证参数，隐式依赖前序步骤的临时登录态本身就存在不稳定问题。

按优先级从高到低选择即可：

方案1：显式传递认证参数给Jib（最稳定） #

抛弃依赖隐式读取Docker配置的逻辑，直接在Maven构建命令中传入合法的ACR认证信息，同时调整AzureCLI任务配置避免登录态被提前清除：

1. 修改AzureCLI@2任务配置，使用bash脚本（Linux代理下比PowerShell Core兼容性更好），开启服务主体环境变量注入：

- task: AzureCLI@2
  inputs:
    azureSubscription: '你的Azure服务连接名称'
    scriptType: 'bash'
    scriptLocation: 'inlineScript'
    inlineScript: |
      az config set core.clear_logs_on_exit=false
      az acr login -n 你的ACR实例名
    addSpnToEnvironment: true

2. 修改Maven构建命令，显式传入Jib推送镜像需要的认证参数：

- script: |
    mvn -Pdistro clean install -DskipTests
    cd modules/flowable-app-rest
    mvn -Pdocker,swagger,dockerPublish -DskipTests \
      -Dimage=你的ACR实例名.azurecr.io/flowable-app-rest \
      -Djib.to.tags=$(Build.BuildId) \
      -Djib.to.auth.username=00000000-0000-0000-0000-000000000000 \
      -Djib.to.auth.password=$(az acr login -n 你的ACR实例名 --expose-token --query accessToken -o tsv) \
      clean package
    cd ../flowable-ui
    mvn -Pdocker,dockerPublish -DskipTests \
      -Dimage=你的ACR实例名.azurecr.io/flowable-ui \
      -Djib.to.tags=$(Build.BuildId) \
      -Djib.to.auth.username=00000000-0000-0000-0000-000000000000 \
      -Djib.to.auth.password=$(az acr login -n 你的ACR实例名 --expose-token --query accessToken -o tsv) \
      clean package
  displayName: 'Launch Build All Images'

注意：使用AAD服务主体认证ACR时，用户名为固定值00000000-0000-0000-0000-000000000000，密码为az acr login --expose-token返回的访问令牌，该格式为Azure官方规范，不会触发客户端ID格式错误。

方案2：使用Docker登录任务持久化凭证 #

删除原有安装ACR Helper、AzureCLI执行ACR登录的步骤，直接使用Azure DevOps内置的Docker任务完成ACR登录，该任务生成的凭证会持久化到全局Docker配置路径，后续Jib可直接读取：

- task: Docker@2
  inputs:
    containerRegistry: '你的ACR对应的Docker Registry类型服务连接'
    command: 'login'

原有Maven构建步骤无需修改即可正常推送镜像。

方案3：升级Jib插件版本 #

将pom.xml中jib-maven-plugin的版本从2.6.0升级到3.3.0及以上稳定版本，修复旧版本对Azure ACR AAD凭证的格式识别bug，配合正确的持久化登录态即可解决问题。

内容的提问来源于stack exchange，提问作者erbg