-
Notifications
You must be signed in to change notification settings - Fork 1.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Live logger properly report errors during restore. #8707
Merged
Merged
Conversation
This file contains 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
This reverts commit a93882f. This is a temporary fix for dotnet#8684 The current plan is to revert dotnet#8275 in 17.6, as it caused some difficulties, and try to bring it back in 17.7 via dotnet#8685. Summary dotnet#8275 fixed a longstanding confusing and unfortunate behavior in MSBuild in which passing the Copy task a symlink as its destination would copy the source file onto the destination of the symlink rather than overwriting the symlink. Unfortunately, it also introduced a new issue in which copying a file onto itself could often just delete the file instead of copying anything. Customers reported this issue. Customer Impact Projects that copy a file onto itself using the Copy task without passing identical paths for source and destination instead delete the file without necessarily even logging an error. Regression? Yes, from dotnet#8275. Testing Unit tests and manually tested that the repro described in dotnet#8684 no longer works. Risk Minimal (straight revert of the commit that caused the bug) --------- Co-authored-by: Forgind <Forgind@users.noreply.github.com>
…tnet#8625) Summary The for sln-based builds, the AssignProjectConfiguration task ends up using the Configuration and Platform defined in the sln rather than passing through the global properties from the referencing project or attempting to do dynamic platform negotiation. This change adds equivalent functionality to graph construction. A concrete scenario this fixes for graph-based builds using an sln file is that most csproj define the "x86" platform while most vcxproj define "Win32". Previously for a graph build, if the csproj referenced the vcxproj, the platform passed to vcxproj would be x86, not Win32. Even worse, the vcxproj would be an entry point anyway, so it would double-build with both x86 AND Win32, which leads to race conditions. Customer Impact Microsoft-internal customer using sln-based builds will be able to opt-into graph builds Regression? No Testing Manual validation in the customer repo, as well as added unit tests Risk Low. Graph builds are a less-used feature, and this adds parity to what non-graph builds and VS-based builds do. It's unlikely that any behavioral change would be impactful due to those other scenarios presumably working for customers who may be using graph builds.
rainersigwald
approved these changes
May 1, 2023
Fixes source building under FreeBSD where a symlink has not been made for bash Context /bin/bash is standard under OSes that ship with bash installed by default. FreeBSD does not have bash as a default shell. Changes Made For portability /usr/bin/env bash is used on the shebang line. This also bring it inline with other dotnet repos. Testing none needed? Notes env is standard at this point. I have been unable to find a non-historic UNIX-like system that places env in a location exclusively that is not /usr/bin/
Example: Recording.2023-04-28.103416.mp4 I like this both because it highlights the TF more clearly and because it saves two characters of line width.
At least one person skimmed over the section we wanted to emphasize (`-bl`) and focused on `MSBUILDDEBUGENGINE`, sharing lower-fidelity logs that are harder to understand. Remove the "Preferred way" callout--it's preferred in that section but not in general. Add a section header for command-line builds. Add some samples there.
Fixes dotnet#8671 Context New layout as agreed offline specs (content remains same, we'll move here rar-core-scenarios from documentation/design folder) |-----proposed (the secrets metadata and packages sourcing PRs would get routed here. In future - all in-progress work specs) |-----archive (the rar-as-service.md from documentation/design will get moved here. In future - all not dismissed but not planned feature spec goes here) Moving facilitated via git mv to preserve history and make diffs conscise
* Update dependencies from https://github.com/nuget/nuget.client build 6.7.0.19 NuGet.Build.Tasks From Version 6.7.0-preview.1.16 -> To Version 6.7.0-preview.1.19 * Update dependencies from https://github.com/nuget/nuget.client build 6.7.0.20 NuGet.Build.Tasks From Version 6.7.0-preview.1.16 -> To Version 6.7.0-preview.1.20 --------- Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>
Fixes dotnet#8471 Changes Made Adds to Autocomplete EmitCompilerGeneratedFiles CompilerGeneratedFilesOutputPath
Context Minor code cleanup in Microsoft.Common.tasks. Changes Made Removed duplicate UsingTask for the ResolveSDKReference task. The redundant ResolveSDKReference doesn't seem to create harm but is not useful. Alphabetized the UsingTask elements. Retained the separate grouping of Roslyn tasks. Retained the blank lines around tasks that have different Runtimes and/or Conditions (i.e. GenerateResource, RegisterAssembly, and UnregisterAssembly). Ordering the UsingTask elements is intended to aid inspection and maintenance of tasks. Testing Tested on Windows 11 and macOS 12. Tested by running unit tests and by having this change in several development branches where msbuild has been run on project files. Notes This change is included in the implementation for dotnet#8613, which is PR dotnet#8614.
As a part of conflict with @rainersigwald #8715 I have deleted dupplicated of |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
merge-when-branch-open
PRs that are approved, except that there is a problem that means we are not merging stuff right now.
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.
Fixes #8704
Context
Errors during restore was not reported when using /tl (live logger) leaving user without actionable information.
Changes Made
When restore success without error or warn - same as before
When restore success with warnings - report success with warnins and list warnings bellow that report
When restore fails - report errors and warnings THEN report
Restore failed in 1.5s
and do not reportBuild summary
Testing
Local