В конвейерах Azure DevOps использование переменных в задаче powershell приводит к ошибке ArgumentParseError при выполнении входа в систему az

#azure #powershell #azure-devops #azure-pipelines #azure-service-principal

#azure #powershell #azure-devops #azure-конвейеры #azure-service-principal

Вопрос:

У меня есть задача Powershell как таковая в моем конвейере:

 - task: PowerShell@2
  inputs:
    targetType: 'inline'
    script: |
      az login --service-principal --username $env:servicePrincipalId --password $env:servicePrincipalKey --tenant $env:tenantId
      python $(Build.SourcesDirectory)/the/path/to/my/python/script.py
  displayName: 'Execute Python code'
 

Сведения о принципале службы предоставляются мне путем addSpnToEnvironment: true выполнения задачи AzureCLI перед этой задачей Powershell.

Когда выполняется задача Powershell, я получаю ArgumentParseError: argument --username/-u: expected one argument . Как я могу это решить?

Комментарии:

1. разве вы не должны использовать $env: вместо $env. ?

2. Извините, только что понял, что я действительно использую $env: в моем реальном конвейере. Введите его как $env. здесь случайно. Отредактировал мой вопрос, чтобы отразить это.

3. Что я нахожу действительно полезным при устранении этих ошибок, так это разбросать несколько из следующих задач по конвейеру (поскольку переменные ограничены, поэтому могут существовать не во всех ваших задачах — в зависимости от того, как вы используете этапы, задания и т. Д.) — pwsh: «Get-ChildItem env:» DisplayName: «ОтображатьПеременные»

Ответ №1:

Проверьте, начинается ли значение пароля с символа « - .

Это известная проблема, вызванная начальным символом « - , который заставляет анализатор аргументов путать его с именем параметра. Смотрите здесь .

В качестве обходного пути вы можете решить проблему, добавив « = между именем параметра и значением.

 az login --service-principal --username=$env:servicePrincipalId --password=$env:servicePrincipalKey --tenant=$env:tenantId
 

Кроме того, вы также можете попробовать следующие способы:

Комментарии:

1. Поэтому я попытался использовать это предложение с предложением @Krzysztof Madej об использовании Azure PowerShell. Это действительно заводит меня дальше, но теперь я получаю следующую ошибку: ##[error]Failed to resolve tenant '' .

2. Когда вы создавали подключение к службе диспетчера ресурсов Azure , пытались ли вы использовать Service principal (manual) метод «»? Этот метод может позволить вам указать Клиента и участника службы. Убедитесь , что вы правильно заполнили Service Principal Id , Service principal key и Tenant ID .

Ответ №2:

Я бы рекомендовал вам использовать задачу Azure PowerShell, которая:

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

 # Azure PowerShell
# Run a PowerShell script within an Azure environment
- task: AzurePowerShell@4
  inputs:
    #azureSubscription: Required. Name of Azure Resource Manager service connection
    #scriptType: 'FilePath' # Optional. Options: filePath, inlineScript
    #scriptPath: # Optional
    #inline: '# You can write your Azure PowerShell scripts inline here. # You can also pass predefined and custom variables to this script using arguments' # Optional
    #scriptArguments: # Optional
    #errorActionPreference: 'stop' # Optional. Options: stop, continue, silentlyContinue
    #failOnStandardError: false # Optional
    #azurePowerShellVersion: 'OtherVersion' # Required. Options: latestVersion, otherVersion
    #preferredAzurePowerShellVersion: # Required when azurePowerShellVersion == OtherVersion