【问题标题】：How to add secret variable as task environment variable in VSTS如何在 VSTS 中添加秘密变量作为任务环境变量
【发布时间】：2017-05-18 02:15:36
【问题描述】：

This documentation 声明秘密变量是

未解密为环境变量。因此，默认情况下不会授予由构建步骤运行的脚本和程序的访问权限。

我的一个构建任务要求设置一个存储在秘密变量中的环境变量。这是否意味着不可能在 VSTS 中使用秘密变量来做到这一点？如果没有，我该怎么做？

为了进一步了解背景，我正在尝试使用 electron-builder 对我的电子应用程序进行代码签名。 It requires 设置两个环境变量：CSC_LINK 和 CSC_KEY_PASSWORD。其中之一是代码签名证书的密码，因此需要保持安全。

【问题讨论】：

【解决方案1】：

设置环境变量

使用命令行任务，如下所示：

target_environment_variable 现在包含 secret_variable 的值。

验证

添加一个后续命令行任务，将所有环境变量写入磁盘文件，如下所示：（注意：在参数文本框中，写入您和构建代理都可以访问的文件夹 ):

将构建定义排队，然后查看包含环境变量的文件：

【讨论】：

如果环境变量名称与秘密变量名称相同，这应该工作吗？因此，在上面的示例中，如果您将“TARGET_ENVIRONMENT_VARIABLE”更改为“secret_variable”，它对您有用吗？我发现如果我尝试设置一个与秘密变量同名的环境变量，该变量实际上并没有设置。
@briandunnington，我没有尝试过这种变化，也无法在 ATM 上尝试。但是，我对您描述的行为并不感到惊讶——管道处理代码可能会检查这种特定情况并阻止它。如果这按您希望的那样工作，引用变量名的下游步骤将不知道是环境变量还是秘密变量。（当然，在您调用“task.setvariable”之后它们将具有相同的值，但没有什么可以阻止在后面的步骤中单独修改它们中的任何一个。）
管道的未来（人类）维护者也会受到歧义的影响。
我研究了 KeyVault 任务源代码并确认了这种行为。源代码中的确切引用说“曾经是秘密，永远是秘密”，它特别不允许将秘密管道变量设置为环境变量。我刚刚写了几行 Powershell 来实现我所需要的，但很高兴知道根本原因。

【解决方案2】：

您可以在构建定义的“变量”页面中提供要传递给任务的变量：

然后可以将它们作为输入传递给任务，如下所示：

【讨论】：

这并没有回答如何将秘密变量的值放入 Environment 变量的原始问题。这个答案实际上只是描述了在 VSTS 任务参数中引用任何变量（无论是否秘密）的标准方法。

【解决方案3】：

当使用 YAML 语法时，这也可以实现：

steps:
- script: |
    echo %MYSECRET%
  env:
    MySecret: $(Secret_Variable)

【讨论】：