Развертывание Azure DevOps SQL DacPac не работает с подключением службы

Так как имя сервисного подключения правильное и настроено на основе переменных в группах переменных

TL;DR Имена подключений служб не могут храниться в группах переменных. Вместо этого объявите их как переменные в своем конвейере или шаблоне YAML.

Кроме того, не забудьте вручную поставить в очередь хотя бы одну сборку, чтобы авторизовать любые подключения к службам.

Подробнее

Переменные в группах переменных доступны во время выполнения, поэтому они доступны только после запуска конвейера.

Учитывая, что подключение к сервису — это защищенный ресурс , который необходимо авторизовать до запуска конвейера (т.е. во время компиляции), мы не можем использовать переменные из групп переменных. Можно использовать только значения, доступные во время компиляции.

Пример

/pipelines/variables/dev-variables.yaml

variables:
  - name: azureSubscription
    value: dev-service-connection

  # other dev variables here

/pipelines/variables/qa-variables.yaml

variables:
  - name: azureSubscription
    value: qa-service-connection

  # other qa variables here

/pipelines/variables/prod-variables.yaml

variables:
  - name: azureSubscription
    value: prod-service-connection

  # other prod variables here

мой-pipeline.yaml

jobs:
  - deployment: deployment_job_${{ parameters.env }}
    displayName: Deployment Job ${{ parameters.env }}
    environment: Deploy to ${{ parameters.env }}
    variables:
      - template: /pipelines/variables/${{ parameters.env }}-variables.yaml # <------- reference variables template here
    strategy:
      runOnce:
        deploy:
          steps:
            - checkout: self
              displayName: 1. Retrieve repository

            - task: SqlAzureDacpacDeployment@1
              displayName: 2. Deploy DACPAC
              inputs:
                azureSubscription: ${{ variables.azureSubscription }} # <------- from variables template referenced above
                # other inputs...

возникла проблема с авторизацией ресурса: «Конвейер недействителен. Задание Deployment_job_prod: Шаг ввода azureSubscription ссылается на соединение службы DEVOPS_mdwh_connection_prod, которое не удалось найти.

В сообщении об ошибке отображается имя подключения службы: DEVOPS_mdwh_connection_prod. Это означает, что параметры передали правильное значение в поле azureSubscription. Параметры в файле YAML должны быть правильными.

Причина проблемы может заключаться в том, что само подключение к службе недействительно.

В этом случае будет показана та же ошибка.

Например:

Когда вы используете подключение к службе типа федерации удостоверений рабочей нагрузки, при редактировании подключения к службе не предусмотрена опция проверки.

Вы можете использовать следующие шаги, чтобы проверить, действительно ли подключение к службе типа федерации удостоверений рабочей нагрузки.

Шаг 1. Вручную выполните поиск задачи sql в редакторе пользовательского интерфейса YAML.

Шаг 2. Вы можете выбрать задачу sql и проверить, видите ли вы соединение службы DEVOPS_mdwh_connection_prod в раскрывающемся списке подключений службы.

Если вы не видите подключение службы в раскрывающемся списке, это означает, что само подключение службы недействительно.

Чтобы решить эту проблему, вы можете перейти в «Настройки проекта» -> «Соединения служб» и автоматически создать новое соединение службы ARM типа федерации удостоверений рабочей нагрузки в пользовательском интерфейсе Azure DevOps и проверить, может ли оно работать.

Или вы можете попытаться вручную создать подключение к службе ARM типа федерации удостоверений рабочей нагрузки. Для получения более подробной информации вы можете обратиться к этому документу: Настройте вручную подключение к службе идентификации рабочей нагрузки Azure Resource Manager

Примечание. Поле AuthenticationType в SqlAzureDacpacDeployment@1 используется для управления подключениями к SQL-серверу Azure. Оно не связано с полем azureSubscription и не поддерживает значение WorkloadIdentityFederation. См. этот документ: SqlAzureDacpacDeployment@1 — задача развертывания базы данных SQL Azure v1

Решение было настолько глупым, насколько это возможно. Я оставил пробел перед переменной ServiceConnectionPrefix. Удаление пространства тоже решило проблему... Теперь буду прятаться от стыда десять лет...