Adding NTLM proxy support

[vinayakmsft]

Context

Task name: Added proxy support for coveragepublisher common task

Description: Added NTLM_PROXY env for coveragepublisher common task.
Fix an issue regarding CoveragePublisher.Console connection failing if it needs to go through proxy.

The main reason for this change is some of the dependencies the customer is running in a network-restricted environment where outbound traffic must go through a corporate proxy. They encountered consistent failures because the task couldn't reach certain on-prem or internal resources due to missing proxy configuration. By adding support for the NTLM_PROXY environment variables, we ensure the task respects the customer’s network routing rules. This change allows the task to function correctly in environments that depend on proxy-based connectivity.

The customer mentioned this was working in the v1 version of the task and the v2 version it was failing because it was not respecting the proxy settings

Issue originated from PublishCodeCoverageResults@2 wherein when the build agent is behind a proxy, the task will fail as the outbound connection is not routing/using the proxy correctly.

Documentation changes required: Ideally - Add information regarding the use of the NTLM_PROXY environment variable if proxy is required for outboundconnection

Added unit tests:

Yes.

Manual test done:

Make sure that relevant env are set (NTLM_PROXY)
Run a pipeline that uses PublishCodeCoverageResults@2
On the test build agent (while the task hasn't been executed yet), override the script with the updated code (Location: /home/vsts/work/_tasks/... )
Expected:

PublishCodeCoverageResults@2 task should succeed, code coverage result visible, and build should not fail
Actual:

Build succeeded and code coverage result visible (Test done just now)

Task Name

PublishCodeCoverageResultsV2

---

---

Risk Assessment (Low / Medium / High)

Low

---

Change Behind Feature Flag (Yes / No)

No, its a configuration addition

---

Tech Design / Approach

• Design has been written and reviewed.
• Any architectural decisions, trade-offs, and alternatives are captured.

---

Documentation Changes Required (Yes/No)

Indicate whether related documentation needs to be updated.

• User guides, API specs, system diagrams, or runbooks are updated.

---

Unit Tests Added or Updated (Yes / No)

Indicate whether unit tests were added or modified to reflect these changes.

---

Additional Testing Performed

List all other tests performed (manual or automated, including integration, regression, scenario tests, etc.).

---

Logging Added/Updated (Yes/No)

• Appropriate log statements are added with meaningful messages.
• Logging does not expose sensitive data.
• Log levels are used correctly (e.g., info, warn, error).

---

Telemetry Added/Updated (Yes/No)

• Custom telemetry (e.g., counters, timers, error tracking) is added as needed.
• Events are tagged with proper metadata for filtering and analysis.
• Telemetry is validated in staging or test environments.

---

Rollback Scenario and Process (Yes/No)

• Rollback plan is documented.

---

Dependency Impact Assessed and Regression Tested (Yes/No)

• All impacted internal modules, APIs, services, and third-party libraries are analyzed.
• Results are reviewed and confirmed to not break existing functionality.

---

Checklist

• Related issue linked (if applicable)
• Task version was bumped — see versioning guide
• Verified the task behaves as expected

[Ricky-G]

NTLM_PASSWORD may be supplied via environment variables (process.env). When values are pulled from process.env, they aren’t automatically masked by the Azure Pipelines agent, so the password could leak into logs. It would be safer to always use taskLib.getVariable() for these secrets and to call taskLib.setSecret() so they’re obfuscated in logs.

[vinayakmsft]

I did not get this, shall I use the NTLM_password parameter or shall i remove it? If I need to keep it how should i update?

[Ricky-G]

Actually here if we are offering a way to enter the ntlm password then yah no choice, we can't avoid it, so ignore my original comment