14

I have a task group which contains besides other tasks the Azure Key Vault task and the Azure Resource Group Deployment task. In the latter I want to override some parameters in the ARM template with values which come from the key vault.

The Secrets filter field in the Azure Key Vault task looks like secret1,secret2,secret3. These secrets are available as variables in other tasks with the same name like the secret names. So the Override template parameters field within the Azure Resource Group Deployment task has the value -p1 $(secret1) -p2 $(secret2) -p3 $(secret3).

The problem is that VSTS automatically picks the three variables as parameters for the task group. I don't want this to happen. These variables will be set and read out within the task group itself. They are like private fields within a class.

One way would be to remove the Azure Key Vault task and use Build and Release > Library > Variable groups instead. But there is no way to link variable groups to task groups.

Yavuz
  • 550
  • 4
  • 19
  • Even you remove Azure Key Vault task from task group, the secret variables still can be used (if the task is ahead of the task group). And what do you mean **there is no way to link variable groups to task groups**? If you already link variable groups to the build definition, you can also use the variables in task group. – Marina Liu Dec 20 '17 at 08:45
  • Edit a release definition. Go to Variables -> Variable groups. There you can link variable groups and use them. There is no such a way for task groups. However I want to remove the extra parameters secret1, secret2, and secret3 from the task group. Exporting the task group, editing the json (removing unwanted inputs), and importing the task group again is also not working. – Yavuz Dec 20 '17 at 10:52

2 Answers2

6

I think there is no way to remove variables from the parameters of the task group. This has to do with the inner workings of how VSTS processes variables within task groups. The blog post VSTS/TFS: Understanding Task Groups and its various use cases with setvariable logging command gives some insights of how variables within task groups behave. In the same blog post there is a workaround to what I want to achieve.

The task group will have the three additional parameters secret1, secret2, and secret3. When I add the task group to a release definition I have to fill in these values:

  • $(secret1) for the parameter secret1
  • $(secret2) for the parameter secret2
  • $(secret3) for the parameter secret3

To reduce errors and improve experience you can set these values as default values for the parameters in the task group. This way you only have to fill out the remaining required parameters which are needed for the task group.

Ugly, but works.

Yavuz
  • 550
  • 4
  • 19
6

I ran into the same issue. I found that you can remove unnecessary parameters (i.e. parameters supplied by variable groups) by exporting the Task Group to a JSON text file and reimporting.

Just edit the JSON file in notepad++, or your favorite JSON editor, and remove any unnecessary parameters before reimporting. After the import, they are gone.

Also note, that you could probably add new parameters the same way but I haven't tried it.

Chris Gessler
  • 21,162
  • 6
  • 49
  • 79
  • 2
    You have to be a bit careful when editing the resulting Task Group in the UI subsequently. I noticed that just clicking on one of the subtasks is enough to get the UI to introduce the unnecessary parameter again. – MarkHasper Nov 04 '19 at 14:02
  • @MarkHasper is there a way to avoid this behavior? The whole point of the Task Group is to be able to make changes in one place to propagate out to many Pipelines using the Task Group. I can't find a way to make changes to the Task Group without introducing the unwanted Parameters again, forcing my to recreate the Task Group (via json) – David.Jones May 06 '21 at 15:15
  • @David.Jones - I tested it recently and the unwanted parameters still show up. What's worse, is if you add a PowerShell task and add the script in-line, it grabs all of the parameters inside the PowerShell script too. Basically, we avoid this feature all together. What a great concept but a big waste because it can't be used. – Chris Gessler May 07 '21 at 03:00