New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support complex input types #48

Open
qetza opened this Issue Mar 4, 2016 · 14 comments

Comments

Projects
None yet
7 participants
@qetza

qetza commented Mar 4, 2016

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

This comment has been minimized.

Show comment
Hide comment
@ericsciple

ericsciple Mar 6, 2016

Member

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?

Member

ericsciple commented Mar 6, 2016

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

This comment has been minimized.

Show comment
Hide comment
@qetza

qetza Mar 6, 2016

Hi,
A simple example is for tasks like those:

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.

qetza commented Mar 6, 2016

Hi,
A simple example is for tasks like those:

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

This comment has been minimized.

Show comment
Hide comment
@jessehouwing

jessehouwing Mar 12, 2016

Contributor

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.

Contributor

jessehouwing commented Mar 12, 2016

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

This comment has been minimized.

Show comment
Hide comment
@pascalnaber

pascalnaber Mar 21, 2016

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.

pascalnaber commented Mar 21, 2016

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.

@chrisrpatterson

This comment has been minimized.

Show comment
Hide comment
@chrisrpatterson

chrisrpatterson Mar 21, 2016

Member

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.

Member

chrisrpatterson commented Mar 21, 2016

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

This comment has been minimized.

Show comment
Hide comment
@qetza

qetza Mar 22, 2016

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.

qetza commented Mar 22, 2016

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

This comment has been minimized.

Show comment
Hide comment
@jessehouwing

jessehouwing Mar 22, 2016

Contributor

@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.

Contributor

jessehouwing commented Mar 22, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@jessehouwing

jessehouwing Mar 22, 2016

Contributor

@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.

Contributor

jessehouwing commented Mar 22, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@bryanmacfarlane

bryanmacfarlane Mar 22, 2016

Member

@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.

Member

bryanmacfarlane commented Mar 22, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@jessehouwing

jessehouwing Mar 22, 2016

Contributor
Contributor

jessehouwing commented Mar 22, 2016

@bryanmacfarlane

This comment has been minimized.

Show comment
Hide comment
Member

bryanmacfarlane commented Mar 22, 2016

@jessehouwing

This comment has been minimized.

Show comment
Hide comment
@jessehouwing

jessehouwing Apr 4, 2016

Contributor

@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.

Contributor

jessehouwing commented Apr 4, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@ericsciple

ericsciple Feb 5, 2017

Member

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.

Member

ericsciple commented Feb 5, 2017

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.

@ericsciple ericsciple changed the title from getVariable and Get-VstsTaskVariable doesn't support secret variables to Support complex input types Feb 5, 2017

@gigeld

This comment has been minimized.

Show comment
Hide comment
@gigeld

gigeld Oct 5, 2017

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

gigeld commented Oct 5, 2017

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment