Merged
Conversation
Previously, eng/build.ps1 always exited with 0 regardless of whether the underlying build succeeded or failed. This caused Azure Pipelines to show steps as 'succeeded' even when they failed (e.g., when the .NET SDK was not found). The fix captures $LASTEXITCODE after Invoke-Expression and uses it as the script's exit code instead of always exiting 0.
Member
|
@copilot we should fix this at upstream at dotnet/arcade repository, can you take care of that? |
Contributor
mattleibow
previously approved these changes
Feb 4, 2026
Contributor
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 1 out of 1 changed files in this pull request and generated no new comments.
Comments suppressed due to low confidence (1)
eng/build.ps1:120
- Consider exiting early if the build fails, before attempting to run code coverage operations. If the build failed (
$buildExitCode -ne 0), running tests and collecting coverage data is unlikely to succeed or provide useful information.
You could add a check immediately after line 115:
if ($buildExitCode -ne 0) {
exit $buildExitCode
}
This would make the script fail fast and provide clearer error feedback. However, this is an optional enhancement and not blocking for this PR.
# Perform code coverage as the last operation, this enables the following scenarios:
# .\build.cmd -restore -build -c Release -testCoverage
if ($testCoverage) {
The 'Install .NET' step runs with -restore which installs the SDK, but environment variables don't persist between Azure DevOps steps. The subsequent 'Build the MSBuild Tasks' step was running with just -build, which doesn't install the SDK if missing. Adding -restore ensures the SDK is properly available even in a new PowerShell process.
mattleibow
approved these changes
Feb 5, 2026
Member
Author
|
/azp run maui-pr-uitests, maui-pr-devicetests |
|
Azure Pipelines successfully started running 2 pipeline(s). |
This was referenced Feb 5, 2026
Open
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Note
Are you waiting for the changes in this PR to be merged?
It would be very helpful if you could test the resulting artifacts from this PR and let us know in a comment if this change resolves your issue. Thank you!
Description
Fixes an issue where
eng/build.ps1always exited with code 0 regardless of whether the underlying build succeeded or failed. This caused Azure Pipelines to show steps as "succeeded" even when they failed.Problem
When running
./build.cmd -build(without-restore), if the .NET SDK is not found, the script would:ExitWithExitCode 1intools.ps1eng/build.ps1would still exit with 0 (line 146:exit 0)This caused Azure Pipelines to show the step as green/succeeded when it should have been red/failed.
Fix
$LASTEXITCODEafterInvoke-Expressioncall tocommon/build.ps1Testing
This fix was identified while investigating Windows Helix device test failures where the "Build the MSBuild Tasks" step was showing as succeeded but had actually failed to find the SDK.
Build with the issue: https://dev.azure.com/dnceng-public/public/_build/results?buildId=1279950