Блог

У меня есть конвейер выпуска в Azure DevOps с одним этапом. Этап содержит задачу «Kubectl» для входа в кластер AKS. В качестве параметра ожидается подключение к службе. Моя проблема в том, что я получаю подключение к службе из предыдущей задачи, которая считывает значение из «Конфигурации приложения». Значение, которое я получаю из конфигурации приложения, задается как переменная среды, которую я затем передаю таким образом echo "##vso[task.setvariable variable=SC]$AKS_SERVICECONNECTION" . Итак, переменная есть SC , и я установил подключение к службе в «Kubectl»-войдите с помощью $(SC) . $AKS_SERVICECONNECTION имеет правильное значение, я распечатал его для проверки.

Это не работает. Значение не установлено, хотя переменная среды SC теперь имеет правильное значение. Итак, я протестировал это с параметром пространства имен, и это работает, но не с подключением к службе. Мой вопрос и предположение заключается в том, что подключение к службе должно быть установлено во время выполнения и не может быть установлено в предыдущей задаче, которую будет использовать следующая задача?

Похоже, что подключение к службе для задачи Kubectl извлекается во время компиляции перед выполнением задачи. Я создал переменную тестирования в разделе Переменные конвейера выпуска и изменил значение переменной тестирования в задаче сценария с помощью echo "##vso[task.setvariable.. . Я видел в журнале задач, что исходное значение для переменной тестирования всегда выбиралось.

Смотрите эту аналогичную проблему здесь.

Однако вы можете использовать rest api в качестве обходного пути. Смотрите следующие шаги:

1. Добавьте второй этап в свой конвейер выпуска. Выберите триггер как Manual Only . Переместите задачу Kubectl и связанные с ней задачи на второй этап (т.е. Kubetcl этап на скриншоте ниже)

2. Определите переменную ServiceCon в Variables разделе. Выберите переменную Scope для второго этапа (т.Е. Kubetcl ). Проверьте Settable at release time

3. Добавьте задачу сценария для вызова обновления api среды выпуска rest на первом этапе (т.Е. SetServiceCon этап). Смотрите ниже встроенный сценарий powershell: Переменной SC присвоено имя подключения к службе в предыдущей задаче.

 $url = "https://vsrm.dev.azure.com/Org/Project/_apis/Release/releases/$(Release.ReleaseId)/environments/$($(Release.EnvironmentId) 1)?api-version=6.1-preview.7"

#override the variable ServiceCon by referencing to variable $(SC) from your previous task
$body = @{
  status= "inProgress";
  variables= @{ ServiceCon= @{value= $(SC)}}
}

Invoke-RestMethod -Uri $url -Headers @{Authorization = "Bearer $(System.AccessToken)"} -Method patch -Body (ConvertTo-Json $body) -ContentType "application/json"
  

Приведенный выше сценарий запустит второй этап (т. Е. этап kubetcl) с обновленным именем подключения к службе

4. Чтобы получить доступ к токену $(System.AccessToken) на предыдущем шаге, вам необходимо перейти на страницу редактирования первого этапа и установить флажок Allow scripts to access the OAuth token , см. Скриншот ниже.

5, Вам также необходимо allow разрешение Manage deployments и edit release stage для учетной записи службы сборки. Смотрите скриншот ниже.

На странице редактирования конвейера выпуска. Щелкните 3 точки в правом верхнем углу. И выберите Security .

Allow Manage deployments и edit release stage разрешение для (ProjectName)build service (OrgName) учетной записи.

После выполнения вышеуказанных шагов и при запуске вашей линии выпуска сначала будет выполнен первый этап, и задача сценария вызовет rest API среды выпуска обновлений. Затем будет запущен второй этап с обновленным именем подключения к службе