Test with CI artifacts

Prefer an existing compatible CI build when checking whether an upstream change fixes a downstream regression. A successful upstream workflow is not proof that the VS Code scenario passes: run the downstream test with the candidate artifact.

This workflow applies to runtime executables, native libraries, SDK packages, and packaged applications. Use the relevant integration-test, unit-test, or smoke-test workflow for execution. For Azure-hosted artifacts, use azure-pipelines for discovery and retrieval; the provenance and comparison rules below still apply.

1. Identify the candidate before building

• Record the upstream repository, PR number, exact head SHA, and intended regression. Record the downstream checkout revision and bundled dependency version.
• Check CI artifacts before cloning, installing dependencies, or starting a local build. Inspect the producer workflow when artifact names or packaging are unclear.
• Execute only artifacts from an authorized source. Treat PR binaries as code execution, use isolated test state, and do not supply live credentials to a deterministic replay test.

GitHub Actions discovery example (replace the illustrative values):