Skip to content

[enhancement]: Enable Injection of Secret Environment Variables into VSTest Task in Classic Release Pipelines #20811

Open
@mikejohnstonPremierinc

Description

Task name

VsTest

Describe your feature request here

Description

In Classic release pipelines, variables can be linked via variable groups and accessed within the VSTestV2 task. These variables are accessed when the Classic release pipeline is linked to Azure automated Test Plans via Azure Test Plan Association. To access them, one adds Environment.GetEnvironmentVariable to his C# automation code, then runs a Test Plan on Azure via automation Test Plan Association.

Problem

If these variables are marked as secret, they are not injected into the environment during task execution, unless they are explicitly defined within the VSTestV2 task.

YAML-based pipelines allow a user to explicitly define secret variables by adding the env input to the VSTestV2 YAML.

YAML from Classic release pipelines is read-only. You can only modify the settings of VSTestV2 using the pre-built fields of the task's UI. This UI currently does not have an environment variables field.

As a result, secret variables are unable to be passed into VSTestV2 using the Classic release pipelines. Attempts to access them using Environment.GetEnvironmentVariable in C# return null.

This discrepancy limits secure configuration management and reduces task flexibility when sensitive information is required for tests.

Proposed Solution

Update the VSTestV2 task to be able to securely inject secret variables defined in linked variable groups into the task environment. Most likely, by adding the field Environment Variables to the settings UI.

Ensure these variables are available to the process without logging or exposing them in task outputs. Maintain secure handling in line with existing Azure DevOps secret management practices.

Alternatives

Write custom scripts to manually inject secrets, which is not secure and contradicts best practices.

Convert Classic release pipelines to YAML-based pipelines. But Classic release pipelines are not compatible with Test Plan Associations, so this is not a valid alternative.

Benefits

Parity between Classic release pipelines and YAML pipelines.

Enhanced security and flexibility for testing configurations requiring sensitive information.

Improved usability for teams managing secure variable groups in Classic pipelines.

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions