Skip to content

Conversation

@rokonec
Copy link
Member

@rokonec rokonec commented Jul 1, 2022

Context

For purpose of msbuild server and other we need to be able to collect and analyze build engine usage.

Changes Made

Data are collected at both msbuild client and msbuild server and then emitted when build is finished by BuildManager.

Testing

Unit tests.
Manual debug tests.

Notes

@rokonec rokonec changed the base branch from main to feature/msbuild-server July 1, 2022 16:13
Copy link
Contributor

@Forgind Forgind left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looking forward to seeing what we can learn from this!

bool serverIsAlreadyRunning = ServerNamedMutex.WasOpen(serverRunningMutexName);
if (KnownTelemetry.BuildTelemetry != null)
{
KnownTelemetry.BuildTelemetry.InitialServerState = serverIsAlreadyRunning ? "hot" : "cold";
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could this be an enum?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I prefer it this way. For telemetry data I like the simplicity of adding new value and transparent passing to telemetry storage.

if (KnownTelemetry.BuildTelemetry != null)
{
KnownTelemetry.BuildTelemetry.Project ??= requestData.ProjectFullPath;
KnownTelemetry.BuildTelemetry.Target ??= string.Join(",", requestData.TargetNames);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My general worry with allocating a lot of strings here for telemetry is that although it isn't a huge deal because it's a cold path, it worsens perf for users without helping them in any way, just helping us help them. Am I wrong about that? Are these telemetry events helpful to users in some way?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is no direct value for users. They could subscribe to our telemetry events in their own logger and somehow process it, but this scenarios is farfetched.
However, this is only one telemetry allocation per whole build and its affect on overall performance will be negligible.


if (KnownTelemetry.BuildTelemetry != null)
{
KnownTelemetry.BuildTelemetry.Project ??= requestData.ProjectGraphEntryPoints?.FirstOrDefault().ProjectFile;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can there be multiple graph entry points? If so, is this right?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There can be, however, this is probably very rare situation and we are fine to have it slightly wrong.
'BuildTelemetry.Project' is designed to be used for events correlations it will correlate build telemetry even when it include just one entry point.

@rokonec rokonec merged commit 26b43b0 into dotnet:feature/msbuild-server Jul 12, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants