test-scenario-env

CoreCLR Test Scenario Environment

Generate a dotenv file consumable by:

corerun[.exe] -e <path-to-env> <managed-test.dll>

Use src/tests/Common/testenvironment.proj as the source of truth. Do not manually duplicate its scenario table or defaults in the skill.

Inputs

Required:

A scenario name from a TestEnvironment item in src/tests/Common/testenvironment.proj

Optional:

A test .csproj under src/tests/; when supplied, merge its effective CLRTestEnvironmentVariable items and the applicable CLRTestBatchEnvironmentVariable or CLRTestBashEnvironmentVariable items
Target OS, architecture, configuration, and runtime flavor
Output path; default to artifacts/tmp/test-scenario-env/<canonical-scenario>.env

Default the target OS to the current host, architecture to x64, configuration to Release, and runtime flavor to coreclr. Use the repro directory's .env path when invoked by standalone-test-repro.

Workflow

1. Resolve the Scenario

Read src/tests/Common/testenvironment.proj and match the requested name against TestEnvironment item identities. Use the canonical identity from the project in output and reporting.

If there is no exact scenario match, use ask_user with the closest concrete scenario names. Do not silently emit an empty environment. If target-dependent duplicates exist, select them by target OS using the project's conditions.

Reject scenarios outside managed desktop CoreCLR support for this skill.

2. Evaluate with MSBuild

Use the build-and-test skill before running the repository SDK. Invoke the repository's bootstrapped dotnet to run the CreateTestEnvFile target rather than interpreting scenario metadata manually.

Generate a temporary script under the same resolved output directory. Choose the repository SDK entry point from the host OS, independently of the target OS. Choose the temporary script extension and TargetsWindows value from the target OS.

Windows host:

.\dotnet.cmd msbuild src\tests\Common\testenvironment.proj /t:CreateTestEnvFile /p:Scenario=<scenario> "/p:TestEnvFileName=<resolved-output>\<temporary.cmd-or-sh>" /p:TargetsWindows=<true-or-false> /p:RuntimeVariant=<variant>

Non-Windows host:

./dotnet.sh msbuild src/tests/Common/testenvironment.proj /t:CreateTestEnvFile /p:Scenario=<scenario> "/p:TestEnvFileName=<resolved-output>/<temporary.cmd-or-sh>" /p:TargetsWindows=<true-or-false> /p:RuntimeVariant=<variant>

Use a .cmd temporary file and TargetsWindows=true for a Windows target; use a .sh file and TargetsWindows=false otherwise. This remains true for cross builds. Omit RuntimeVariant when none was requested. Keep the generated value for random scenarios such as jitstress_random_1; do not replace it with the literal random.

3. Convert Scenario Output to Dotenv

Parse only assignments generated by testenvironment.proj:

Windows: set NAME=VALUE
Non-Windows: export NAME=VALUE

Ignore the shell shebang and other non-assignment lines. Encode an empty value as NAME=''; a bare NAME= before another entry is not safe because CoreRun's parser skips the following newline while looking for a value. Collapse duplicate names using the last generated value.

Convert assignment values from the target shell's syntax to CoreRun dotenv syntax; do not copy the shell text verbatim:

Use the value written to the generated script. MSBuild decodes escaped item metadata before writing it, so %2A in testenvironment.proj is emitted as the literal wildcard *.
For non-Windows scripts, convert shell variable references such as $NAME or ${NAME} to CoreRun's supported ${NAME} form. Do not expand them from the ambient environment while generating the file. For example, convert $HELIX_DUMP_FOLDER/coredump.%d.dmp to ${HELIX_DUMP_FOLDER}/coredump.%d.dmp.
Preserve non-expansion format tokens such as %d. To protect a literal $, single-quote the entire dotenv value so CoreRun does not interpret it as substitution; inside a single-quoted value, escape \ as \\ and ' as \'.

Write portable dotenv entries as NAME=VALUE, one per line. Quote or escape whitespace, #, quotes, backslashes, newlines, and variable-expansion syntax according to src/coreclr/hosts/corerun/dotenv.cpp. Never leave an unbraced $NAME reference in the generated .env.

Delete only the specifically resolved temporary script after conversion.

4. Merge Test-Project Variables

When a test .csproj was supplied, evaluate its effective common CLRTestEnvironmentVariable items and the selected target's CLRTestBatchEnvironmentVariable or CLRTestBashEnvironmentVariable items for the chosen OS, architecture, configuration, and runtime flavor, including applicable imports and conditions.

Merge in runtime-wrapper order:

Scenario variables from testenvironment.proj
CLRTestBatchEnvironmentVariable items for a Windows target, or CLRTestBashEnvironmentVariable items for a non-Windows target
Common test-project CLRTestEnvironmentVariable items

Later values replace earlier values with the same name, including replacing them with an empty value. This matches runtime wrapper behavior, which sources __TestEnv, applies target-specific environment items, and then applies common CLRTestEnvironmentVariable items.

Do not include the ambient process environment, CI credentials, or unrelated MSBuild properties. Do not leave unevaluated expressions such as $(SomeProperty) in the file.

5. Validate

Before completing:

Confirm the scenario exists for the selected target.
Compare scenario entries with the temporary script after applying the documented shell-to-dotenv normalization, before deleting it.
If a project was supplied, compare merged entries with its effective target-specific and common environment items and verify wrapper-order precedence.
Confirm corerun -e <env-file> can parse the generated file when a matching Core_Root is available.
Confirm the output is under artifacts/tmp unless the user explicitly chose another safe path.

Final Response

Report the canonical scenario, output .env path, target OS and architecture, and variable names. If a project was merged, report its path and any names whose scenario values were overridden. Do not unnecessarily print sensitive values.