Support more kinds of project 'outputs' in Terminal Logger

[baronfel]

Fixes part of #9608 - specifically showing NuGet packages

Context

This builds on top of #12292.

The primary problem being solved here is detecting and classifying different kinds of project outputs for different ways of building projects - specifically

• 'normal builds'
• 'publishing'
• 'packaging'

Correctly detecting these without introducing a new special kind of message (which would require adoption by the various teams involved in building/packaging/etc.) requires some intimate knowledge of the structures of Targets and Tasks that generate those outputs.

Changes Made

Categorizing ProjectStarted build intent

We now track more data about the project(s) being built:

• EntryTargets - used to determine the intent of the build
• (Probably Soon) primary exe/binary names to detect primary assets/exes

To solve the problem of tracking the 'logical outputs' of a project I added the ability to have more than one, and I added an enum to classify each kind of output. We then use this enum to determine

a) what the link in the terminal should point to, and
b) which decorative glyph to use when rendering.

We also support rendering more than one output per TerminalProjectInfo too.

Getting Outputs for relevant Targets and Tasks

There are three kinds of scenario we need to handle to get Target/Task outputs

• Target runs completely for the current project

This is the easiest case - in this case we get TargetFinishedEventArgs that contain TargetOutputs on them. We can inspect these outputs and pick the ones we need for each comparison. We know the specific Targets we need outputs for, so in the ForwardingLoggers we can remove outputs from all other Targets so that we limit the amount of data we forward back to the central logger. We still need to forward all of the TargetFinishedEventArgs because other rendering cares about tracking this.

• Target is skipped because everything was up to date

In this case, we need to start looking at TargetStartedEventArgs and capture the contexts for the Targets that we care about.
If we later get a TargetSkippedEventArgs for any of those targets, we can then listen for matching TaskParameterEventArgs with a Kind of SkippedTargetOutputs, forward those to the central node, and the central node can inspect that message's Items in the same way as the 'normal' Target-completion scenario.

• Target is skipped because it previous ran successfully

In this case, the TargetSkippedEventArgs will say that it previously built successfully, and point to the original BuildEventContext that the results came in on. If we keep the particular kinds of outputs that we need, either on the TerminalProjectInfo structure or on other lookups that are keyed appropriately, we should be able to reconstruct those associations from the original BuildEventContext and use that data however we need to.

Testing

Manual testing.
Automated testing that mimics the kind of message flow in a 'real' build for these same scenarios.

Notes

[baronfel]

Rebased on top of #12292 for easier tracking.

[baronfel]

Added the do-not-merge label because in manual testing I've seen the SourceRoot lookups no longer working after these changes.

[github-actions]

This pull request has been automatically closed because it has been open for more than 180 days with no recent activity.

If you believe this work is still relevant, please feel free to reopen or create a new pull request. Thank you for your contribution!

Generated by Close Stale Pull Requests