FIX: Use imageOverride demand instead of vmImage for 1ES Windows pool selection

[David-Engel]

Work Item / Issue Reference

AB#42368

N/A

---

Summary

Fix 1ES Pipeline Templates validation failure (1ES PT Error: Using an image without 1es-pt-prerequisites artifact is not allowed) on Windows build stages.

The Django-1ES-pool custom 1ES Hosted Pool was falling back to its default MMS2016 (Windows Server 2019) image because vmImage doesn't properly select images from custom pools. Changed all three Windows pool configurations to use demands with imageOverride (matching the pattern already used by the Linux stage template) to correctly select the WIN22-SQL22 image.

Files changed:

• OneBranchPipelines/stages/build-windows-single-stage.yml
• OneBranchPipelines/official-release-pipeline.yml
• OneBranchPipelines/dummy-release-pipeline.yml

[Copilot]

Pull request overview

Updates OneBranch/1ES pipeline pool configuration so Windows stages/jobs correctly select the custom hosted pool image via demands (imageOverride) instead of vmImage, avoiding the 1ES template validation failure and preventing fallback to the pool default image.

Changes:

• Replaced vmImage: WIN22-SQL22 with demands: - imageOverride -equals WIN22-SQL22 in the Windows build stage template.
• Applied the same pool image selection change to both the official and dummy release pipelines.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated no comments.

File	Description
OneBranchPipelines/stages/build-windows-single-stage.yml	Switches Windows build job pool image selection to demands/imageOverride for the custom 1ES pool.
OneBranchPipelines/official-release-pipeline.yml	Updates the release job’s custom pool configuration to use imageOverride demand for WIN22-SQL22.
OneBranchPipelines/dummy-release-pipeline.yml	Updates the dummy release job’s custom pool configuration to use imageOverride demand for WIN22-SQL22.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[saurabh500]

LGTM. Is it possible to have a successful run link or does this PR need to be merged to test the OB ?

[bewithgaurav]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[github-actions]

📊 Code Coverage Report

🔥 Diff Coverage 100%

🎯 Overall Coverage 76%

📈 Total Lines Covered: 5472 out of 7137 📁 Project: mssql-python

---

Diff Coverage

Diff: main...HEAD, staged and unstaged changes

No lines with coverage information in this diff.

---

📋 Files Needing Attention

📉 Files with overall lowest coverage (click to expand)

mssql_python.pybind.logger_bridge.hpp: 58.8%
mssql_python.pybind.logger_bridge.cpp: 59.2%
mssql_python.row.py: 66.2%
mssql_python.pybind.ddbc_bindings.cpp: 69.3%
mssql_python.pybind.ddbc_bindings.h: 69.7%
mssql_python.pybind.connection.connection.cpp: 75.3%
mssql_python.ddbc_bindings.py: 79.6%
mssql_python.pybind.connection.connection_pool.cpp: 79.6%
mssql_python.connection.py: 84.1%
mssql_python.cursor.py: 84.7%

---

🔗 Quick Links

⚙️ Build Summary	📋 Coverage Details
View Azure DevOps Build	Browse Full Coverage Report

[gargsaumya]

LGTM. Is it possible to have a successful run link or does this PR need to be merged to test the OB ?

With this PR, it would need to be merged first, then synced with ADO, and after that we can run the Official Build pipeline on the latest main.

In the meantime, I’m creating a test PR with the same changes directly in ADO and will run the build on that test branch. This should allow us to validate OB more quickly while this original PR process completes.