[WIP] Fix missing environment variables in ctest command

[Copilot]

• Review issue details and identify root cause in CTest preset handling
• Update CTest invocation to honor test preset environment via --preset when applicable
• Add/update unit coverage or document manual verification steps
• Update CHANGELOG with user-facing fix entry
• Run relevant lint/tests (or document failures) and summarize verification

Original prompt

---

This section details on the original issue you should resolve

<issue_title>running ctest using test explore with env vars from test presets</issue_title>
<issue_description>### Brief Issue Summary

hello
our test presets have bunch of environment variables (composed by conan due to our dependency graph) which we need in order to launch the tests,
we were expecting to see those vars along the ctest command.
but the command ctest invokes is:

ctest.exe -T test --output-on-failure --build-config Debug -R ^MyProj\.MyTest$

Due to the missing env vars the tests fail when running from the test explorer.
Running ctest —preset ${my-preset} from the terminal pass the env vars to my test executables

CMake Tools Diagnostics

Debug Log

Additional Information

No response</issue_description>

<agent_instructions>You are Copilot coding agent acting as a senior maintainer/contributor for the VS Code extension repository microsoft/vscode-cmake-tools.
You are deeply familiar with CMake, CMake Presets, CTest, kit/toolchain selection, VS Code extension APIs, and the architecture of this repo (TypeScript-heavy).
Your job is to resolve the GitHub issue provided below safely and in a maintainable way, matching existing patterns and UX.

SOURCE OF TRUTH

• Implement the requested change by reading and interpreting this issue (and its comments, linked issues/PRs, logs, and repro projects):
  running ctest using test explore with env vars from test presets #4313 - Bug running ctest using test explore with env vars from test presets #4313
• If the issue lacks repro steps, you must derive minimal repro steps from the information available and document them in the PR.

NON-NEGOTIABLE PROCESS

1. Triage & understanding (issue-first)

• Read the entire issue thread.
• Extract and write down:
  • expected behavior
  • actual behavior
  • repro steps (or minimal repro you infer)
  • affected OS/toolchains/generators/presets
  • whether it is a regression and from which version/commit (if indicated)
• Identify which CMake Tools feature area is involved (configure/build/test/debug, presets, kits, status bar, tasks, command palette, IntelliSense).

2. Orient yourself in the repo (implementation map)

• Identify the relevant user-facing workflows impacted (configure/build/test/debug, presets, kits, status bar, tasks, command palette).
• Locate the existing implementation areas (commands, configuration/presets handling, test integration, UI, telemetry/logging).
• Identify existing tests and how they are run in CI; prefer extending existing suites over inventing a new harness.

3. Changelog discipline (required)

• Find the project’s changelog / release notes mechanism (e.g., CHANGELOG.md, docs/changelog, “Unreleased” section, or a dedicated changes/ folder).
• Add exactly ONE appropriate entry for this change, in the correct section and format used by the repo.
• The entry must describe user-visible behavior (not internal refactors).
• If the change is not user-visible, explicitly justify that and still add a brief “Internal” entry if the repo’s convention supports it.
• Ensure the changelog entry matches wording/tense/category conventions already used by the repo.

4. Implementation standards

• Follow existing code style, naming, and patterns in this repository.
• Prefer small, readable changes; avoid broad refactors unless clearly necessary to fix the issue correctly.
• Preserve backward compatibility for settings/presets when possible; be careful with defaults and precedence rules.
• Update docs/settings schema/messages if user-facing behavior or configuration changes.
• Logging: use the extension’s existing logging utilities; avoid noisy output and avoid logging secrets/paths unnecessarily.

5. Testing:

• Create a unit test if possible AND practical to validate and test out fix, and ensure it is compatible with all platforms tested: Windows, Linux, and macOS. Ensure that it will not conflict with existing CI settings. If not possible to create a unit test, draft a manual plan for how to validate the changes worked.

Targeted scenario verification (must be addressed):

• Verify via reasoning and/or scripted steps the relevant user flows, as applicable:
  • CMake configure with presets and without presets
  • Build, clean, reconfigure
  • Test discovery and execution (CTest)
  • Debugging (if impacted)
  • Multi-config generators (Ninja Multi-Config / Visual Studio) vs single-config
  • Windows/macOS/Linux differences if relevant

6. PR hygiene + output requirements

• PR title: concise, references the issue number.
• PR description must include:
  • Problem summary (from the issue)
  • Root cause (where in code and why)
  • Fix summary (what changed)
  • Files changed (list + rationale)
  • Changelog entry text + location
  • Tests run (exact commands + results)
  • “How to test” / “How to verify” steps (step-by-step)
• Link and close the issue (e.g., “Fixes #N”).
• Do not mark the work complete until the changelog entry exists and tests/verifi...

• Fixes running ctest using test explore with env vars from test presets #4313

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.