Use Azure DevOps logging command format for version bump check error with file navigation

[Copilot]

Summary

Fixes the error reporting in .vsts-dotnet-ci.yml line 48 to use proper Azure DevOps logging command format instead of throw, making errors easier to find and diagnose in the Azure DevOps pipeline UI. The error message now includes file path and line number information for direct navigation.

Problem

When the version bump check failed on release branches (vs* branches), the error was thrown as a PowerShell exception, which made it harder to locate and understand in the Azure DevOps pipeline logs. The error message was embedded in a throw statement, which doesn't utilize Azure DevOps' formatting capabilities or provide navigation to the specific file location that needs to be changed.

Solution

Replace the throw statement with:

1. Write-Host to emit the proper Azure DevOps logging command: ##vso[task.logissue type=error]
2. Include sourcepath and linenumber properties to enable direct navigation to the file location
3. exit 1 to explicitly fail the step with a non-zero exit code

Before:

throw "Hello! I noticed that you're targeting one of our servicing branches..."

After:

Write-Host "##vso[task.logissue type=error;sourcepath=eng/Versions.props;linenumber=6;]Hello! I noticed that you're targeting one of our servicing branches..."
exit 1

Benefits

• Better visibility: The error now appears as a properly formatted error in the Azure DevOps UI
• Direct navigation: Developers can click on the error to navigate directly to line 6 of eng/Versions.props where the VersionPrefix needs to be updated
• Easier troubleshooting: Developers can quickly identify the issue without digging through exception stack traces
• Consistent with Azure DevOps best practices: Uses the official logging command format documented by Microsoft

Testing

Validated that:

• PowerShell syntax is correct
• The logging command format follows Azure DevOps documentation
• File path and line number properties are correctly specified
• The change is minimal and focused on the specific issue

Original prompt

On .vsts-dotnet-ci.yml:48-48, When this check fails, the error is hard to get to. Instead of throwing here, use the AzDO format commands (https://learn.microsoft.com/en-us/azure/devops/pipelines/scripts/logging-commands?view=azure-devops&tabs=bash#formatting-commands) to report an AzDO error.

---

💡 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.

[dotnet-policy-service]

Hello @@copilot, I noticed that you’re changing an .swr file or any file under src/Package/MSBuild.VSSetup.. Please make sure to validate this change by an experimental VS insertion. This is accomplished by pushing to an exp/* branch, which requires write permissions to this repo.

[rainersigwald]

@copilot Can you also report the file and line number of the Versions.props file that should change?

[rainersigwald]

@copilot Can you also report the file and line number of the Versions.props file that should change?

[Copilot]

@copilot Can you also report the file and line number of the Versions.props file that should change?

Added in commit 3b385bf. The error message now includes sourcepath=eng/Versions.props;linenumber=6; which will allow Azure DevOps to create a clickable link directly to line 6 of the Versions.props file where VersionPrefix needs to be updated.

[rainersigwald]

I deliberately mistargeted this PR to a branch where it would trigger and this looks pretty good:

[Copilot]

Pull Request Overview

This PR updates the Azure DevOps pipeline error handling for the version bump check to use a structured logging command instead of throwing a PowerShell exception, improving discoverability and navigation in the pipeline UI.

• Replaces throw with an Azure DevOps logging command (##vso[task.logissue ...])
• Adds file path and line number metadata for clickable navigation
• Explicitly exits with non-zero status using exit 1

[AR-May]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).