-
Notifications
You must be signed in to change notification settings - Fork 14
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
Report errors from build telemetry #4054
Conversation
3308d8c
to
dbb7f12
Compare
// Shutdown the connection. | ||
await connection.ShutdownAsync(cts.Token); | ||
} | ||
catch |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just removed this catch block that was ignoring all exceptions
@@ -75,13 +75,11 @@ | |||
</OutputHashTask> | |||
|
|||
<!-- Run build telemetry --> | |||
<BuildTelemetryTask | |||
<Exec |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can use the standard Exec task to call the reporter, no need for a custom task.
Condition="'$(IceRpcBuildTelemetry)' != 'false'" | ||
ContinueOnError="true" | ||
/> | ||
ContinueOnError="true" /> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Alternatively we can use IgnoreExitCode
parameter from Exec task. The difference is that errors would be reported as regular messages instead of warnings.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that IgnoreExitCode
would be preferable.
Maybe our collective sentiment has changed, but I think that a telemetry failure should have no impact on whether your build succeeds or not; and emitting warnings would still cause a failure if warnings are being treated as errors (something that seems to be at least slightly common).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Presumably ContinueOnError=true means we keep going on error.
Keeping in mind this process (slice compilation) is under our control here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe I misunderstood, but #4049 made it sound like ContinueOnError
was insufficient.
Even though, "keep going on error" is definitely the impression you get from it's name.
(maybe only if you treat warnings as errors? But, to be fair, that is something that many developers do.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe I misunderstood, but #4049 made it sound like ContinueOnError was insufficient.
That was my impression too when I created the bug. But it is not correct. When you set ContinueOnError warnings doesn't make the build fail even if you set treat warnings as errors.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks much simpler!
WorkingDirectory="$(IceRpcBuildTelemetryScriptPath)" | ||
CompilationHash="$(Hash)" | ||
SourceFileCount="$(FileCount)" | ||
Command="dotnet IceRpc.BuildTelemetry.Reporter.dll --idl protobuf --hash=$(Hash) --src-file-count=$(FileCount)" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same here with no equals after the idl
switch.
Condition="'$(IceRpcBuildTelemetry)' != 'false'" | ||
ContinueOnError="true" | ||
/> | ||
ContinueOnError="true" /> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that IgnoreExitCode
would be preferable.
Maybe our collective sentiment has changed, but I think that a telemetry failure should have no impact on whether your build succeeds or not; and emitting warnings would still cause a failure if warnings are being treated as errors (something that seems to be at least slightly common).
try | ||
// Create a cancellation token source to cancel the telemetry upload if it | ||
// takes too long. | ||
using var cts = new CancellationTokenSource(timeout); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I find this code oddly written. We use timeout only here, no need for var timeout
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agree, I just removed the try/catch would rewrite this in a follow up PR where we split the program in protobuf/slice versions.
using var cts = new CancellationTokenSource(timeout); | ||
|
||
// Create a client connection | ||
var clientAuthenticationOptions = new SslClientAuthenticationOptions(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No need for this extra variable.
var reporter = new ReporterProxy(connection); | ||
|
||
// Parse the IDL | ||
string? idl = args |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
From the expression below, doesn't sound like in can be null.
.Skip(1) | ||
.FirstOrDefault(), out int referenceFileCountResult) ? referenceFileCountResult : 0; | ||
|
||
BuildTelemetry buildTelemetry = idl.ToLower() switch |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Given how trivial this program is, I would prefer to have separate versions for IceRpc.Protobuf.Tools and IceRpc.Slice.Tools. For a follow-up PR.
Then no need for an "idl" argument to the program.
Also note that most (maybe all) arguments are IDL-specific. --contains-slice1/--contains-slice2/--ref-file-count is Slice-only, which is not clear with the current setup.
@@ -2,98 +2,92 @@ | |||
|
|||
using IceRpc; | |||
using IceRpc.BuildTelemetry; | |||
using Microsoft.Extensions.Logging; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Where do we use Logging?
This PR updates the telemetry reporter to report errors, that are then treated as warning and allow the build to continue:
For example, with a disconnected network:
or with detailed logging enabled
/v:d