Arcade allows build to pass as green even when target shows error and build output is corrupted
See original GitHub issueIn this build I get the following error:
##[error].packages\microsoft.dotnet.arcade.sdk\5.0.0-beta.19521.4\tools\VisualStudio.InsertionManifests.targets(23,5): error : Property VisualStudioDropName must be specified in official build that produces Visual Studio insertion components.
Yet the build passes. This will cause the build output to be invalid and should fail the build
Issue Analytics
- State:
- Created 4 years ago
- Comments:11 (11 by maintainers)
Top Results From Across the Web
"pxt target arcade" fails - Microsoft MakeCode
Just playing around with C++ extensions. I made a dummy C++ extension, but cannot build it from the command line - I made...
Read more >AP Computer Science Midterm Flashcards
Study with Quizlet and memorize flashcards containing terms like A state government is attempting to reduce the digital divide.
Read more >Question - [SOLVED] WebGL Build Error - "Unable to parse ...
My current version is Unity 2021.1.4f1. My newest build gave me an error message, shown below (my file is named "WebGL v1"):
Read more >Bug listing with status RESOLVED with resolution FIXED as at ...
Bug listing with status RESOLVED with resolution FIXED as at 2023/06/27 06:45:33.
Read more >Mame 0.253 compiling error
First time it happen... Mame compiling fine without Subtarget... ... The arcade target has been removed, if you need a build with specific...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
I get the interpretation, but I think the current behavior is incorrect and inconsistent with a common sense rule “if a task runs and it fails the build should fail”. I’d be fine if msbuild chose not to run these AfterTargets at all. But running them and ignoring their failure is imo wrong.
Nevertheless, I have been fixing these cases. I guess there are some more left.
Does look related. All our previous instances of something like this were in the powershell side, but that was not the case here. I’ll take a look at that issue. Thanks Davis.