1
votes

I have a release pipeline in Azure DevOps with one stage. The stage contains a task "Kubectl" to login to an AKS cluster. It expects a service connection as a parameter. My problem is that I get the service connection from the previous task which reads the value from "App Configuration". The value I get from App Configuration is set as an environment variable that I then pass on this way echo "##vso[task.setvariable variable=SC]$AKS_SERVICECONNECTION". So the variable is SC, and I set the service connection in "Kubectl"-login with $(SC). $AKS_SERVICECONNECTION has the correct value, I printed it out to check.

This doesn't work. The value is not set even though the environment variable SC has now the correct value. So, I tested it with the namespace parameter, and that works, just not with service connection. My question and assumption is that a service connection has to be set at execution-time, and can not be set in a previous task that a following task will use?

1
The SC it's the service name or id?Shayki Abramczyk
$(SC) is the name of the variable I set in the field for service connection. That means that I have assigned a variable SC to it in a Bash task after App Configuration task with the name of the service connection and before kubectl-login task which uses $(SC).Sven Malvik
This I understood, but what the value of this variable? the service connection name or the service connection id?Shayki Abramczyk
Ah sorry, the value is the name of the service connectionSven Malvik
If you can, try to put the idShayki Abramczyk

1 Answers

1
votes

It seems that the service connection for Kubectl task is retrieved at compile time before the task being executed. I created a testing variable on the release pipeline Variables section, and i changed the testing variable value in a script task using echo "##vso[task.setvariable... I saw in the task log that the original value for the testing variable was always picked.

See this similar issue here.

However, you can use the rest api as workaround. See below steps:

1, Add a second stage in your release pipeline. Select the trigger as Manual Only. Move the Kubectl task and related tasks in the second stage(ie. Kubetcl stage in below screenshot) enter image description here

2, Define a variable ServiceCon in the Variables section. Select the variable Scope to the Second stage(ie.Kubetcl). Check Settable at release time

enter image description here

3, Add a script task to call update release environment rest api in the first stage (ie. SetServiceCon stage). See below inline powershell script: The variable SC is assigned the service connection name in the previous task.

$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"

Above script will trigger the second stage (ie. kubetcl stage) with the updated service connection name

4, In order the token $(System.AccessToken) can be accessed in above step, you need to go to the edit page of first stage and check the option Allow scripts to access the OAuth token See below screenshot.

enter image description here

5, You also need to allow the Manage deployments and edit release stage permission for the build service account. See below screenshot.

In your release pipeline edit page. Click the 3 dots on the top right corner. And select Security.

enter image description here

Allow the Manage deployments and edit release stage permission for the (ProjectName)build service (OrgName) account.

enter image description here

After complete above steps, and when your release pieline is triggerred, the first stage will be executed first and the script task will call the update release environment rest api. Then the second stage will be triggered with the updated service connection name