Skip to content
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 17 commits into from
May 4, 2023

Conversation

rokonec
Copy link
Member

@rokonec rokonec commented Apr 26, 2023

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 report Build summary

Testing

Local

Forgind and others added 5 commits April 23, 2023 15:44
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.
@rokonec rokonec changed the title Live logger properly report errors during restore. [WIP] Live logger properly report errors during restore. Apr 26, 2023
@rokonec rokonec changed the title [WIP] Live logger properly report errors during restore. Live logger properly report errors during restore. Apr 26, 2023
Thefrank and others added 11 commits May 1, 2023 13:31
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.
@rokonec
Copy link
Member Author

rokonec commented May 2, 2023

As a part of conflict with @rainersigwald #8715 I have deleted dupplicated of Terminal.RenderColor with IMO better placed AnsiCodes.Colorize. Hope thats OK.

@rokonec rokonec added the merge-when-branch-open PRs that are approved, except that there is a problem that means we are not merging stuff right now. label May 2, 2023
@Forgind Forgind merged commit b313662 into dotnet:main May 4, 2023
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.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

TerminalLogger: errors in restore are not emitted
8 participants