Support complex input types

[qetza]

Hi,

Currently those functions only support normal variables getting their value through environment variable. It would be great that they also support secret variables like Get-TaskVariable in Microsoft.TeamFoundation.DistributedTask.Task.Internal.

Thanks

[ericsciple]

My understanding is that secret variables should be passed into tasks via inputs. If that's not sufficient, can you provide more details about your scenario?

[qetza]

Hi,
A simple example is for tasks like those:

• https://github.com/qetza/vsts-replacetokens-task/
• https://github.com/colindembovsky/cols-agent-tasks/tree/master/Tasks/ReplaceTokens

Those tasks help replace tokens with variable values, if we had to ask the users to supply secret variables as parameters it would be unusable.

[jessehouwing]

We also use pre-defined variable names and variables with a specific prefix in a number of our internal tasks. We simply query all available build variables, iterate through them and act on them based on their name.

We currently use the script I blogged about here:
http://blog.jessehouwing.nl/2016/03/access-all-available-build-variables.html

This includes the use of Secret variables. We use convention over configuration to make the setup of builds much easier.

[pascalnaber]

Because we need to configure an n-amount of variables for deployment to Azure, we use a naming convention for variables. We can't know on forehand what and how many variables we should use, its dynamic. When iterating over all variables and checking the names based on the naming convention, we are now able to use variables from VSTS to deploy dynamic to Azure.
Because there is sensitive information in the value of the variables they need to be a secret.
So we really need to read secret variables and also iterate over all variables.

[chrispat]

We are considering adding a checkbox so there is an explicit option for the user to grant access to their secrets to a task. Ideally the reflection hack that Jesse put together would not work but that was an artifact of the custom PowerShell host that we are trying to move away from.

[qetza]

Hi Chris,
Having a opt-in option would be an good workaround.
Also it would be good to have an easy access to the list of variables as Jesse has done. Maybe something like OctopusDeploy where you have an OctopusParameters hashtable filled with all relevant values.

[jessehouwing]

@chrisrpatterson it's only a reflection hack because calling a generic method from powershell isn't easy. The API is otherwise public API and would look quite clean if I had written it in C# instead. So ideally it would look cleaner, but API wise it is supposed to work from a API consumer perspective.

[jessehouwing]

@chrisrpatterson I'd love this to be part of a permission system. As a sysadmin I would want to review these types of tasks with more rigor than tasks that do not have access to secrets.

[bryanmacfarlane]

@qetza

OctopusParameters hashtable filled with all relevant values

We had an dictionary input for tasks - we could do that.

The anti-pattern we are trying to avoid is folks publishing tasks where when you drag them on, you also have to know what secret variables to set. It makes the system fall apart - even though it's fine for your custom tasks.

By adding a check box, we are encouraging the fragile pattern.

The problem seems to be a collection of data points that feed into a task - not one to one. A dictionary input type on the tasks would solve that. It's the better equivalent of start your variables with MY_PREFIX which is essentially addressing the same problem - scoping a variable set of data for a task to use. Tasks should use inputs.

[jessehouwing]

If at the same time you fix the recursive expansion of variables, I'll return my tasks :)

[bryanmacfarlane]

Deal
microsoft/azure-pipelines-agent@a16213a

[jessehouwing]

@bryanmacfarlane I've been looking for the ability to provide lists and dictionaries in a couple of my tasks. Being able to supply the dictionary keys from a datasource would be a lovely addition. One of my tasks shows a textbox to enter key-value pairs for Check-in Notes. At the moment I've resorted to having my users enter Json.

[ericsciple]

Updating the title since getting secret variables was added to task lib (and agent too since it has to pass to the task).

The remaining discussion is about more complex input types.

[gigeld]

If the secret value has an '&' character inside, the task will fail. We've tried using this format:
key:'$(secret)'
but no luck :(

[github-actions]

This issue has had no activity in 90 days. Please comment if it is not actually stale